Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6
The buzz in the industry right now is all about virtualization. Virtualization vendors are jockeying for position and each one touts the features the others are not supposed to have. One of these is a feature every hypervisor should have and one that Windows Server 2008 Hyper-V seems to be without in this version: live virtual machine (VM) migration. Live migration in a virtual environment does not mean migration from one state to another, such as migrating a physical machine to a virtual state. It means moving a VM from one host server to another while the VM is running and delivering service to end users without interrupting the service.
In order to move virtual machines in this manner, you need to make sure that each host server has access to the files that make it up. When you move a VM through live migration, you don't want to have to move the files that make it up since those can be considerable in size. Instead, you want to move only the in-memory contents of the virtual machine -- contents that are stored within the host server's memory.
Both VMware ESXi and Citrix XenServer have the ability to do this, and both use the same strategy. Generally, host servers are linked together in high-availability clusters or resource pools. The servers tie into the same shared storage container and because of this, they have immediate access to the files that make up the VM during such a move. This is the first rule of host servers: They must be configured to tie into shared storage in order to provide high availability for the virtual machines they host (see Figure 1).
Figure 1 (click to enlarge)
Microsoft's Hyper-V does not support live migration. Instead it supports Quick Migration -- a feature that saves the state of a VM and moves it to another host. Because the state of the virtual machine is saved, there is an interruption in service, even though in some host server configurations this interruption can be as minimal as four seconds.
Hyper-V provides this feature through Windows Server 2008's Failover Clustering service, where host server nodes are linked together into a failover cluster. These clusters can provide host server redundancy at the site level when two or more nodes -- Windows Server 2008 can create clusters of up to 16 nodes -- are linked to shared storage, or at the multi-site level when two or more nodes are joined through WAN links to provide redundant services should damage occur at the site level (see Figure 2).
Multi-site failover is based on each cluster node having the same contents as the other. This is achieved through content replication, a feature that Windows Server 2008 does not offer -- you get it through a third-party replication tool. Despite this, multi-site clustering is available by default for Hyper-V. Other hypervisors do not offer this out of the box.
Figure 2 (click to enlarge)
Windows Failover Clustering and Network Load Balancing (NLB) are two features that have been part of Windows Server since Windows NT (though NLB was called Windows Load Balancing at the time). These two features are mutually exclusive, but both provide high availability to some degree. Failover clustering is mostly used for the protection of stateful workloads or workloads that must commit changes to data, such as SQL Server or the Mailbox Server role in Exchange Server. Network load balancing clusters are created for workloads that are stateless or read-only. A good candidate for NLB is the Web server, especially when it is used as a front end to an n-tier application.
If you are running Windows workloads in virtual machines and you want to make sure those workloads are always highly available no matter which hypervisor you use, you can and should configure them to use either Windows Failover Clustering or Network Load Balancing. In addition, you can configure non-affinity policies to make sure that each node of a cluster does not reside on the same host server. Then, if a failure occurs either at the VM or the host level, your workloads are automatically failed over without any service interruption to end users (see Figure 3).
Figure 3 (click to enlarge)
So, is it essential for Microsoft Hyper-V to have live migration? The answer is no, not at this time. Most organizations running Hyper-V as a hypervisor will also run Windows workloads in their virtual machines. By relying on Windows Server 2008's own internal features, it's easy for administrators to make sure there are no service interruptions to end users, no matter what happens to the host server. It doesn't work for every Windows workload, but it does for most of them, and as a proven technology, it works really well.
Danielle Ruest and Nelson Ruest are IT professionals specializing in systems administration, migration planning, software management and architecture design. Danielle is Microsoft MVP in Virtualization and Nelson is Microsoft MVP in Windows Server. They are authors of multiple books, including the free 
