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

["M.A. Williamson" <maw48@xxxxxxxxx>]

> 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...
Cheers,
Mark

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel