| |||||||||||||
A look at XenA look at XenPosted Jun 23, 2005 3:26 UTC (Thu) by dcreemer (guest, #5103)In reply to: A look at Xen by yodermk Parent article: A look at Xen 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.
(Log in to post comments)
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.
|
|||||||||||||