As we discussed in part one of this series, you don't need high-priced tools to create high-availability virtual machines (VMs) with Hyper-V. Instead, you can use Microsoft's Failover Cluster Management, though as noted, it requires some additional manual tasks. And of course, enabling a virtual machine for high availability is only the first step.
You'll need to go through a few extra clicks to ensure that a VM fails over to the desired host by telling a cluster which hosts are the preferred locations for running that virtual machine. They also configure the hosts that are potential targets when a failover is necessary. In this tip, we'll explain how to use the Failover Cluster Management console to configure a VM.
The Failover Cluster Management's console can be confusing. Unlike competitors' high-availability systems, Microsoft's infrastructure runs atop a service designed for multiple uses. This is quite different from VMware vCenter's and Citrix XenServer's interfaces. Architected with virtualization in mind, these virtualization technologies use a more focused set of options. In comparison, Microsoft's technology can cluster Dynamic Host Configuration Protocol or file servers in much the same way it manages Hyper-V. While this can be a boon for supportability, its settings for cluster management are more generic than those for Hyper-V's competition.
Configuring cluster failover settings
Let's assume for this discussion that you've created a four-node cluster exclusively for use by Hyper-V virtual machines. Hosted on this cluster are 40 VMs that are distributed equally among the cluster nodes, with 10 per node. In this configuration, you may want to ensure that certain VMs reside on specific cluster nodes. The VMs should also fail over as a group so that they always reside on the same host.
The first setting you should config...
To continue reading for free, register below or login
To read more you must become a member of SearchServerVirtualization.com
ure that enables VMs to do so is found by viewing the properties of a highly available VM in the Failover Cluster Management console. Under the General tab, you will find the list of preferred owners. This list specifies the hosts selected as the owners for a resource. A cluster will use this list to decide where to re-host resources (such as a VM in this case) during a failover. Multiple hosts can be configured as preferred owners, and an order of preference can be set by reordering host names using the arrow buttons.
Beware that setting a preferred owner will not automatically fail over that resource. Rather, the next time the resource needs to fail over, its target will be based on the selected preference.
Setting the list of preferred owners thus establishes a "wish list" of hosts in the case of a failover. But this list fulfills only part of your needs. The "possible owners" setting can be found under the Advanced Policies tab. Designed to be a superset of the wish list, this second configuration identifies the cluster nodes that can host the resource.
These two settings work together to help identify where virtual machines should go when you invoke a failover or lose a host. In our example of 40 machines spread across four hosts, configuring the possible owners and preferred owners ensures that high-resource VMs don't all fail over to the same location.
Preventing failback
A third potential setting is used after a resource's cluster node comes back online after a failover. Under the Failover tab is the Failback setting with the default setting "prevent failback." When failback is configured, the virtual machine will return back to its original host when that host is again available. If you want virtual machines to return to your known configuration after a host problem, this can be a good thing. But it can also be a source of frustration.
Failback is turned off by default, because enabling it can lead to what is called a "bounce" condition. In this situation, a host becomes unresponsive. The cluster recognizes this as a host failure and fails over its resources. Then the host becomes responsive again. If the cluster is configured to respect failback, its resources will migrate back when that host is available. But in conditions where the host repeatedly becomes unresponsive -- such as when a resource itself causes unresponsiveness -- you'll see resources bounce back and forth until they've hit their threshold limit and are shut down.
This is not a desirable situation for virtual machines, and it is a primary reason why failback is disabled by default. Use such settings wisely, and consider manually re-migrating your VM resources after a failure as a more workable solution.
Because they're designed for use by all sorts of cluster resources, the names of the configurations in the Failover Cluster Management console are a bit obtuse in their meaning. Learning their idiosyncrasies is one of the challenges you'll face if you plan to use Hyper-V without its Virtual Machine Manager tool.
About the author
Greg Shields is an independent author, instructor, Microsoft MVP and IT consultant based in Denver. He is a co-founder of Concentrated Technology LLC and has nearly 15 years of experience in IT architecture and enterprise administration. Shields specializes in Microsoft administration, systems management and monitoring, and virtualization. He is the author of several books, including Windows Server 2008: What's New/What's Changed, available from Sapien Press.
