When customers say they want Hyper-V high availability (HA) in their infrastructure, the solution provider's next step is to ensure that certain requirements are met and that the HA solution is implemented properly. But before any Hyper-V HA implementation takes place, important factors-- such as the number of spare hosts needed -- should be considered.
Hyper-V expert Greg Shields explains whether Cluster Shared Volumes (CSVs) are necessary when adding HA to a customer's Hyper-V environment, a determination that may depend on the failover capability requirements.
•When spec'ing out a client's Hyper-V cluster, should I include "spare" hosts? How many?
• I'm thinking about adding high-availability to a client's Hyper-V infrastructure. Is using Cluster Shared Volumes a requirement? Is it a good idea?
• If my client doesn't have Systems Center Virtual Machine Manager (VMM), what is the Windows Failover Clustering PowerShell cmdlet that will invoke a live migration?
• Sometimes my clients need to quickly migrate every virtual machine off a Hyper-V host. Is there a simple command I can give them to do this?
• I've been finishing up the implementation of a client's Hyper-V cluster, and I'm finding that some settings are not present when VMs change hosts. What have I done wrong?
• I've completed building a client's highly available Hyper-V R2 infrastructure and want to see if it meets Microsoft's best practices. Is there a quick way to accomplish this?
• More on Hyper-V high availability
• About the expert
A: Until Microsoft releases Windows Server 2008 R2 SP1, we won't have the new dynamic memory feature. That feature enables greater flexibility in terms of how RAM is assigned to and used by virtual machines (VMs). This service pack is soon to arrive, but until it does, you should always consider incorporating one "spare" host in your Hyper-V cluster. While VMs in a Hyper-V cluster will most surely be spread across every host, the capacity provided by the spare host ensures that enough RAM is available so that a single host can fail. Without the capacity associated with that spare host, not enough RAM will be available to fail over every VM.
A: "No" and "maybe," in that order. Cluster Shared Volumes (CSVs) is a new feature in Windows Server 2008 R2. In short, by running virtual machines on a CSV-enabled volume, it becomes possible to fail over those VMs individually. Without CSV, an entire disk resource -- along with all the VMs on that resource -- must be failed over at once. Most clients want individual failover capability because it provides the granularity they need during failure or pre-failure events.
However, CSV also introduces a set of complexities all its own. The greatest of these is in interoperability with some kinds of VM backup solutions. Not all VM backup solutions currently support CSV-enabled volumes. Before turning this feature on, make sure you've got full support first.
A: Without VMM, you won't have access to the Move-VM cmdlet, which invokes a live migration between hosts. So, you'll need a cmdlet that works with the Windows Failover Clustering feature directly. You can get this with a combination of Get-Cluster and Move-ClusterVirtualMachineRole cmdlets. First, import the PowerShell module that manages Windows Failover Clustering with
Then, use the following command to move a VM group to a new cluster node:
Get-Cluster "<Cluster Name>" | Move-ClusterVirtualMachineRole -Name "<VM group name>" -Node ""<Destination node name>"
A: If you're using VMM, there is. All by itself, Hyper-V doesn't include a set of PowerShell cmdlets that are terribly easy to use. Without VMM, Hyper-V's PowerShell exposure is limited to the methods and properties that can be invoked within Windows Management Instrumentation (WMI). Those cmdlets can be challenging to construct when you need them quickly.
VMM, on the other hand, comes equipped with a usable set of cmdlets for moving VMs. One of the simplest moves every VM from one host to another. It looks like this:
Get-VM –server HostA | Move-VM –server HostB
A: Most of a Hyper-V's configuration happens during its initial setup. Once that setup is complete, most VMs merrily complete their tasks with little extra effort. So, during any client engagement where setup is required, it is important to be careful not only with what you're changing but also where you're changing it.
Configuration of clustered VMs should always be done using the Windows Failover Cluster console or through VMM rather than through the Hyper-V Manager. Making configurations in these locations ensures that cluster resources remain in sync and present as VMs move between hosts.
A: There is by using Windows Server's built-in Best Practices Analyzer (BPA). The BPA is a native part of the Windows operating system and can be invoked either through the Server Manager console or through PowerShell.
The BPA uses downloadable modules that include the "rules" for each Windows role and associated best practices. For Hyper-V in Windows Server 2008 R2, you'll first want to download and install the BPA module. This module includes a set of updates to ensure you've got the most recent suggestions from Microsoft. Once installed, navigate to Roles | Hyper-V in Server Manager and then scroll down to the Best Practices Analyzer. There, click Scan This Role and wait for the results.
About the author
Greg Shields, MVP, vExpert, is a partner with Concentrated Technology. Get more of Greg's tips and tricks at www.concentratedtech.com.