Migration (virtualization)

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Migration" virtualization – news · newspapers · books · scholar · JSTOR (December 2014) (Learn how and when to remove this message)

In the context of virtualization, where a guest simulation of an entire computer is actually merely a software virtual machine (VM) running on a host computer under a hypervisor, migration (also known as teleportation,^[1] also known as live migration) is the process by which a running virtual machine is moved from one physical host to another, with little or no disruption in service.

Ideally, the process is completely transparent, resulting in no disruption of service (or downtime). In practice, there is always some minor pause in availability, though it may be low enough that only hard real-time systems are affected. Virtualization is far more frequently used with network services and user applications, and these can generally tolerate the brief delays which may be involved. The perceived impact, if any, is similar to a longer-than-usual kernel delay.

The actual process is heavily dependent on the particular virtualization package in use, but in general, the process is as follows:

1. Regular snapshots of the VM (its simulated hard disk storage, its memory, and its virtual peripherals) are taken in the background by the hypervisor, or by a set of administrative scripts.
2. Each new snapshot adds a differential overlay file to the top of a stack that, as a whole, fully describes the machine. Only the topmost overlay can be written to.
3. Since the older overlays are read-only, they are safe to copy to another machine—the backup host. This is done at regular intervals, and each overlay need only be copied once.
4. When a migration operation is requested, the virtual machine is paused, and its current state is saved to disk.
5. These new, final overlay files are transferred to the backup host.
6. Since this new current state consists only of changes made since the last backup synchronization, for many applications there is very little to transfer, and this happens very quickly.
7. The hypervisor on the new host resumes the guest virtual machine.
8. Ideally, the administrative scripts resume backup operations, the new host becomes the primary, and the previous host now receives the backup copies, readying it for a subsequent migration operation.

Note that in practice, regular maintenance operations are required to "merge down" the snapshot stack into a more manageable number of files, to improve performance and optimize storage (redundant overwrites are merged out).

Migration is similar to the failover capability some virtualization suites provide. In true failover, the host may have suddenly completely failed, which precludes the latest state of the VM having been copied to the backup host. However, the backup host has everything except for the very latest changes, and may indeed be able to resume operation from its last known coherent state.

Because the operations are so similar, systems that provide one capability may provide the other.