Skip navigation.
Home
latest scoop on virtual machine technology

What's this "quick migration" business; Microsoft confusing you again?

I found Micorosft's recent Live Migration related announcement rather puzzling.

The Register published an article "Microsoft promises VMware beater despite reversals" that everyone should read. You'll get a laugh out of it. I sure did and it started my morning off just right!

Instead of providing details of this bogus idea of "quick migration", the Microsoft rep takes the press to task:

"The recent press has been inaccurate to say we don't do migration - we do migration: quick migration"

Brilliant! Blame the press.

But, what is this quick migration business? I've been looking for details on this topic and I found Microsoft's own definition on a page entitiled "Virtual Server - Quick Migration". Here it is:

This page defines quick migration as:

"Quick Migration simply saves the state of a running virtual machine (memory to disk), moves the storage connectivity from one physical server to another and then restores the virtual machine (disk to memory). This is quick (seconds) - but it will depend on how much memory needs to be written to disk and the speed of the connectivity to the storage. For your reference, a 512Mb virtual machine can be migrated from one server to another in about six seconds using 1Gb iSCSI."

Now I see where the 6 second number in the Microsoft presentation quoted in the Register article is coming from. It appears to just be a technology from their ancient Microsoft Virtual Server product. Let's dissect this a little bit:

  • isn't a 512MB VM is pretty small by todays standards? No database, fileserver or other real workload is going to fit into 512 MB. Heck, even running Vista in that much memory is a painful experience. With a (more typical) memory size of 4GB, the downtime is more than a minute!!!
  • Quick migration is just suspend/resume. We call it cold migration. It's pretty bogus to compare Live Migration (VMotion) to cold migration.
  • This 6 second down time seems to assume a 1Gigabit connection over iSCSI. Usually you don't really get the full 1Gbit on a network so that 6 seconds downtime is, in reality, likely around 8 or 9 seconds.
  • if things go perfectly for a tiny, puny VM, you will still likely get network service timeouts with 6-9 seconds of _downtime_. Nobody from Microsoft seems to be talking about this. But if you are going to run a business on their virtualization stack, you are not going to want to migrate your virtual machines more than once in a blue moon. There's just too much downtime. How would you feel if:
    • File copies fail.
    • Printing stops.
    • ODBC connections fail.
    • TCP window timeouts fire.
    • Citrix users get kicked off.
    • You need to notify end users and schedule the downtime. You don't need to do that with VMware. This stuff doesn't happen with VMotion.
  • you can't really dynamically load balance your cluster with that much downtime per migration. Unless your migration associated downtime is 1 second or less, you're just stuck with your initial VM placement.

Enough said. Decide for yourselves if you still want to call this junk "Quick" migration. It ain't all that quick. I say: "quick", let's "migrate" before they change their minds again! Not that you need to migrate anything real since Microsoft's offering isn't available at this point.

Anyway, VI3 gives you an enterprise tested, proven and hardened VMotion feature on top of which we have a widely deployed dynamic resource scheduler (DRS).