Posted by: Anonymous Coward
on July 28, 2006 08:57 PM
The virtual machine to be migrated is a Xen domU instance. When migration is started , a new Xen instance is fired up on the target hardware, which forms a "container" for the instance to be migrated to.
Once this is prepared, the xen kernel is then instructed to migrate, and it begins a memory copy to the target, which is not in a "running" state - i.e. it's virtual CPU is halted. The memory copy is cyclical - once it completes it goes back to the beginning, and copies any pages that have been modified since it started - this happens repeatedly until Xen notices that the set of dirt pages in each cycle is no longer shriking substantially.
After the cyclic memory copy reaches a point of diminishing returns, the source Xen instance is halted. With this done, a final memory copy occurs, which cleans up the last few dirty pages. The target container now contains a full memory image of the instance, and has access to the same storage via a SAN or something. This instance is then started.
The dom0 kernels deal with taking down the IP address on the source machine and bringing it up on the target. There isn't any problem with device drivers, as they're all virtualised anyway as far as domU instances are concerned. the final phase of migration, where both instances are in a halted state, typically takes 50ms. XenSource tested it by doing live migrations on a public Quake server, and players couldn't see it happen.