Latest posts by Kyle Beckman (see all)
- Managing shared mailboxes in Office 365 with PowerShell - Thu, May 5 2016
- Managing shared mailboxes in Office 365 with the GUI - Wed, May 4 2016
- Installing and configuring the Enhanced Mitigation Experience Toolkit (EMET) - Wed, Mar 16 2016
In previous versions of Hyper-V, Failover Clusters were only possible if the guest virtual machines had access to some kind of shared storage (like Fiber Channel or iSCSI) on the back end. Organizations running highly available Hyper-V private cloud environments already have shared storage; however, getting access to that shared storage inside of a virtual machine can introduce complexity that some organizations may not want or be able to do in their environment. This can get even more complicated in public cloud scenarios where service providers don’t (or won't) include access to block-level or SMB 3.0 storage from within virtual machines. The introduction of the Shared VHD feature in Windows Server 2012 R2 allows you to create virtual hard disks that can be shared between multiple virtual machines for Failover Clustering.
Physical server requirements ^
For your physical servers, you’ll need two (or more) Windows Server 2012 R2 servers that are in the same Active Directory domain running Hyper-V and Failover Clustering. The servers will need to be configured in a Failover Cluster which means they’ll need some kind of shared storage on the back end for storing both virtual machines and the shared VHD files. This shared storage can be any of the supported back ends for Hyper-V: Cluster Shared Volumes (iSCSI, Fiber Channel, Serial Attached SCSI/SAS, or clustered Storage Spaces using shared SAS) or a Scale-Out File Server.
So why can’t you have a shared VHD and create a Failover Cluster on a standalone Hyper-V server? If you’re going for high availability for a service that is running inside of guest virtual machines, you have to have highly available Hyper-V servers first. If you configure two or more virtual machines in a failover cluster, the cluster is going to fail if your Hyper-V host has problems. What about reboots when patching? You would have to shut down the Failover Cluster to reboot the host server.
If you do try to set up a shared virtual hard disk on an unsupported, un-clustered Hyper-V configuration, you'll get the error, "Error applying Hard Drive changes. Failed to add device "Virtual Hard Disk". The storage where the virtual hard disk is located does not support virtual hard disk sharing."
Failed to add device "Virtual Hard Disk"
In a lab environment, you can get around this by creating a single node Failover Cluster. Just be aware that this configuration will fail a validation check and, most likely, won’t be supported.
Virtual Machine requirements ^
The virtual machines accessing the shared VHD will need to be running at least Windows Server 2012 and can be Generation 1 or Generation 2 VM's. If you choose to use Server 2012 over Server 2012 R2, you’ll need to ensure that the Integration Services have been updated to the latest version when you deploy the OS. All of the virtual machines in the failover cluster must be joined to the same Active Directory domain and have Failover Clustering installed.
Additional Hyper-V considerations ^
A failover cluster can operate with a single network connection, but should one of the hosts in the cluster come under heavy network traffic, that node could fail if it is unable to communicate with the rest of the cluster. You may want to set aside a VLAN on your network for cluster communications. You'll definitely want to involve your network team so they'll be aware of what you're doing. Depending on how your switches are configured, you could cause problems if you start configuring VLAN's in Hyper-V. Have the VLAN ID handy and we'll use it in Part 2.