In today’s post in the modernizing your infrastructure with Hybrid Cloud series, I am going to talk about Hyper-V over SMB, which we introduced in Windows Server 2012. It is also important to note that you can use storage spaces to house your SMB share that Hyper-V will leveraged. In Part 7 I talked about storage spaces: Modernizing Your Infrastructure with Hybrid Cloud - Storage Spaces in Windows Server 2012 R2 (Part7)
With Windows Server 2012 R2, we have improved the SMB protocol and it is a new version SMB 3.02. I will start this article with a quick review of SMB 3.0 and talk about the improvements that can be found in SMB 3.02 which is included in Windows Server 2012 R2
In Windows Server 2012 we introduced the next version of SMB 3.0. The SMB protocol, essentially allows applications or the user of an applications to access files and other remote server side resources. This allows the basic operations like working with files, reading, writing, accessing…etc. It can also communicate with any server program that is set up to receive an SMB client request. Two of the most important features we introduced into SMB are Microsoft SQL Server over SMB and Hyper-V over SMB (we will get to that in a second). We also included several other new features:
I wrote about these in a post I did a while back: 31 Days of Our Favorite Things- SMB 3.0 the Glue in Windows Server 2012 (Part 17 of 31)
In Windows Server 2012 R2 we have updated SMB to version 3.02. A good list of what is new can be found here: What's New in SMB. There are several new and improved functionalities in the protocol including:
Probably the most important enhancement we put into the SMB 3.02 protocol is the ability to do Automatic rebalancing of Scale-Out File Server clients!
In SMB 3.0 we had the ability to use Scale-Out-File Servers. In Windows Server 2012, SMB clients would be randomly directed via DNS Round Robin to a node of the cluster. Then once that node was selected they would use that for all the shares they wanted to access and all their traffic would be going to that particular file server. With Automatic rebalancing of Scale-Out File Server clients change how they connect to file servers. SMB client connections are tracked per file share (instead of per server), and clients are then redirected to the cluster node with the best access to the volume used by the file share. This improves efficiency by reducing redirection traffic between file server nodes. Clients are redirected following an initial connection and when cluster storage is reconfigured. What that essentially means is the client will leverage the best server for the file share they are looking to use. Jose Barreto wrote an excellent post going into some great comparisons for this new feature: Automatic SMB Scale-Out Rebalancing in Windows Server 2012 R2
If you want to learn more about SMB 3.02, my buddy Keith wrote a great post here: Why R2- Your Next SAN with SMB 3.02 Scale-out File Servers
Now let’s take this to next level with Hyper-V. In Windows Server 2012 R2 you can now store virtual machine files, such as configuration, Virtual hard disk (VHD) files, and snapshots, in file shares over the SMB 3.0 protocol. This can be used for both stand-alone file servers and clustered file servers that use Hyper-V together with shared file storage for the cluster. By leveraging two new features of SMB 3.0 (SMB Direct and SMB Multichannel) on a file server hosting the VHDX drives for your Hyper-V cluster, you can see storage performance on your Hyper-V guests that approaches that of a built-in server storage. Not only that, but those Hyper-V guests enjoy the resiliency of a failover network to help avoid any outages. Taking this even a step further with your virtual machine stored on an SMB file share. You can then perform a live migration on this virtual machine, running between non-clustered Hyper‑V hosts while the virtual machine’s storage remains on the central SMB share. This lets you use the benefits of virtual machine mobility without investing in clustering infrastructure. Hosting providers and similar environments frequently need this capability. All provided courtesy of this wonderful protocol and take a look at the graphic for some examples:
Overall the process of creating a virtual machine on an SMB is very straight forward:
Then viola you’re done! The only tricky part and really it is not that tricky is to set permissions on the share and the NTFS folder. For this to work properly, you will need to set full permissions on the NTFS folder for the following accounts:
The reason I mention security is because of traditional SAN and NAS solutions. These solutions commonly use some type of security system to help ensure that only authorized hosts have access to shared storage – such as LUN masking in Fiber Channel SANs, initiator lists in iSCSI SANs and access lists for NFS NAS devices.
With SMB 3.02, we’ve streamlined the security model used to provide authorized access to shared storage by aligning it to the well-understood NTFS security capabilities already used in many organizations for securing application data.
Here is a great video talking about some of the considerations when doing Hyper-V over SMB:
You can do this easily enough in PowerShell. The following sequence will create a folder on the F: drive called VMS. In step 2 you will create a share and set full access permissions for the administrator account HAdmin in the Dom domain, two Hyper-V hosts (HV1, HV2 and since this is on a cluster, HVC for the cluster host:
I hoped you enjoyed this post and please check out the full series here: