Performing a live migration

These commands are useful in the context of a live migration.


  1. Optional: You may specify a tolerable downtime for a virtual server during a migration operation by using the virsh migrate-setmaxdowntime command (see migrate-setmaxdowntime). The specified value is used to estimate the point in time when to enter the stopped phase.
    You can still issue this command during the process of a migration operation:
    # virsh migrate-setmaxdowntime <VS> <milliseconds>
  2. Optional: You might want to limit the bandwidth that is provided for a migration.
    To set or to modify the maximum bandwidth, use the virsh migrate-setspeed command (see migrate-setspeed):
    # virsh migrate-setspeed <VS> --bandwidth <mebibyte-per-second>
    You can display the maximum bandwidth that is used during a migration with the virsh migrate-getspeed command (see migrate-getspeed):
    # virsh migrate-getspeed <VS>
  3. To start a live migration of a virtual server, use the virsh migrate command with the --live option (see migrate):
    # virsh migrate --live <command-options> <VS> qemu+ssh://<destination-host>/system

    When virsh connects to the destination host via SSH, you will be prompted for a password. See to avoid entering a password.

    Are options of the virsh migrate command.
    Is the name of the destination host.
    Is the migration bandwidth limit in MiB/s.
    Is the number of milliseconds used to estimate the point in time when the virtual server enters the stopped phase.
    Is the name of the virtual server as specified in its domain configuration-XML file.
    1. Optional: The use of the --auto-converge and the --timeout options ensure that the migration operation completes.
    2. Optional: To avoid a loss of connectivity during a time-consuming migration process, increase the virsh keepalive interval (see Selected virsh commands):
      # virsh --keepalive-interval <interval-in-seconds>

      The use of the virsh --keepalive-interval and --keepalive-count options preserves the communication connection between the host that initiates the migration and the libvirtd service on the source host during time-consuming processes.

      Use the keepalive options if:
      • The virtual server is running a memory intensive workload, so that it might need to be suspended to complete the migration.
      • You make use of an increased timeout interval.

      These defaults can be changed in /etc/libvirt/libvirtd.conf.

      # virsh --keepalive-interval 10 migrate --live --persistent --undefinesource \
      --timeout 1200 --verbose vserv1 qemu+ssh://kvmhost/system

      This example increases the keepalive interval of the connection to the host to 10 seconds.

    3. Optional: Perform disk migration for any virtual block devices that are backed by local resources on the source host.
      Such local host resource can be, for example, image files in the host file system or PCIe-attached NVMe devices.

      Specify the option --copy-storage-all or --copy-storage-inc in combination with the option --migrate-disks to copy image files or file systems on NVMe devices to the destination host.

      • Disk migration is only possible for writable virtual disks.

        One example of a read-only disk is a virtual DVD. If in doubt, check your domain configuration-XML. If the disk device attribute of a disk element is configured as cdrom, or contains a readonly element, the disk cannot be migrated.

      This example copies the qcow2 image /var/libvirt/images/vdd.qcow2 to the destination host, assuming that vdd is configured as follows:
      <disk type="file" device="disk">
          <driver name="qemu" type="qcow2" io="native" cache="none"/>
          <source file="/var/lib/libvirt/images/vdd.qcow2"/>
          <target dev="vdd" bus="virtio"/>
          <address type="ccw" cssid="0xfe" ssid="0x0" devno="0x0004"/>
      1. Create a qcow2 image on the destination host:
        [root@destination]# qemu-img create -f qcow2 \
        /var/lib/libvirt/images/vdd.qcow2 1G
      2. Issue the virsh migrate command on the source host:
        [root@source]# virsh migrate --live --copy-storage-all --migrate-disks vdd \
        vserv2 qemu+ssh://zhost/system


The virtual server is not destroyed on the source host until it has been completely migrated to the destination host.

In the event of an error during migration, the resources on the destination host are cleaned up and the virtual server continues to run on the source host.


  • This example starts a live migration of the virtual server vserv3 to the destination host zhost. The virtual server will be transient on zhost, that is, after vserv3 is stopped on zhost, its definition will be deleted. After a successful migration, the virtual server will be destroyed on the source host, but still be defined.
    If the migration operation is not terminated within three hundred seconds, the virtual server is suspended while the migration continues.
    # virsh migrate --live --auto-converge --timeout 300 vserv3 qemu+ssh://zhost/system
  • This example starts a live migration of vserv3 to the destination host zhost. After a successful migration, vserv3 will be destroyed and undefined on the source host. The virtual server definition will be persistent on the destination host.
    If the migration operation is not terminated within three hundred seconds, the virtual server is suspended while the migration continues.
    # virsh migrate --live --auto-converge --timeout 300 --undefinesource --persistent \
    vserv3 qemu+ssh://zhost/system

What to do next

  • You can verify whether the migration completed successfully by looking for a running status of the virtual server on the destination, for example by using the virsh list command:
    # virsh list
    Id Name                 State
    10 kvm1                running
  • You can cancel an ongoing migration operation by using the virsh domjobabort command:
    # virsh domjobabort <VS>