Live Migrate a GuestVM

Stage 0: Pre-Migration We begin with an active VM on physical host A. To speed any future migration, a target host may be preselected where the resources required to receive migration will be guaranteed.

Stage 1: Reservation A request is issued to migrate an OS from host A to host B. We initially conrm that the necessary resources are available on B and reserve a
VM container of that size. Failure to secure resources here means that the VM simply continues to run on A unaffected.

Stage 2: Iterative Pre-Copy During the rst iteration, all pages are transferred from A to B. Subsequent iterations copy only those pages dirtied during the previous
transfer phase.

Stage 3: Stop-and-Copy We suspend the running OS instance at A and redirect its network trafc to B. As
described earlier, CPU state and any remaining inconsistent memory pages are then transferred. At the end of this stage there is a consistent suspended copy of
the VM at both A and B. The copy at A is still considered to be primary and is resumed in case of failure.

Stage 4: Commitment Host B indicates to A that it has successfully received a consistent OS image. Host A acknowledges this message as commitment of the migration
transaction: host A may now discard the original VM, and host B becomes the primary host.

Stage 5: Activation The migrated VM on B is now activated. Post-migration code runs to reattach device drivers to the new machine and advertise moved IP addresses.

Check this paper:

• Live Migration of Virtual Machines describes our techniques for achieving low overhead migration of active virtual machines betweenphysical hosts. Pre-print of paper to be published at NSDI 2005..