In Windows Server 2012, Hyper-V added the capability to store virtual machine (VM) resources on network shares hosted on NAS devices as an alternative to SAN remote storage. The Hyper-V storage stack in Windows Server 2012 now supports increased resiliency for network disconnects for these VM resources by using the “resilient handles” feature in the SMB protocol. This basically means that now virtual machine resources such as VM configuration file, ISO files, VHD files and VHD snapshot files can be stored on any remote SMB file share that supports the SMB 2.2+ protocol.

The Hyper-V over SMB feature in System Center 2012 Virtual Machine Manager (VMM) builds on this feature by increasing management support and adding full support for NAS storage management. User can now do the entire lifecycle of a network share from creation, modifying permissions, to deletion through VMM. These network shares could either reside on a Windows Server 2012 (now SMB 3.0) file server or on NAS devices that implements the SMB 2.2 or higher protocol. Currently VMM support NAS devices (NetApp or/and EMC) supporting SMI-S compliant storage provider.

Basics

Following are the steps to manage SMB shares in VMM:

1.       Add Storage device: The first step is to add the storage device or the Windows file server into VMM’s management. This can be done using the Fabric workspace à Storage\Provider node à Right click and select the “Add Storage device” option.  Select “Native Windows WMI” for Windows file server or “SMI-S CIMXML” for SMI-S NAS compliant storage provider. Use the RunAs account that has administrator access on the file server. VMM will use this specified RunAs account to execute additional future file share administrative operations like create shares, modify permissions on the shares and delete shares. As part of this operation, VMM will discover all the currently present shares on the storage device and add them to VMM’s management. Any shares added later on the storage device (out of band from VMM) will also be periodically discovered and added to VMM management. The Add-SCStorageProvider cmdlet can also be used to add the storage device from PowerShell command line.

2.       Create the share: You can optionally create file shares directly on this provider using the Fabric workspace à Storage\Provider node à Select the provider from the right view or data grid à Select the ribbon action to Create File Share. If the user specifies a local path that is not present on the file server, VMM will automatically add the path for you. The New-SCStorageFileShare cmdlet can also be used to create the share from PowerShell command line.

3.       Register the share to a host or cluster: Once a share is added or discovered, you need to register it with any hosts or clusters where you want to create the VMs that can utilize the file server remote storage. This is done using the Fabric workspace à Select the host or cluster à Right click “Properties” à “Storage” page (for host) & “File Share Storage” page (for clusters)  à Select “Add File Share” option. As part of this operation VMM will modify the share with the necessary permissions for the Hyper-V host to access the storage. Additional details on these permissions are given in the section titled “When should I manually modify the permissions on the share?”. The Register-SCStorageFileShare cmdlet can also be used to register the share from PowerShell command line.

4.       Create the VM instance with VM resources on the SMB share: Once the share is registered with the host or cluster, you can now place virtual machine VHDs and/or VM resources on this share. During the new virtual machine creation wizard, you can select a SMB share in the “Configure Settings” page:

a.       You can select to put all the virtual machine files on a SMB share. This can be done by selecting the “Virtual machine location” as the registered SMB share.

b.      You can also optionally select to put only individual VHD files on a SMB share. This can be done by selecting the “Transfer the virtual hard disk by using the network” and then selecting the source as on of the library share and destination path as the registered SMB share.

c.       You can also select to use an existing VHD from an SMB share. This can be done by selecting the “Use the virtual hard disk that exists at the destination” option and then select the destination path as the path to the VHD on the registered SMB share.

 

5.       Unregistering the share from the host or cluster: Before removing the host or cluster, it is recommend to unregister the share from the host or cluster. This would cleanup all the unnecessary permissions, to the Hyper-V host, on the share. This can be done using the Fabric workspace à Select the host or cluster à Right click “Properties” à “Storage” page à Select “Remove File Share” option. The Unregister-SCStorageFileShare cmdlet can also be used to unregister a share from PowerShell command line. Based on optional user input –LeavePermissionsOnShare, one can select to not modify the permissions on the share. This option is only available when using PowerShell command line. The default for this option is $false i.e. to always remove the permissions from the share.

6.       Remove the share: You can also remove the share completely from the file server using VMM. This can be done using Fabric workspace à Storage/Provider node à Select the provider from the right data grid à Select the share à Select the ribbon action “Remove”. Please note that this would permanently remove the share from the file system. This will not delete the files on the share. The Remove-SCStorageFileShare cmdlet can be used to remove the share from PowerShell command line.

For additional details on these steps, please visit the TechNet Library and look for Hyper-V over SMB support.

FAQ

