Migration requirements

• A guest virtual machine installed on shared storage using one of the following protocols:
  • Fibre Channel-based LUNs
  • iSCSI
  • NFS
  • GFS2
  • SCSI RDMA protocols (SCSI RCP): the block export protocol used in Infiniband and 10GbE iWARP adapters
• Make sure that the libvirtd service is enabled and running.

  # systemctl enable libvirtd.service
  # systemctl restart libvirtd.service

• The ability to migrate effectively is dependant on the parameter setting in the /etc/libvirt/libvirtd.conf file. To edit this file, use the following procedure:

  Procedure 15.1. Configuring libvirtd.conf

  1. Opening the libvirtd.conf requires running the command as root:

     # vim /etc/libvirt/libvirtd.conf

  2. Change the parameters as needed and save the file.
  3. Restart the libvirtd service:

     # systemctl restart libvirtd

• The migration platforms and versions should be checked against Table 15.1, “Live Migration Compatibility”
• Use a separate system exporting the shared storage medium. Storage should not reside on either of the two host physical machines used for the migration.
• Shared storage must mount at the same location on source and destination systems. The mounted directory names must be identical. Although it is possible to keep the images using different paths, it is not recommended. Note that, if you intend to use virt-manager to perform the migration, the path names must be identical. If you intend to use virsh to perform the migration, different network configurations and mount directories can be used with the help of --xml option or pre-hooks . For more information on pre-hooks, see the libvirt upstream documentation, and for more information on the XML option, see Chapter 23, Manipulating the Domain XML.
• When migration is attempted on an existing guest virtual machine in a public bridge+tap network, the source and destination host machines must be located on the same network. Otherwise, the guest virtual machine network will not operate after migration.

Migration Limitations

• Guest virtual machine migration has the following limitations when used on Red Hat Enterprise Linux with virtualization technology based on KVM:
  • Point to point migration – must be done manually to designate destination hypervisor from originating hypervisor
  • No validation or roll-back is available
  • Determination of target may only be done manually
  • Storage migration cannot be performed live on Red Hat Enterprise Linux 7, but you can migrate storage while the guest virtual machine is powered down. Live storage migration is available on Red Hat Virtualization. Call your service representative for details.