In this article we will show you how to use and store Hyper-V virtual machines on SMB 3.0 storage. People expect this process to be extremely complex, but it’s not. If you can create a shared folder and set the permissions on the share and folder, then you already know how to use SMB 3.0 shares for Hyper-V.
Hyper-V has a default location for storing the files of new virtual machines and another default location for new virtual hard disks:
These are pretty dumb locations to use no matter what kind of storage you use. We would recommend that you always change both of these locations to the following.
Below you can see that the UNC path to a file share on a Scale-Out File Server (SOFS) was used to define both default locations in the Hyper-V Settings of a host in Hyper-V Manager. This means that any process of creating a new virtual hard disk or virtual machine in Hyper-V will use this file share. You can override the choice of location. Tip: Verify that the hosts and Hyper-V administrators have Full Control access to the share and folder.
Specifying default storage locations in Hyper-V settings.
Most people seem to expect some additional complexity when creating a virtual machine on a shared folder. It’s no different to use local storage or CSV; you just specify a UNC path that the host (or hosts in the case of a cluster) and administrators have access to, as you can see below.
Specifying the path of a new virtual machine.
If you do not check the Store The Virtual Machine In A Different Location box, then the files of the virtual machine will be created in the root of the folder. This is the unfortunate default action, and it leads to a messy collection of files names after the GUIDs of the associated virtual machines.
Check the box, and you’ll store the files of the new virtual machine in a sub-folder named after the virtual machine – a much tidier solution. Note that System Center – Virtual Machine Manager uses this default folder process by default.
During the New Virtual Machine Wizard, the default option is to create a Dynamic VHDX file as the boot virtual hard disk of the virtual machine. You can see that this file is being stored nicely in a sub-folder called Virtual Hard Disks in the virtual machine’s own sub-folder.
Default VHDX location for the new virtual machine.
Finally the virtual machine is created with all of the virtual machine’s files stored on the shared folder.
The new virtual machine’s files on the SMB 3.0 share
The process is the same no matter what tool you use, be it Hyper-V Manager, PowerShell, Failover Cluster Manager, or Virtual Machine Manager (VMM).
Note that VMM simplifies this process as follows.
There is an additional benefit of using shared folders to store virtual machines beyond simplification, cost reduction, and the performance of SMB 3.0. Unlike a CSV where a cluster member is the coordinator (owner) of that volume, no Hyper-V cluster member owns the SMB 3.0 share. The same applies to a non-clustered host; virtual machines aren’t stored on single owner DAS. A folder can be shared with more than one non-clustered host, multiple Hyper-V clusters, or a mix of Hyper-V clusters and non-clustered hosts.
With Live Migration you can easily move virtual machines across your entire Windows Server 2012 Hyper-V and/or Hyper-V Server 2012 estate… assuming that your host/VM licensing is adequate, of course. Files never move; they reside on the shared folder and the virtual machine’s running state is copied and synchronized between the source and destination host. Note that in the case of cross-cluster migration (Live Migration to/from one cluster to another, or to/from a non-clustered host):
Doing the above has no downtime for the VM. You do not need to do the above when live migrating a VM between hosts in the same cluster (things are simple there).
An additional benefit of using SMB 3.0 storage is that it will simplify “upgrades” using Cross-Version Live Migration, a new feature in WS2012 R2 Hyper-V and Hyper-V Server 2012 R2. Simply build the new hosts/clusters, grant them rights to the new file share, and live migrate (one-way only) from 2012 to 2012 R2. There is no need for any down time or duplication of storage.