When should I manually modify the permissions on the share?

VMM updates all the required permissions on the share for you. You don’t need to manually modify any permissions to allow Hyper-V access to the file share.

Figure 1: File server administration

VMM adds the following RunAs accounts to the share permissions:

a)      The Hyper-V host administrator account. This is the management domain account used while adding the host or the cluster.

b)      The machine account of the host. In cluster case, the VMM server will add the machine accounts of all the nodes of a cluster. When new nodes are added to the cluster, VMM will automatically update permission on all the shares registered to the cluster as part of the periodic refreshing of the cluster.

For Windows server SMB file shares, VMM will add the following permissions for all the above accounts:

a)  Share permissions: AccessRights.Full

b)  NTFS permissions: FileSystemRights.Modify | FileSystemRights.ChangePermissions | FileSystemRights.DeleteSubdirectoriesAndFiles

For SMI-S NAS compliant storage providers, VMM will add the following permissions for the above accounts:

a)      CIM_AssociatedPrivilege of 5 (Read), 6 (Write) and Change Permissions (14).

The only case where you ever want to modify permissions for a share, is the case of unmanaged share. An unmanaged share in VMM, 

is one that is not associated with a provider or a file server. Such shares can also be managed by VMM, but with limited capability of 

only being able to create VMs on these shares, but no share ACL management.

Credential Delegation: Why doesn’t VMM need constrained delegation for Hyper-V SMB storage?

Figure 2: Credential Delegation

On the first call to the SMB share, Hyper-V impersonates the user (in this case CONTOSO\AdminH) that has initiated the VHD mount operation. This is done to validate whether the calling user has appropriate permissions to the VHD file on the SMB share. If this call succeeds then in the following calls, Hyper-V will use the machine account credentials of the Hyper-V host (in this case CONTOSO\HyperVHost$).

When the VMM server/client or any other management client attempts to manage Hyper-V VMs on an SMB share remotely, an identity level token is handed to Hyper-V (first hop) by default which will result in a failure to authenticate to the SMB share (second-hop) after impersonation (as described above). This authentication failure is due to the fact that an identity level token cannot be used on any machine other than the one it was created on. To avoid this issue, either constrained delegation must be setup between the Hyper-V server and the SMB share server allowing the identity token on the Hyper-V server to be accepted by AD for authenticating to the SMB share server or VMM must pass a full interactive token to Hyper-V for the operation (provided by CredSSP).

The first option of using constrained delegation not only requires higher level of authority on the domain but also needs updating, as fabric (Hyper-V hosts/clusters) changes over time. The second alternative to achieve credential delegation, is to use CredSSP. Hyper-V remote APIs (WinRM) allows using CredSSP authentication for delegation of the callers’ credentials. VMM uses CredSSP and enables CredSSP on the host agent WinRM calls.

To enable CredSSP, VMM automatically does the following for you:

1.       VMM Server Setup: VMM server setup configure the machine’s group policy settings to allow WinRM to use the CredSSP authentication provider.

o   Enable WinRM client GPO: Computer Configuration\Administrative template\Windows Components\Windows Remote Management (WinRM)\WinRM Client

[Allow CredSSP authentication] = true

                                                OR

                                                Command Line: winrm set winrm/config/client/auth '@{CredSSP="true"}'

o   Enable credential delegation GPO:  Computer Configuration\Administrative Templates\System\Credentials Delegation

[AllowFreshCredentials ] = "WSMAN/*"

2.       Host agent Setup:

o   Enable WinRM service GPO:  Computer Configuration\Administrative template\Windows Components\Windows Remote Management (WinRM)\WinRM Service.

[Allow CredSSP authentication] = true

OR

Command Line: winrm set winrm/config/service/auth '@{CredSSP="true"}'

3.       VMM’s WinRM communication channel: WinRM only allows delegation of “Fresh credentials”. This requires the VMM server to explicitly pass valid credentials when creating a WinRM session. (Note that we cannot use VMM service account since WinRM does not support using “Default credentials”). We use the RunAs account assigned while adding the host or cluster for this purpose. All the following WinRM calls to the host will use this RunAs account to manage the host. Hence it’s essential to add the host and/or cluster with a RunAs account instead of just providing direct credentials (i.e. username and password), allowing VMM to use these saved credentials for delegation.

 

I hope that you will found this post helpful. Please feel free to submit feedback at the bottom of this post and/or ask questions on the VMM forums.  Also, make sure to visit the VMM 2012 TechNet Library!

Thanks,

Radhika Gupta | Developer | MSFT

Get the latest System Center news on Facebook and Twitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/