Live Migration of Linux Desktop

Live Migration of Linux Desktop

[Jun OKAJIMA]

I succeeded to do live migration of Linux desktop just now. It is just
done with # xm migrate without any hack. It was easy but interesting
trial.
Are there somebody who have done same stuff? Or anybody has interest
about this issue?

Well, what I am thinking now is, what is the purpose of this. It is
interesting to do, and would have many feture usage, but has no actual
merit for now. I mean, it is even possible that I transfer my current
desktop to the cambridge Univ in live, but any merit there? I am afraid
that it would be just a geek toy currently. Tell me your ideas of usage.

      --- Okajima, Jun. Tokyo, Japan.

Re: Live Migration of Linux Desktop

[M.A. Williamson]

>I succeeded to do live migration of Linux desktop just now. It is just
>done with # xm migrate without any hack. It was easy but interesting
>trial.
>Are there somebody who have done same stuff? Or anybody has interest
>about this issue?
>
>Well, what I am thinking now is, what is the purpose of this. It is
>interesting to do, and would have many feture usage, but has no actual
>merit for now. I mean, it is even possible that I transfer my current
>desktop to the cambridge Univ in live, but any merit there? I am afraid
>that it would be just a geek toy currently. Tell me your ideas of usage.

For a desktop it doesn't seem so useful: if you're migrating your desktop 
system e.g. from home to work, whilst you travel by car you don't really 
need it to be a "live" migration. Stop and copy would work just as well - 
it'd be completed by the time you get there, and you won't notice the loss 
of interactivity whilst you're away from the console.

The live feature is most useful for datacentres: it gives you the ability 
to move server virtual machines to a less loaded host (load balancing 
across the server room) or use it to evacuate VMs from a host you're going 
to take down for maintenance. In this environment, the VMs may be serving 
your website, or part of your internal infrastructure, or you may be 
renting them out to customers, so you want them to remain live during the 
process - if you had to stop them in this circumstance, migration would be 
much less useful.

Really for "desktop" use, you'd also want some sort of disk technology to 
let you easily transfer just the modified bits of disk between systems, 
automatically. This would enable you to full migrate your "desktop" between 
home and work, whilst maintaining a cache of *most* disk state at both 
sites. It'd also be useful when transferring a virtual machine between your 
desktop and your laptop, for instance.

Cheers,
Mark

Re: Live Migration of Linux Desktop

[Harry Butterworth]

If you were sitting in Red Square accessing your desktop remotely using
a wearable display and a mobile phone and your desktop service provider
needed to service the hardware that happened to be running it then it
would be convenient for them to be able to migrate it without
interrupting your current trading activity.

Or perhaps when you get home to the UK they might need to migrate it
from street-light to street-light so as to keep the network latency down
as you travel around.

Harry

On Mon, 2006-04-03 at 11:08 +0100, M.A. Williamson wrote:
> >I succeeded to do live migration of Linux desktop just now. It is just
> >done with # xm migrate without any hack. It was easy but interesting
> >trial.
> >Are there somebody who have done same stuff? Or anybody has interest
> >about this issue?
> >
> >Well, what I am thinking now is, what is the purpose of this. It is
> >interesting to do, and would have many feture usage, but has no actual
> >merit for now. I mean, it is even possible that I transfer my current
> >desktop to the cambridge Univ in live, but any merit there? I am afraid
> >that it would be just a geek toy currently. Tell me your ideas of usage.
> 
> For a desktop it doesn't seem so useful: if you're migrating your desktop 
> system e.g. from home to work, whilst you travel by car you don't really 
> need it to be a "live" migration. Stop and copy would work just as well - 
> it'd be completed by the time you get there, and you won't notice the loss 
> of interactivity whilst you're away from the console.
> 
> The live feature is most useful for datacentres: it gives you the ability 
> to move server virtual machines to a less loaded host (load balancing 
> across the server room) or use it to evacuate VMs from a host you're going 
> to take down for maintenance. In this environment, the VMs may be serving 
> your website, or part of your internal infrastructure, or you may be 
> renting them out to customers, so you want them to remain live during the 
> process - if you had to stop them in this circumstance, migration would be 
> much less useful.
> 
> Really for "desktop" use, you'd also want some sort of disk technology to 
> let you easily transfer just the modified bits of disk between systems, 
> automatically. This would enable you to full migrate your "desktop" between 
> home and work, whilst maintaining a cache of *most* disk state at both 
> sites. It'd also be useful when transferring a virtual machine between your 
> desktop and your laptop, for instance.
> 
> Cheers,
> Mark
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

