| |||||||||||||
A look at XenA look at XenPosted Jun 23, 2005 2:07 UTC (Thu) by yodermk (subscriber, #3803)Parent article: A look at Xen
>>> Crosby said that it's possible to move a Xen virtual machine "so that the guest is only non-responsive to the outside world for tens of miliseconds."
That sounds great, but I'm not sure I believe it. Wouldn't it take at least a few seconds to transfer an image to another box over 100 megabit ethernet?
Also, I read very briefly in a comment somewhere else that next-gen chips from Intel and AMD would allow for full virtualization without a modified guest, just as mainframes have done for decades. Does anyone know more about this and when they will come out? Will Xen support them right off the bat?
(Log in to post comments)
A look at Xen Posted Jun 23, 2005 3:26 UTC (Thu) by dcreemer (guest, #5103) [Link] Xen guest VM migration between hosts completes very quickly. The actual transfer takes longer, but the VM stays running on the source machine as long as possible. It only (usually) takes less than a second to stop the VM on the source host, transfer any remaining differences, then bring up the VM on the target machine.
A look at Xen Posted Jun 23, 2005 18:04 UTC (Thu) by patha (subscriber, #6986) [Link] > It only (usually) takes less than a second to stop the VM on the source host, transfer any remaining differences, [...]
Does this also holds for a machine with 64GB RAM running GUPS (http://www.dgate.org/~brg/files/dis/gups/) all over the memory? ;)
Seriously, were can I read about how the step "transfer any remaining differences" is implemented?
A look at Xen Posted Jun 30, 2005 14:32 UTC (Thu) by MarkWilliamson (guest, #30166) [Link] For details of live migration see:http://www.cl.cam.ac.uk/netos/papers/2005-migration-nsdi-... Other papers under: http://www.cl.cam.ac.uk/Research/SRG/netos/xen/architectu... If you run software that dirties large amounts of memory then the precopy approach doesn't work very well: in this case, the live migration code will figure it out and cuts its losses by doing "stop and copy" - incurring a longer stoppage but more efficient use of network bandwidth. For real world server workloads it works well: Running Quake 3 servers incurred a downtime of about 60ms (I think), whilst an Apache webserver running SpecWeb incurred a downtime of 300ms and didn't drop any clients.
A look at Xen Posted Jun 24, 2005 22:24 UTC (Fri) by erich (subscriber, #7127) [Link] Hi,according to talk recently at BaLUG, they copy and note which pages have become "dirty" in the meantime, after a few cycles they then stop the vm and migrate the rest over, start it on the new one. According to them, they've done that with a Quake3 server without the users noticing much. That sounds really impressive. Apparently "downtimes" of ~200ms is typical when you have a 100Mbit link between the two hosting machines.
A look at Xen Posted Jun 26, 2005 8:40 UTC (Sun) by csamuel (✭ supporter ✭, #2624) [Link] Both Intel and AMD have made public declarations of support for Xen with respect to their virtualisation technology.
It's this which will make it possible to run unmodified OS's under Xen in the future (fingers crossed)..
Chris
|
|||||||||||||