KVM Command Reference

Migration Commands

https://www.suse.com/documentation/sles11/book_kvm/data/sec_libvirt_managing_status.html

Requirements

One of the major advantages of virtualization is the fact that VM Guests are portable. When a VM Host Server needs to go down for maintenance, or when the host gets overloaded, the guests can easily be moved to another VM Host Server. KVM and Xen even support "live" migrations during which the VM Guest is constantly available.

In order to successfully migrate a VM Guest to another VM Host Server, the following requirements need to be met:

• Host and target must have same processor manufacturer (Intel or AMD).

• Storage devices must be accessible from both machines (for example, via NFS or iSCSI) and must be configured as a storage pool on both machines (see Section 9.0, Managing Storage for more information). This is also true for CD-ROM or floppy images that are connected during the move (however, you may disconnect them prior to the move as described in Section 10.4, Ejecting and Changing Floppy or CD/DVD-ROM Media with Virtual Machine Manager).

• libvirtd needs to run on both VM Host Servers and you must be able to open a remote libvirt connection between the target and the source host (or vice versa). Refer to Section 8.2, Configuring Remote Connections for details.

• If a firewall is running on the target host ports need to be opened to allow the migration. If you do not specify a port during the migration process, libvirt chooses one from the range 49152:49215. Make sure that either this range (recommended) or a dedicated port of your choice is opened in the firewall on the target host.

• Host and target machine should be in the same subnet on the network, otherwise networking will not work after the migration.

• No running or paused VM Guest with the same name must exist on the target host. If a shut down machine with the same name exists, its configuration will be overwritten.

• Only the default CPU model (qemu64) should be used when migrating VM Guests.

• SATA disk device type is not migratable.

• File system pass-through feature is incompatible with migration.

Migration using virsh

To migrate a VM Guest with virsh migrate, you need to have direct or remote shell access to the VM Host Server, because the command needs to be run on the host. Basically the migration command looks like this

virsh migrate [OPTIONS] VM_ID_or_NAMECONNECTION URI [--migrateuri tcp://REMOTE_HOST:PORT]

The most important options are listed below. See virsh help migrate for a full list.

--live

Does a live migration. If not specified, an offline migration where the VM Guest is paused during the migration, will be performed.

--suspend

Does an offline migration and does not restart the VM Guest on the target host.

--persistent

By default a migrated VM Guest will be migrated transient, so its configuration is automatically deleted on the target host if it is shut down. Use this switch to make the migration persistent.

--undefinesource

When specified, the VM Guest definition on the source host will be deleted after a successful migration (however, virtual disks attached to this guest will not be deleted).

The following examples use mercury.example.com as the source system and jupiter.example.com as the target system, the VM Guest's name is opensuse11 with Id 37.

Offline migration with default parameters

virsh migrate 37 qemu+ssh://tux@jupiter.example.com/system

Transient live migration with default parameters

virsh migrate --live opensuse11 qemu+ssh://tux@jupiter.example.com/system

Persistent live migration; delete VM definition on source

virsh migrate --live --persistent --undefinesource 37 \
    qemu+tls://tux@jupiter.example.com/system

Offline migration using port 49152

virsh migrate opensuse11 qemu+ssh://tux@jupiter.example.com/system \
    --migrateuri tcp://@jupiter.example.com:49152

Firewall command to allow migration ports

firewall-cmd --add-port 49152-49215/tcp
firewall-cmd --add-port 49152-49215/tcp --permanent