With Windows Server 2012, Microsoft introduced support of SMB 3.0. With that introduction, there also came support of using the SMB 3.0 share location as a placement option for application files, including Hyper-V VHDs and VHDXs. This came about, because the new SMB protocol supported scalability and high-availability enhancements. These were discussed in an earlier post.
With storage arrays like EMC’s Unified VNX and VNXe, a file gateway is included, and with the appropriate VNX OE installed, SMB 3.0 is supported. Using that as a storage target, customers can deploy standalone and clustered Windows Server 2012 (and later) implementations and use these SMB 3.0 targets as valid locations for applications (SQL Server, for example) and Hyper-V VMs. Because the fileshare is seen by all nodes in the cluster, and because persistent filehandles are supported, Hyper-V virtual machines with VHD/VHDX file located on these fileshares, can be enabled as Clustered Roles, and will support all normal Windows cluster functionality, including Live Migration, etc.
For many customers however, usage of the SMB 3.0 share model also includes a management aspect. What I mean by this, is that they want to put the Hyper-V hosts under the control of System Center Virtual Machine Manager 2012 R2. Which, of course is all goodness as the management features add a great deal of value and function. But then comes the desire to have the fileshares seen and possibly managed by SCVMM2012 R2. Without introducing awareness of the existence of the file shares to SCVMM 2012 R2, these entities are not known, which means that they are not considered targets for VM deployments … and that will never do.
Management Versus Tolerance
I’m going to make a distinction between two aspects, which may be referred to as Management and Tolerance. Management means the proactive operations against an object, which include , amongst other things, creation and deletion of an object (in this case a fileshare). Tolerance is simply the introduction of awareness of an object to a system, and the ability of the two to coexist. SCVMM 2012 R2 can be tolerant of an entity such as a third party, unmanaged fileshare on Windows 2012 Server running Hyper-V. Thus SCVMM 2012 can be aware of and use certain objects without needing to manage them. This may not work for all requirements, but for many, this may be sufficient.
When we talk about Management of an SMB 3.0 fileshare, we are either talking about native Windows Server SMB management (if it’s a Windows 2012 Server that’s creating the SMB 3.0 share, which, for these scenarios, is typically a Scale-out fileshare), or for third party arrays with SMB 3.0, this will require an SMI-S File Provider. Note that this is a FILE SMI-S provider. I say that, because you can have separate FILE and BLOCK providers. Most people will be familiar with the block providers – EMC’s had a block provider for quite some time, and this provides the interface for management of block storage devices from within SCVMM 2012 R2.
For may existing storage arrays, there may not be an SMI-S file provider, and we may not be able to manage the SMB 3.0 fileshares, but we can introduce a level of tolerance of an SMB 3.0 fileshare into SCVMM 2012 R2, without the need for an SMI-S File Provider.
It is the File SMI-S Provider that will invariably trip up most customers. EMC introduced a File Provider with the VNX2 (applicable to VMAX with the appropriate Gateway) product. Since VNX and VNXe preceded the definition of the SMI-S File specification, they do not have a File Provider at this time.
Configuring System Center 2012 R2 for Unmanaged Fileshares
We’ll assume that the target Windows Server 2012 cluster (also works for a standalone Windows 2012 Server) has previously been deployed, and is known to the SCVMM 2012 R2 infrastructure.
SCVMM 2012 R2 Account requirement
One item that many deployments fail to implement, are appropriate account requirements for SCVMM for the managed systems (Host and Clusters). The requirement is the usage of a RunAs account when adding a Cluster or Host to the SCVMM 2012 environment. What invariably happens is that administrators will add the resource, without assigning a “RunAs” account to manage the host/cluster. That’s a problem here, because we need to use SCVMM 2012 to assign the FileShare, and it will proxy user access to the share from the node using this defined RunAs account. The problem is, that if you did not do this when adding the cluster resource, when attempting to access the FileShare, various failures will typically occur.
If the cluster/host has already been added to SCVMM 2012 R2, then you will find that the option is grayed out, and inaccessible via the UI. You get to see if this RunAs account has been assigned by looking at the properties of an individual cluster node, in the Fabric -> Servers area of VMM, and you can see an example below. The “Browse” option to associate a different RunAs account is grayed out and unavailable.
The most direct way to assign a RunAs account, is to remove the Cluster from SCVMM 2012 R2, and then re-add the cluster specifying the RunAs account. While that is one way to do it, this can cause some side-effects if there are existing resources already deployed into the cluster. One alternative is to use PowerShell to save some angst, and mitigate impact to existing resources.
The following script, run on the SCVMM 2012 server, will assign a RunAs account. This account (the actual Domain user account) will need to be the same account that was used, or will be used, to assign access permissions on the share. In this example case, the user account is defined within the RunAs account “DomainUserForFileShare”, and the cluster is “CLOUD2-CLUSTER”. You will need to define your own RunAs name, and have assigned the correct domain user account.
$MyCluster = Get-SCVMHostCluster -Name CLOUD2-CLUSTER
$MyRunAsAccount = Get-SCRunAsAccount -Name DomainUserForFileShare
Set-SCVmHostCluster -VMHostCluster $MyCluster -VMHostManagementCredential $MyRunAsAccount
In the event that this does not end up working, then it may be necessary to resort to the removal of the cluster from SCVMM and then the re-addition of the cluster (using a RunAs account).
FileShare Security/Access Requirement
The account defined for use as the RunAs account when adding the cluster, then also needs to be assigned permissions on the fileshare itself. For VNX/VNXe arrays this can be done by using the Computer Management MMC from any Windows host, and connecting to the VNX/VNXe (as is the case here). The remote connection is specified via a right-click against the root level item in the MMC as shown below:
Once connected, expand the tree to show the fileshare on the VNX/VNXe, and select the Properties option as shown below:
It will be necessary to configure appropriate permission on the share, by adding the domain account used within the RunAs account. I would recommend adding the Computer accounts (all nodes, and the Cluster object) with the same permissions. These accounts should all be assigned the permissions required by SCVMM 2012 R2:
- Share permissions: Full
- NTFS permissions: Modify, ChangePermissions, DeleteSubdirectoriesAndFiles
This will then provide appropriate access for the connections made from the cluster nodes for any services being accessed. As an aside, if operations appear to fail when executed from within SCVMM (for example, when deploying a virtual machine), it can be useful to use the Computer Management MMC to see if there are security failures. You will find these in the “Event Viewer” node, in the “Security” item.
Add the Unmanaged File Share to SCVMM 2012 R2
With all the appropriate security requirements implemented, the fileshare may be added, such that SCVMM 2012 R2 becomes aware of its existence, and allows for it to be used for deploying virtual machines to. To do this, we add the fileshare to the Cluster entity itself from within SCVMM 2012 R2. In the image below, we first select the cluster object in the “VMs and Services” section (although the same option is accessible in the Fabric section for the Cluster), and select the “File Share Storage” item.
From this location, shares can then be added via the “Add” option, as shown in the example below. It is assumed here, that the VNX/VNXe has been appropriately added to the domain, and is correctly defined within the DNS being used.
It is recommended to watch the job execution within SCVMM 2012 R2 after the share is added to ensure that there are no errors logged for the cluster nodes.
If successfully added, the fileshare will be defined against all nodes, and can now be used for virtual machine placement. The VNX/VNXe systems support Continuous availability and multi-channel connections, and therefore fulfill all requirements for implementing scalable and highly available virtual machine storage.
Virtual Machine deployments from within SCVMM 2012 R2 can now be executed through the UI, or via scripting, and specify the fileshare location for the VHD/VHDX storage. In the example below, a virtual machine was deployed to this unmanaged share from within SCVMM 2012 R2, and the VHDX location is highlighted.
Because this is an unmanaged fileshare. SCVMM 2012 R2 will show an alert next to the assigned fileshare, as shown below. This is as a result of its unmanaged state, and the inability of SCVMM 2012 R2 to set and change account permissions directly on the share.
In addition, because there is no management of the fileshare, SCVMM 2012 R2 is unable to define new shares or remove existing ones. These operations will need to be affected manually by the administrator. EMC does provide a number of PowerShell utilities to control and manage the fileshares on VNX and VNXe systems.