Linked by Thom Holwerda on Mon 30th Nov 2009 23:45 UTC
Oracle and SUN Yesterday (today if you're in the US), Sun released the latest version of its virtualisation solution, VirtualBox 3.1. Among speed improvements and other smaller features, the biggest news is that Virtualox 3.1 introduces something called teleportation: you can move running VMs between machines - servers or clients, different architectures, different host operating systems, it doesn't matter to VirtualBox. Coincidentally, this reminded me of an idea I once had about moving running applications between machines.
Permalink for comment 397222
To read all comments associated with this story, please click here.
Teleportation == Live Migration
by Mark Williamson on Tue 1st Dec 2009 01:41 UTC
Mark Williamson
Member since:

This feature is called "live migration" in Xen and KVM/Qemu and vMotion in VMware. Moving a virtual machine's state between different systems is comparatively easy but doing it without pausing the VM for a long time is tricky.

Typically it works like this: you monitor what memory that VM is changing. Then you copy all the VM's memory to the destination machine. Then you check what's changed and recopy that - this will be quicker, because hopefully most of the memory has not changed. Then you check what's changed - again, hopefully less - and just copy that. You do this for a while and then you briefly pause the VM, copy the last of the state whilst it's stopped, then start the copy on the remote machine. The VM does have to be stopped briefly but it can be an imperceptible delay. Once the process is finished you switch off the extra memory monitoring, so that you can get full performance back.

Trouble with this is that it's not instant - you have to wait for a while after requesting the live migration. You can make it go faster by stopping the original VM right away and starting the copy running on the remote system before all the memory has been moved. Each time the remote copy tries to access memory that hasn't been moved yet, it has to wait. Although this looks instant to the user it still takes time and hurts the VM's performance; plus, if *either* machine crashes during the migration then the VM dies, which is a worse failure mode.

If you wanted really low latencies for the operation to complete you'd want to run the copying phase *all the time* so that very little needs to be done when the operator asks for a migration. VMware has a product that does this, Xen has integrated some support for it and there is work in progress to support this with KVM. They're focusing on high availability concerns but I'm looking forward to being able to do my work in a VM on my desktop which continually syncs with my laptop, then just hitting a "move" button and 5 seconds later being able to walk off with the work VM running on the laptop.

Side note: it would be very interesting to do this sort of thing with applications, as Thom describes. It's doable up to a point but believe it or not, that's considered quite a bit harder than migrating a whole virtual machine. Complex as a whole x86 machine is, most OS APIs are far more complicated still. Whatsmore, the state involved is also less well documented and - given people keep extending their OSes - less stable over time. There has been some work on migrating limited kinds of processes on various OSes, it's just that it's really really hard to solve generally for a commodity OS.

Reply Score: 15