This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Live Migration of Linux Desktop

This seems good. The situation would be like this: You have to go out the office 2:00 PM for making a presentation on the conference on 3:00 PM. And you need to finish making slides before goint out. It is very usual that you get finished the work up to the moment you have to go out. Then, in that moment, you must want to migrate your desktop to a laptop PC *IN LIVE*!, because you have no time to wait suspend-resume sequence.

Bear in mind that live migration is *slower* (though not necessarily significantly, I don't actually have numbers for non-live migration) in terms of latency than non-live migration. This is because it has to pre-copy data whilst the guest OS is running and may need to copy data several times as the guest writes to memory. Live mode also tries to save network bandwidth, which will make the migrate happen slower.

Live migration is "live" because the *downtime* of the virtual machine is low, but the actual state transfer still takes quite some time - it just occurs mostly whilst the VM is running.

If you don't actually need interactivity *during* the migration you're better off doing non-live (not the same as suspend / resume, since the guest state will be copied to the other host automatically in the process) migration.

If you were in a hurry you'd want to use non-live migration for this scenario.

As an extension you might want to modify the migration code to continually update the state of a domain on the target machine to look like that on the origin. This could be used to keep your laptop permanently *almost* in sync with the domain on your desktop, so that you could finally sync the migration process at the push of a button - this should work almost instantaneously because most of the data is already transferred. A more advanced version of this would be to do failover to provide robustness to hardware failures using this technique - it's something we've talked about...


Xen-devel mailing list