How to Store Hyper-V Virtual Machines on SMB 3.0 Storage
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 Virtual Machines on SMB 3.0: Configure Default Storage Locations
Hyper-V has a default location for storing the files of new virtual machines and another default location for new virtual hard disks:
- Virtual hard disks: C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks
- Virtual machines: C:\ProgramData\Microsoft\Windows\Hyper-V
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.
- D:\Virtual Machines or similar: If you are using direct attached storage (DAS) to store virtual machines
- C:\ClusterStorage\Volume1 or similar: In the situation where you are creating a Hyper-V cluster with a traditional SAN and Cluster Shared Volumes (CSVs)
- \\FileServer\ShareName or similar: When you want to use SMB 3.0 storage whether the hosts will be clustered or not
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.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
Specifying default storage locations in Hyper-V settings.
Creating Virtual Machines
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).
- Set the permissions of the share to include the host(s) and Hyper-V administrators (with the required reboots/logins if users/servers are added to a security group).
- Specify the UNC path of the share instead of a local path.
Note that VMM simplifies this process as follows.
- You can add the shared folder as a storage location to host/cluster properties in the VMM console.
- VMM will set permissions using a Run As account that has administrative rights on the SOFS or file server when you assign the share.
Additional Benefit of SMB 3.0 Storage
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):
- Disable high availability of the VM on a source clustered host (remove it from the cluster) before Live Migration to a non-clustered host or another cluster.
- Enable high availability of the VM on a destination clustered (add it to the cluster) after Live Migration from a non-clustered host or another cluster.
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.