It’s impossible to have a full discussion of server virtualization without mentioning Quick Migration and Live Migration. These are related but different technologies to move virtual machines between hosts using shared storage and shared high-speed networks. Live Migration is the newer technology. Its key feature is that the unavailability of the VM during the actual move is very short. Subsecond times are not unusual. This time is short enough to keep TCP/IP sessions alive. In other words, anyone using that VM will at most notice a subsecond delay, but everything keeps working.
The ability to move VMs quickly between hosts opens up some interesting scenarios. Let’s say you have at least three of four Hyper-V hosts deployed, and you are running all your VMs on shared storage with Live Migration enabled.
Easier host management Any time you need to do something on a host that requires downtime, you can move all VMs away without downtime for those VMs. Think hardware maintenance like adding memory, patching, and so on.
On-demand resource allocation You may have VMs that are running “hot” and are using a lot of CPU or disk I/O resources. With Live Migration, you can move this VM to a lightly loaded host or, alternatively, get other VMs out of the way instead.
Enabling green IT With Live Migration, you have the potential to shut down lowly used hosts, although in the real world you would need additional tooling to pull this off. The idea is that you move VMs away from lightly used hosts, putting them all on a few hosts that are well
utilized—say, up to 60 percent average CPU time or whatever you prefer. The hosts without VMs can be shut down until they are needed again, with corresponding power savings. All the major server virtualization vendors offer similar features but may use different names. However, shared storage implies SANs, iSCSI, and other storage technologies that we can’t fully discuss here. Still, we’ll cover the basic principles and show you a brief walk-through assuming that you are able to set up the basic storage infrastructure yourself. If you have never worked with remote storage before, we will have some hints to help you along.
Live Migration relies on failover clustering, known as server clustering in Windows 2003 and 2000. Failover clustering is the ability to transfer running applications between hosts, including all their data and current state. This transfer (also known as failover event) can be initiated by the user, but usually a number of conditions are set that should trigger the failover. Dependencies of the application are good examples of such a condition: disks, networks, certain services that should be running, and so on. If any of these goes missing, failover clustering will trigger a failover. An application needs to know that it’s running on a cluster and take action when requested. Well- known examples are SQL Server, Exchange Server, File and Print Services, and so on. You can see where the shared storage comes in: a data disk for an application running on one node needs to go to another node if the application fails over.
Each server taking part in a clustering setup is a node. Since Windows 2008, the maximum number of nodes has been pushed to 16, an increase from 8 in Windows 2003. The main point of failover clustering is to provide high availability: if one host goes down, either planned or unexpectedly, the clustering services ensure that the application is restarted on another node.
An important limitation of Quick Migration in Hyper-V version 1 is that each VM requires its own logical unit (LUN). A LUN is a unit of storage on a SAN that is presented as a single disk to Windows. This leads quickly to drive letter exhaustion and other administrative complications. One of the major changes in Windows 2008 R2 is the introduction of a cluster shared volume (CSV). This is a way to store multiple files on a single LUN, simultaneously shared among two or more hosts. There is a locking mechanism that determines which node actually owns which file. CSV was written with Live Migration in mind, although it also works with Quick Migration. Its main function is to make life easier by simplifying the setup and configuration of a Hyper-V cluster and its VMs.
With failover clustering applied to Hyper-V virtual machines, you actually have two different failover technologies. First, Quick Migration works by saving the state of the VM, transferring control of its disk to another node, and restarting it on that node. This process is predictable and reliable but not so fast that it passes unnoticed. Time is lost during saving and restoring the VM state, which may take up to perhaps a minute for VMs with a lot of memory. Still, this is not a problem during a maintenance window where you need to work on the cluster node(s).
The second technology is Live Migration, called that because it is fast enough to move a VM to another node without loss of service. It works roughly like this; the key difference with Quick Migration is the way the VM memory is transferred:
1.
The migration is initiated. The VM configuration is transferred to the destination host, which builds a skeleton VM.2.
The memory store of the VM is locked, and a difference file is started. All memory changes are written to this file.3.
The memory store of the VM is transferred to the destination node using the shared net- work. Clearly, this network should be as fast as possible. The destination node starts load- ing this memory into the skeleton VM.4.
The first difference file is locked, and a second one is started. The first difference file is trans- ferred to the destination node. This process repeats until the difference files become small.5.
Up to now, the VM keeps running, but at this point, the VM is frozen, and the finaldifference file is transferred as well.