Planning for live migration for KVM

The live migration transfers the instance through the management network by default. You can indicate the different network to do the live migration by setting live_migration_inbound_addr in the nova.conf, refer to FAQ of IBM® Cloud Infrastructure Center on KVM for details.

The IBM® Cloud Infrastructure Center supports two kinds of live migration for KVM.

  • Shared storage-based live migration

    The storage that the instance's root disk locates is shared between the compute nodes. You can indicate the shared path when adding the host and the IBM Cloud Infrastructure Center supports two kinds of shared storage: The IBM Storage Scale (previously known as GPFS) and NFS (Network File System), refer to Planning shared storage and Add host for details.

  • Block live migration

    This is contrary to shared storage-based live migration, that the storage instance's root disk locates, is not shared between the compute nodes.

Shared storage-based live migration has a better performance than the block live migration. The instance with attached volume is also supported for both kinds of the live migrations. Refer to Live migration API for API support.

Notes:

  1. It is not possible to live migrate the instance from a higher generation hardware that the compute node locates to a lower one, or from a higher Operating System that the compute node has to a lower one. For example: it is not possible to live migrate an instance from z15 to z14 or other lower generation hardware, neither can you live migrate an instance from the compute node of RHEL8.6 to that of RHEL8.4. The contrary is generally supported. For example: you can live migrate an instance from z14 or other lower generation hardware to z15, and also live migrate an instance from the compute node of RHEL8.4 to that of RHEL8.6.

  2. Start the firewalld in the compute nodes before adding them like systemctl start firewalld. If not, when adding host, the IBM Cloud Infrastructure Center cannot set the necessary configrations for the firewalld. If the firewalld is started later, the live migration may fail. Do not install iptables or start it in the compute nodes, if it is started, stop it before adding host. Otherwise, the live migraton might fail because the IBM® Cloud Infrastructure Center does not support iptables for the compute node.

  3. Live migrating the instance between the compute nodes of different availability zones is not supported. You can only live migrate the instance between the compute nodes in the same availability zone.

  4. The duration of the live migration is up to many factors including the resources of the CPU, the memory and so on in the compute nodes, the flavor of the instance, the current workload of the instance, the bandwidth of the network, the I/O speed of the disk and whether the storage of the compute nodes are shared.

  5. When the live migration fails and the instance enters into Error state, try the reset state in the instance's detailed page. If it does not work, try a hard restart in the UI to restart it, to get the instance back. Check the reason of the failure and try to solve it before the next live migration.

  6. The live migration may not work if the destination compute node and the source compute node have an inconsistent release/kernel/libvirt version. Refer to Live migration host no change for more information.

  7. It is not supported to live migrate the instance from a Secure Execution enabled host to a Secure Execution disabled host.