Re: Live Migration of Linux Desktop

[Jun OKAJIMA]

>It'd also be useful when transferring a virtual machine between your 
>desktop and your laptop, for instance.
>

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.


            --- Okajima, Jun. Tokyo, Japan.

Re: Live Migration of Linux Desktop

[M.A. Williamson]

> 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

Re: Live Migration of Linux Desktop

[Thorolf Godawa]

Hi,

> migrate your "desktop" between home and work, whilst maintaining a 
> cache of *most* disk state at both sites. It'd also be useful when 
> transferring a virtual machine between your desktop and your laptop, 
> for instance. 
there are just some "little" problems:

During migration between two different platforms it can often happen, 
depending on the CPU-type and actual CPU-state that the migration fails 
and the VM on the destination-system crashes.

Second problem is that for migration you need a shared device for the 
image. You can use the harddrive of laptop for sharing via NFS but 
actually it's not very usefull because then you can directly work on the 
laptop.

And the other scenario, making snapshots in some interval is not the 
best idea too, because the saved CPU- and memory-state and the actual 
harddisc-content you have later are out of sync. With this everything 
between data-loss and machine-crash is possible!
-- 

Chau y hasta luego,

Thorolf

Re: Live Migration of Linux Desktop

[Mark Williamson]

> > migrate your "desktop" between home and work, whilst maintaining a
> > cache of *most* disk state at both sites. It'd also be useful when
> > transferring a virtual machine between your desktop and your laptop,
> > for instance.
>
> there are just some "little" problems:
>
> During migration between two different platforms it can often happen,
> depending on the CPU-type and actual CPU-state that the migration fails
> and the VM on the destination-system crashes.

Yep, you'd want a combination of machines that were compatible.  I think most 
recent Pentiums share similar instruction sets, but I think maybe Pentium M 
omits a couple of P4 instructions (anybody know?).  Athlon <-> Pentium 
migrations are yet more dodgy!

A way to disable a subset of the hardware features to restrict software to use 
only the features on all your hardware platforms would be very welcome.

> Second problem is that for migration you need a shared device for the
> image. You can use the harddrive of laptop for sharing via NFS but
> actually it's not very usefull because then you can directly work on the
> laptop.

Well, all you really need is some means (e.g. rsync, or something more 
efficient) of transferring changed disk blocks at the same time as the 
migration.  For a "I'm driving to work" migration this doesn't even need to 
be very fast, just pause the VM, send its memory state and then run an rsync.  
We don't have a hook for this state transfer to occur on at the moment, but a 
simple solution could easily be added - a more complete solution would be 
more complicated but could also be done.

> And the other scenario, making snapshots in some interval is not the
> best idea too, because the saved CPU- and memory-state and the actual
> harddisc-content you have later are out of sync. With this everything
> between data-loss and machine-crash is possible!

Snapshots are fine so long as you make them coherent before you try to run 
them.  I was envisioning snapshotting periodically from the active to the 
inactive host just to keep the state *mostly* consistent.  You'd do a full 
sync on demand when the user actually wanted a migration to occur.  You 
wouldn't usually want this behaviour because it'd waste network bandwidth and 
other resources.  But if (for instance) you wanted to be able to "migrate" 
your work VM from your desktop to your laptop in a few seconds, you might run 
the sync continually as a background task to minimize the time required to 
make everything coherent when you eventually do click "sync to laptop".

For the more general case of hardware fault tolerance, you'd need a more 
sophisticated snapshot mechanism so that you could guarantee the replica 
could resume from a consistent state at any time.  Doing this (and especially 
doing this efficiently!) is a bit more tricky.  I've heard of it being done 
on a PA-RISC based hypervisor for HP-UX, but not on a mainstream x86 
hypervisor AFAIK.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!