This blog discusses running a Windows Server Failover Cluster (WSFC) in a Virtual Machine (VM) on top of a Hyper-V host. Running a cluster in a virtualized environment is commonly referred to as "Guest Clustering". Guest Clustering provides two key values:
1. Application Health Monitoring – Enables health monitoring of applications running within a VM. For example; if SQL Server is placed in a VM then the health state of SQL will be monitored to ensure it is functional and take recovery actions if the SQL instance were to crash or hang.
2. Application mobility – Allows applications to failover from one VM to another VM. For example; if you need to patch the guest operating system you can move the application to another VM and reduce downtime.
It is supported by Microsoft to run Failover Clustering in a virtualized environment with Windows Server 2008 R2 Hyper-V; however the support policy varies for different guest OS versions.
It is not supported by Microsoft to run a guest cluster with the Microsoft Cluster Service (MSCS) on Windows NT Server 4.0, Windows 2000 Server, or Windows Server 2003.
It is supported by Microsoft to run Windows Server 2008 and Windows Server 2008 R2 as a guest cluster. In order for a solution to be supported by Microsoft all individual components must have a Windows logo, and the solution must pass the cluster Validation tool. The full support policy is documented here: http://technet.microsoft.com/en-us/library/cc732035(WS.10).aspx
In particular see the "Virtualized servers" section here: http://technet.microsoft.com/en-us/library/cc732035(WS.10).aspx#BKMK_validation_scenarios
Guest OS Version
Windows Server 2008
Windows Server 2008 R2
Windows NT Server 4.0
Windows 2000 Server
Windows Server 2003
· Storage – It is only supported to do guest clustering on a Hyper-V host using iSCSI based storage connected from the guest with the Microsoft iSCSI Software Initiator.
· Exchange Server – Running Exchange Server in a virtualized environment has some additional considerations, including that it is not supported to configure Exchange high availability features on a mobile VM (where the VM may move to another host via failover, quick migration, or live migration). See this document for additional information: http://technet.microsoft.com/en-us/library/cc794548(EXCHG.80).aspx
· It is supported to mix physical and virtual nodes in the same cluster, however all nodes in the cluster must be running the same OS version and the entire solution must pass Validate (per normal support policy).
· There are no restrictions on the number of nodes in the guest cluster (can be up to 16-nodes)
· Affinity – It is recommended that the nodes of a guest cluster should reside on different hosts to achieve the highest levels of availability. If a host were to crash, having VM’s associated with the same guest cluster distributed across multiple hosts will enable applications to recover faster. To accomplish this, configure the cluster group property AntiAffinityClassName. The host cluster will attempt to keep VM’s with a consistent string value (such as the VM name) off the same host. See this KB for additional details: http://support.microsoft.com/kb/296799
· Heartbeat Thresholds – It may be necessary to increase the cluster heartbeat thresholds of a guest cluster when a mobile guest VM node is being moved to a new host, through a process such as live migration. During the migration of the VM it will be temporarily unavailable for a brief period of time which cluster health detection may detect, increasing the thresholds will mitigate clustering assuming the node is down and incorrectly taking recovery actions. This can be accomplished by increasing the SameSubnetThreshold and SameSubnetDelay cluster common properties. See this document for additional details: http://technet.microsoft.com/en-us/library/dd197562(WS.10).aspx