What Are Shared Virtual Hard Disk Sets on Windows Server 2016 Hyper-V?
This post will explain what Shared Virtual Hard Disk (VHD) Sets are and why to use them to create shared virtual storage on Windows Server 2016 (WS2016) Hyper-V.
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.
Hyper-V clusters allow us to have high availability (HA) at the host level but it does nothing for solving service HA. The best solution for this is to develop or acquire applications that have HA built into the application layer. All too often, we need to create clusters to allow service failover. This means that we need to build a cluster from virtual machines.
A requirement of clustering is that the data of the service is placed in storage that both cluster nodes can access. Traditionally, this was a SAN but other options appeared, such as SMB 3.0 and Storage Spaces in Windows Server 2012 (WS2012). We can use iSCSI, virtual fiber channel, and SMB 3.0 for cluster storage with Hyper-V virtual machines but this causes a problem. Normally, virtualization administrators dislike when the guest layer crosses a boundary to the physical layer. An example of this is when a guest OS connects to an LUN in a SAN. This boundary crossing is a total no-no in hosting or cloud computing.
WS2012 R2 included a way to create completely virtual guest clusters. A VHDX file was created and connected to the SCSI controllers of two virtual machines. Keep in mind, sharing had to be enabled on the connection. Each virtual machine saw the disk as SAS storage, which is supported by failover clustering.
At first, Shared VHDX sounded perfect but then the asterisks were presented:
- We could not do a hot-resizing of the VHDX file. The cluster had to be shut down first.
- Hyper-V Replica could not be used to replicate the guest cluster. Instead, you had to replicate the data from inside the guest OS or use other forms of storage replication.
- Worst of all, we could not backup virtual machines from the host level if shared VHDX was used. We had to do backups inside of the guest OS.
Shared VHDX was a version 1.0 technology and improvements were promised. Those improvements arrived with WS2016.
WS2016 replaces shared VHDX with VHD Sets. This is a more complete 2.0 technology. Do not worry if you invested in version 1.0. It is possible to migrate shared VHDX files to VHD Sets using Convert-VHD, which can do an offline conversion.
The headline features are that VHD Sets do support:
- Hot resizing
- Backup from the host level
- Hyper-V Replica using virtual machine groups
The method that appears to be used, is an old one. When you create a VHD Set or a single disk in your mind, two files are created:
- .VHDS: This is the VHD Set file, which is what your virtual machines will connect to.
- .AVHDX: This is the advanced VHDX file or differencing/checkpoint disk, which is where all of your data is actually stored.
Virtual machines connect to the .VHDS file and data is stored in the .AVHDX file. This layer of abstraction is commonly used by Hyper-V. This can be seen in the backups from WS2012 R2. It allows operations to be performed against the data disk without worrying so much about file locks.
If you wish to create a guest cluster on WS2016 Hyper-V or later, then you should use VHD Sets. Create 1 VHD set for each required clustered LUN/volume and attach the VHDS files to each cluster node.