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.
17 responses to “Hyper-V Live Migration vs. Quick Migration”
[…] recently published an article comparing VMware VMotion with Microsoft Quick […]
[…] for quick migration. Check out the Video below to see Live migration in action & check out Hyper-V Live migration vs Quick migration post to find out more about the difference between them […]
[…] is the difference between Quick Migration and Live Migration? Check Out Hyper-V Quick Migration vs Live Migration Post. Check Out Hyper-V Live Migration […]
Hi ,
if one of the hyper-v clustered servers suddendly turn off, the active server use the quick migration, right?
Hi Mino,
Sorry to disappoint you, but if one of the hyper-v Clustered servers suddenly crash or removed of power or turned off without properly shutting down Hyper-V, then all the virtual machines will only get restarted on another server if a hyper cluster is setup (Downtime will be involved as the servers get restarted. Its like pulling the power cable of a physical server then putting the power cable again and powering it on right away). And no Quick migration is not involved in this process.
Regards,
Eiad
Hi Eiad,
thanks for your reply.
Ok, if the migration isn’t involved in this process, when to use the quick migration and when to use the live migration.
Thank you for spending your time to answer me.
Hi Mino,
The only reason quick migration existed is because the earlier version of Hyper-V prior to R2 did not have a live migration & VMware had VMotion(Reliable Live Migration) since ages so they wanted a feature that can mislead people to think that they have a live migration. The only reason it seems to stay in there after R2 either it was forgotten or b/c Live Migration in hyper-V is still sloppy. Just remember when using quick migration your virtual machines movement will require downtime, where Live migration will not require a downtime. So you should always look for Live migration to avoid downtime if your environment allow you to do so.
If I may ask why are you playing with Hyper-V rather than VMware ESX. I believe you should give our VMware ESX a try. Let me know if I can provide you with any further help.
Regards,
Eiad
I have tried both. I agree that at the time HyperV is not yet ready for enterprise companies, but only for small and medium-sized, they have little money to invest in virtualization.
I was trying HyperV r2, because one of our customers, having the entire IT system with Microsoft,want to see how it works for virtualization.
Hi Mino,
I am sorry again to get in your business, but you are falling for the biggest mistake most of people falling for when looking at VMware. Who said VMware has to be expensive for SMBs. Actually most SMBs who went for Virtualization are using VMware not Hyper-V. I don’t want to pitch about our features as I am sure you already know of how much better hypervisor and feature we got over hyper-V. If your customers are small & got a little money to spend on Virtualization then VMware is the solution you should offer him as its much easier to administer which definitely a plus for your small customer, but our new acceleration packages for small business are very cheep. They can even beat Hyper-V on the price. Check out this page with our acceleration kit & look at the essential & essential plus kits at http://www.vmware.com/products/vsphere/buy/small_business_editions_comparison.html
Trust me these kits have been priced with small businesses in mind, but still give many more enterprise & reliability features than Hyper-V (specially the essential plus kit). Your SMB customer won’t like to find out that you have treated him differently from your larger customers, where he could got what the bigger guys are using. Let me know if you need any help in this regard.
Before I close up I love one of my colleagues signatures method in this regard. Below is a copy of that as that is exactly what you need to look at:
==================== Signature ======================
Myth Buster
Myth -1 : SMBs don’t need the same reliability and availability as enterprises, so any virtualization engine is good enough
Myth -2: SMBs can save money by going with a “free” hypervisor
Fact: Forrester reports that 74% of the virtualized environments in SMBs run on VMware technologies, find out why at: http://www.vmware.com/solutions/smb/resources.html
===================End of Signature ================
Regards,
Eiad
ok, Eiad, take back your info and we hope that these make the right choice;)
Thanks for everything … and the next opportunity.
Hi Mino,
No problem. keep coming back & let me know how it goes & if you require any further help.
Regards,
Eiad
We are running HyperV R2 since some months and compared to ESX (which I worked with in my former company) it’s
) much easyier to administrate
) Live Migration does not give us any ping loss, while ESX did loose always 1-2 pings
) its free and every Windows 2008 R2 Enterprise License comes with 4 extra licenses for virtual servers
) Not ONE bug so far
I do not see why a company that virtualizes free<) and much less work to administrate and much easier to use.
Used both, never want to go back to ESX (3.5).
Sure ESX has it's strength (especially non windows virtualization) and dynamic memory allocation (which comes with SP1 for 2008 R2), but it's not the wonder product that some like to present it as.
PS: by the way, we are running a 30 node scientific cluster (Linux, GPFS) here too, so it's not like I can only handle a Windows GUI.
Not to forget the hassle free online VSS backup of our HyperV Guests provided by the integrated Windows Backup 🙂
HI Joachim,
I am not sure how are you building your price comparison. If you are going to get what only the standard vSphere edition with vCenter provide you, then you will have to pay for the full System Center Suite.
System Center Suite is actually sold by every Hyper-V R2 server connected to it, so your Hyper-V setup will not be free anymore although your initial cost with an ELA might look like it. Though MS will send you the bill at later stage. Further, the max Hyper-V can match today as features wise is VMware Standard edition which will put them both at the same pricing mark at the moment after the latest VMware schema pricing change.
Further, you are comparing the latest Hyper-V version with ESX 3.5 which at that time Hyper-V did not even have live migration & MS was still suffering to offer anything similar. Look at the many new functionalities vSphere has been leading with. I would leave you with one question to think off, what would happen if a virus or a malware was able to break through to your Windows 2008 base machine & spread as fire as happen with new viruses strikes every now and then. I would not want to be a part of a company running hyper-v at that time, would I?
Regards,
Eiad
[…] Hyper-V Live Migration vs. Quick Migration | Virtualization Team http://www.microsoft.com/downloads/d…displaylang=en […]
@Eiad
We have setup a hyper V R2 cluster. Complety free.
You will need to pay for the VMM, but only if you want to. You can use the cluster manager instead.
We have 2 nodes, completly different hardware, different memory size and even AMD-Intel mix, and still failover VM if a node goes down. The VM will be restarted, but it will do automatically.
Hi Alex,
Well, you still can have VMware ESXi for free as well. You only paying for management and advance features you get.
Mixing Intel & AMD is not a problem in any hypervisor as far the failover go, but it is still a problem for every hypervisor to when it come to live migration which I think you are totally mixing up in here.
With VMware you are really only paying for the extras you get over what other hypervisors could offer you at the moment.
Regards,
Eiad