2.12.1.2. Live Migration of Virtual Machines and Containers

The process of migrating virtual machines and containers live is as follows:

  1. Once you start the migration, OpenVZ checks whether the destination server meets all the migration requirements and the virtual machine or container can be migrated to it.
  2. All virtual memory and disks of the virtual machine or container are migrated to the destination server.
  3. The virtual machine or container on the source server is suspended.
  4. The changed memory pages and virtual disk blocks, if any, are migrated to the destination server.
  5. The virtual machine or container is resumed on the destination server.

The virtual machine or container continues running during steps 1 and 2 and is not available to the user during steps 3-5. But since the amount of memory pages and virtual disk blocks changed during step 2 is small, the downtime is almost imperceptible.

After migration, the relocated virtual machine or container may not be accessible over the network for several minutes due to network equipment reconfiguration (for example, as switches are updating their dynamic VLAN membership tables).

Note

Note: For increased security during live migration, OpenVZ provides connection tunneling between the source and destination servers. Tunnelling increases migration time, so if you want to speed up the process and do not need a secure tunnel between servers, you can disable connection tunneling with the --no-tunnel.

When performing live migration, take into account the following requirements and restrictions:

  • Before starting live migration, it is recommended to synchronize the system time on the source and destination servers, for example, by means of NTP (http://www.ntp.org). The reason is that certain processes running in virtual machines and containers may rely on system time being steady and might behave unpredictably when resumed on a destination server where time is different.
  • The network must support data transfer rates of at least 1 Gbps.
  • The source and destination servers must belong to the same subnetwork.
  • The CPUs on the source and destination servers must be manufactured by the same vendor, and the CPU capabilities of the destination server must be the same or exceed those on the source server.
  • Virtual machine and container disks can be located on local disks, shared NFS and GFS2 storages, and ISCSI raw devices.
  • Live migration is not supported for virtual machines and containers with open prlctl enter sessions and containers with IPSec connections.