Live Migration in Hyper-V R2

Greg Shields

Nowhere is this more noticeable than in the improvements to Microsoft's Hyper-V. Rising from an astonishingly feature-complete version 1.0 that arrived shortly after the release of Windows Server 2008, Microsoft is poised to reach new heights with its improvements to Hyper-V in Windows Server 2008 R2. One of the most anticipated improvements to Hyper-V version 2.0 is an upgrade from Quick Migration to a fully functional Live Migration feature set. This tip covers the differences between Quick Migration and Live Migration and how to get started with Live Migration for VM host relocation with zero downtime.

Hyper-V's initial release enabled a Hyper-V virtual machine to be relocated from one virtual host to another with minimum downtime, a feature known as Quick Migration. The downtime was directly related to the amount of memory assigned to the VM, along with the speed of the connection between virtual hosts and shared storage. VMs with higher levels of assigned virtual memory and slow networks took longer to complete a migration from one host to another, while those with less virtual memory and faster networks could complete a migration in less time.

For example, a VM with 2 GB of memory that runs on top of a 1 Gigabit Ethernet iSCSI connection takes upward of 32 seconds to complete a host-to-host migration. Although a VM in the process of being migrated technically never has to restart or power down, it is unavailable during the migration. During this period, the VM will not respond to clients or be available on the network.

For many environments, 32 seconds of downtime is too long . VM migrations that involve this amount of downtime exceed the typical norms for client timeouts, which means that many clients will experience a migration as an outage. For environments with high-availability needs, this is unacceptable.

With Live Migration, however, the length of downtime for a migration has been effectively reduced to zero. Although a slight delay occurs -- similar to the delay during a VMotion event with VMware ESX -- it's insignificant and doesn't affect the clients on the network.

Quick Migration in Hyper-V's version 1.0 and Live Migration in Hyper-V's version 2.0 require Hyper-V to be installed on servers that host the Windows Server Failover Clustering feature. What is not widely understood is that the cluster itself contains most of the technology responsible for failover from virtual host to virtual host. As a result, this "new Hyper-V feature" is as much a new set of clustering features as it is an improvement on core virtualization capabilities.

Perhaps the biggest difference between the two functionalities, though, is the process by which the migrations take place. Let's start with Quick Migration. At the point when Quick Migration is initiated, a VM is immediately placed in a saved state. The saved state is not a power-down, nor is it the same as a paused state. In the saved state, a VM releases its memory reservation on the host machine and stores the contents of its memory pages to disk. Once this has been completed, the target host can take over ownership of a VM and bring it back into operation. With Quick Migration, putting the VM in a saved state is with the most time-consuming aspect of a migration.

To reduce this delay, Microsoft developed a mechanism that would pre-copy a VM's memory from the source to the target host. At the same time, the pre-copy logged changes to memory pages that occur during the copy period. Live Migration addresses these needs. Although the changes themselves are relatively few in number, they make the delta copy significantly smaller -- and thus faster -- than the original copy. Once the initial copy is completed, Live Migration pauses the VM, copies the memory deltas and then transfers ownership to the target host. Since the amount of data being transferred during the VM's outage is significantly smaller, the time required to complete the transfer is dramatically reduced.

• Install Windows Server 2008 R2 on two or more servers that will host Hyper-V virtual machines.
• Enable the Windows Server Failover Clustering feature on each server. Failover Clustering has specific requirements for hardware and network configuration. For full support, each component that comprises your cluster should be certified by Microsoft. The Windows Server Catalog.
features additional information on this certification.
• Configure your nodes as a Failover Cluster. Doing so requires passing each of the tests in the built-in Validate a Cluster configuration wizard.
• Configure connected shared storage as Cluster Shared Volumes (CSVs). This is done in R2's Failover Cluster Manager by navigating to CSVs and adding the appropriate storage. Cluster Shared Volumes is a new technology in R2 and is one of the major reasons why Windows Failover Clustering works so well. I'll discuss Cluster Shared Volumes further in another article, but for now be aware that CSVs enable multiple cluster nodes to better identify which node owns which files and folders in a disk resource.
• Set up cluster networks for Live Migration. Live Migration needs a high-speed, isolated network to transfer memory pages between cluster nodes. R2's Failover Cluster Manager includes the ability to identify a network resource as a "network for live migration".
• Build virtual machines and test Live Migration. Once these steps are complete, build a new VM and attempt to migrate it to another server from within the Failover Cluster Manager console.

"Hyper-V: Step-by-Step Guide to Using Live Migration in Windows Server 2008 R2" offers detailed information on each step. Also, if you're unfamiliar with the basics of Windows Failover Clustering, you should read Microsoft's "Getting Started: Failover Clustering" guide.

So even with all these new features in Hyper-V version 2.0, virtualization in my mind still isn't as sexy as it used to be. But it remains exciting and Hyper-V 2.0 has the potential for major impact on your data center. With R2's upgrades to Hyper-V and Failover Clustering, Microsoft is bringing feature parity to a market full of similar -- and soon to be commonplace -- technologies.

Greg Shields, MCSE, is an independent author and consultant based in Denver with many years of IT architecture and enterprise administration experience. He is an IT trainer and speaker on such IT topics as Microsoft administration, systems management and monitoring, and virtualization. His recent book Windows Server 2008: What's New/What's Changed is available from Sapien Press.