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.
Thread beginning with 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:
2005-07-06

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

Ventajou Member since:
2006-10-31

Thanks for the thorough comment!

I'd say app virtualization might be more easily doable if it ran in a VM itself as with Java or the .Net CLI.

A modified Mono VM for example could keep track of an app's state from the moment it's started. As long as the app is managed the situation would be very similar to that of an OS VM.

Of course the challenge would be that apps need to support moving from a desktop PC to a cell phone. That would mean more work for a developer in order to handle different form factors... Cell phones might be getting better in term of screen resolution, they still require an entirely different UI.

Reply Parent Score: 3

Laurence Member since:
2007-03-26

People seem to be forgetting a couple of important factors with app teleportation:

1/ External references:
If an app is expecting a specific file / directory structure. For example:
* Photoshop / PSP with it's dozens of filters, FX and masks held as plug in files.
* Or sound editing software with it's dozens of VST(i) audio plug ins.

You'd have to copy the GFX plug ins / VST folder (depending on the example) along with the app - which could violate copyright law (in terms of VST(i) plug ins, a lot are worth hundreds of £££ per softsynth / effect bank) and have several hundreds of MB of data to instantly "teleport".
This simply is not doable on either a legal nor technical point of view (legally you can't have several copies of active software so, from a technical perspective, you'd have to move the data from one platform to another each time you "teleport"

Another issue is:
2/ software that expects specific hardware:
* CD burners expecting a CD write,
* BACS software expecting a smart card & reader,
* video conferencing expecting a mic and (web)camera.....
and so on.


So in short, I think the only workable applications for teleportation are for kind of apps that's (for the most part) already available via the interweb cloud (webmail, Google Docs, etc).
Thus we end up back at a bigger question: how much do you trust organisations like Google with your personal data?

Teleporting whole OSs doesn't negate hardware dependencies, but it does resolve point 1/ of this (now lengthy) post.


[edit]

Thinking about it some more: X tunnelling through SSH is probably the closest we have to Thoms dream on current technology.
However I'm not sure how easy it is to transfer an active application from one SSH -X session to another.

Edited 2009-12-01 10:58 UTC

Reply Parent Score: 2