VirtualizationTeam (Blog)

As we find out more about Windows Server Virtualization, it is only natural to start having doubts about its features. One of the most famous is Live/Quick Migration.

I would therefore like to spend some time clarifying everything I can about this subject.

First of all, Quick and Live Migration are not the same thing. They are not synonymous or interchangeable terms. Quick Migration is completely different from Live Migration.

The WSV RTM will have Quick Migration available right away while Live Migration (which is the equivalent of VMware VMotion) will be ready in an update a few months after WSV RTM.

While both are used to “move” a VM from one host to another, each one does so in a different way and at a different time. Live Migration can start a VM on another host in less than a second while Quick Migration needs more time, which depends on the amount of RAM in the VM and the connection speed to the storage.

Now that the distinction has been made, we’re going to elaborate on each of them.

Quick Migration

Basically, it works in three steps:

1. The machine is put in “Saved” state.
2. The VM is taken by another host
3. The VM is reset.

The speed of Quick Migration does not depend on the size of the VM (size of the VHD). The following table shows the average time it takes for Quick Migration to “move” a VM:

VM Memory	1 GbE iSCSI	2 Gb FC	4 Gb FC
512 MB	~8 seconds	~4 seconds	~2 seconds
1 GB	~16 seconds	~8 seconds	~4 seconds
2 GB	~32 seconds	~16 seconds	~8 seconds
4 GB	~64 seconds	~32 seconds	~16 seconds
8 GB	~2 minutes	~64 seconds	~32 seconds

The requirements for Quick Migration are:

1. Windows Server 2008 Enterprise or Datacenter x64 Editions in the parent partition. The host must use Windows Server 2008 Enterprise or Datacenter x64 Edition because Quick Migration requires Windows Server Cluster, which is only available in Windows Server 2008 Enterprise and Datacenter.

2. Shared Storage. The Quick Migration of a VM from one server to another requires shared storage such as SAN (iSCSI or Fiber Channel) or NAS. Be careful because Windows Server 2008 does not support more clusters with SCSI.

Live Migration Basics

The requirements for Live Migration are similar to those for Quick Migration. The following is a rough description of the Live Migration process:

1. Pre-flight Migration. Can migration be secure and reliable?

a) Yes, migration can be and is safe.

b) If any risk or problem is detected, migration cannot occur.

2. VM Transfer.

a) Copy the VM configuration and create the worker process in the other host.

b) Move the memory pages from the current host to the new one. First move all the inactive pages you can to reduce the number of pages as much as possible.

3. Final transfer and start-up of the VM. Ideally at this point, there is a very small set of pages saved to the VM as almost all the other ones were moved to another host. The remaining few are in active state. For the final step, pause the machine, move it from one host to another, and then turn it on. Move the storage connectivity from one server to the other and it’s ready.

Live Migration in detail

1. Pre-flight Migration: The first step in Live Migration occurs in the source host (where the VM is currently running) and the in the destination host (where the VM will be moved) to ensure that migration can in fact occur.

The detailed steps are as follows:

1. Identify the source and destination machines.

2. Establish a network connection between the two hosts.

3. Check of the various resources available:

i) Are the processors similar in terms of internal architecture? (a VM in Intel cannot be moved to AMD and vice versa)

ii) Is there enough RAM available in the destination?

iii) Is there sufficient CPU available at the destination?

iv) Is there access to required global resources (vhd, network, etc.)?

v) Is there access to physical resources for devices that must remain associated with the VM after migration? In other words, the CD drives, DVDs and LUN or offline disks needed for re-association should to be available.

If there are any problems during the pre-flight stage, migration cannot occur. The VM will stay where it is and will continue running as usual, as if no migration had occurred.

If pre-flight is successful, migration can occur. Go on to Step 2.

2. VM Transfer: Now that you know that Live Migration can occur safely, the actual migration process can begin. This step will move the VM state (inactive pages) in order to reduce the active VM as much as possible, leaving behind a small working set of the VM.

Copy the VM configuration and device information to the destination and create the worker process. Then, transfer the VM memory to the destination while the VM is still running. Memory writes are intercepted and used to track actions that occur during migration. This page will be re-transmitted later.

3. Final transfer and start-up of the VM: Now that you are almost done and most of the VM has been moved, it is time to complete the migration. What remains of the VM is paused; the VM is then transferred to another host; access to storage is moved from one host to the other, and the VM is reset in the destination host.

While all this is going on, what happens to applications attempting to access the VM that is being migrated?

First, it is important to understand why IT managers are looking to move a VM. The vast majority need this feature to perform preventive and scheduled maintenance of the hosts. In addition, this work should not be performed during peak hours, even with Live Migration. This means that, in most cases, a difference of >1 to 30 seconds is not too great when migration is programmed.

Anyways, let’s focus on the subject at hand:

Live Migration: As Live Migration is seen as a process that takes less than one second, this generally has no impact on the VM service. TCP/IP can tolerate minimal cuts, and continue to relay without the user even noticing.

Quick Migration: Here the answer is more ambiguous: “It depends”. The reality is that it depends on how the client application supports connection cuts. Some applications use cache, which tolerates a few seconds of cuts, while others do not. If the application is well-designed and anticipates possible problems, there shouldn’t be any problems experiencing cuts up to 15 seconds long.

So, the best thing to do is to test the applications that will eventually run in virtual servers with Quick Migration and see what happens. Then, in a physical server with the installed application, run it and use it to perform an action. Mid-way through the process, disconnect the network cable, count to 10, restore it, and see what happens.

Thanks to Ponicke for inspiring this article.

 Subscribe to our burning feeds