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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
>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
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > 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! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel