16.10 Live Migration

The live migration process allows to transmit any virtual machine from one host system to another host system without any interruption in availability. It is possible to change hosts permanently or just during a maintenance. It is recommended that the source and destination systems have the same architecture, however it is possible to migrate between hosts with AMD and Intel architectures.

The requirements for the live migration:

  • Live migration is only possible between VM Host Servers with the same CPU features. The only supported CPU model for migration is -cpu qemu64 (default) with no additional features specified.

  • No physical devices can be passed from host to guest.

  • The VM Host Server and VM Guest need to have proper timekeeping installed.

  • AHCI interface, virtfs feature, and the -mem-path command-line option are not compatible with migration.

  • Migration from SP3 to SP2 or SP1 hosted guests is not supported.

  • The virtual machine image must be accessible on both source and destination hosts. For example, it can be located on a shared NFS disk.

  • The image directory should be located in the same path on both hosts.

  • Both hosts must be located in the same subnet.  

  • The guest on the source and destination hosts must be started in the same way.  

The live migration process has the following steps:

  1. The virtual machine instance is running on the source host.

  2. The virtual machine is started on the destination host in the frozen listening mode. The parameters used are the same as on the source host plus the -incoming tcp:ip:port parameter, where ip specifies the IP address and port specifies the port for listening to the incoming migration. If 0 is set as IP address, the virtual machine listens on all interfaces.

  3. On the source host, switch to the monitor console and use the migrate -d tcp:destination_ip:port command to initiate the migration.

  4. To determine the state of the migration, use the info migrate command in the monitor console on the source host.

  5. To cancel the migration, use the migrate_cancel command in the monitor console on the source host.

  6. To set the maximum tolerable downtime for migration in seconds, use the migrate_set_downtime number_of_seconds command.

  7. To set the maximum speed for migration in bytes per second, use the migrate_set_speed bytes_per_second command.