Although hypervisors such as VMware ESX and Microsoft Hyper-V allow virtual machines to be made highly available, some organizations choose to implement high availability at the virtual machine level. In some cases, physical servers running a clustered application may have been converted to virtual machines, resulting in the creation of a guest cluster. In other cases, guest clustering might be created in order to provide an extra layer of protection against interruptions in service availability.
The anatomy of a guest cluster
Like failover clusters built on top of physical hardware, guest clustering often makes use of a cluster shared volume. A cluster shared volume is a shared storage volume that is accessible to all of the clusters' nodes. This allows ever cluster node to have access to the exact same storage resources.
Guest clustering often make use of physical shared storage. A guest cluster might, for instance, use a logical unit number on a Storage Area Network as a cluster shared volume. However, basing a guest cluster's cluster shared volume on physical hardware is not a requirement. Beginning in Windows Server 2012 R2, Microsoft has made it possible to use a shared virtual hard disk (VHD) as the cluster shared volume for a guest cluster that is running on top of Hyper-V.
In some ways, a virtualized node within a guest cluster isn't really configured all that differently than a physical cluster node. A physical cluster node typically makes use of two different storage volumes. One of these volumes is, of course, the cluster shared volume. The other is the boot volume. Similarly, VMs within a guest cluster must be configured with at least two VHDs -- a boot disk and a shared disk.
There aren't really a lot of requirements for the VM's boot disk. The boot disk is a standard -- non-shared -- VHD. This virtual hard disk can be in either VHD or VHDX format.
The requirements for the shared disk are a bit more rigid. First of all, the shared disk must be in VHDX format. VHD files are fine for use as a boot disk, but cannot be used as a shared disk.
There are also some requirements for the guest cluster nodes. The guest cluster nodes can exist as Generation 1 or Generation 2 VMs. While it is theoretically possible to mix and match VM generations within a guest cluster, it is a good idea to be consistent with your use of VM generations.
Another requirement is that the guest operating system must be either Windows Server 2012 or Windows Server 2012 R2. Keep in mind that although Windows Server 2012 is supported on the guest OS, it is not supported for use at the hypervisor level. Furthermore, if you are going to run Windows Server 2012 as the guest OS, then you must install the Windows Server 2012 R2 version of the Integration Services onto the VMs.
Requirements for Hyper-V hosts
Just as there are requirements for the guest OS, your Hyper-V hosts must also adhere to some requirements that go beyond those that have already been mentioned. First, your Hyper-V deployment must be clustered. Microsoft requires a host level cluster, and this cluster is independent of any guest clusters that may exist. The host level cluster must consist of at least two Windows Server 2012 R2 servers that are running the Windows Server Failover Clustering feature and the Hyper-V role.
A second requirement for the Hyper-V hosts is that any hosts within the host cluster must be joined to a common Active Directory domain.
A third requirement is that the Hyper-V hosts must have access to a supported form of shared storage.
If you find these requirements to be slightly confusing, just remember that what you are really doing is building a cluster inside of a cluster. The outer cluster is the Hyper-V cluster. It consists of a series of Hyper-V servers that are also running the Failover Clustering feature. These servers run Windows Server 2012 R2, are joined to a common Active Directory domain and are connected to a cluster shared volume. The cluster shared volume is usually made up of physical storage using something like Windows Storage Spaces. Its job -- in this case -- is to store VHD files.
The inner cluster is the guest cluster. The guest cluster also connects to a cluster shared volume, but this cluster shared volume is a VHDX virtual hard disk. This VHDX file resides on the host's cluster shared volume.
Although you can use a VHD as a cluster shared volume for a guest cluster, there are some restrictions surrounding its use. Microsoft does not support resizing or migrating a shared VHD, nor do they support making backups or replicas of this disk.
How to build a failover cluster in Hyper-V
A closer look at Hyper-V disaster recovery features
Create an SCVMM cluster with Hyper-V nodes