KVM Command Reference

Installation

virt-install --connect qemu:///system -n windows-vm1 -r 16384 --vcpus=4 \
   --disk path=/var/lib/libvirt/images/windows-vm1.img,size=150,format=qcow2 \
   --graphics vnc,listen=0.0.0.0 --noautoconsole --os-type=windows \
   --os-variant=win7 --accelerate --network=bridge:virbr0 --hvm \
   --cdrom /var/lib/libvirt/images/GRMCPRXVOL_EN_DVD.iso --boot cdrom,hd

Creation / Deletion Commands

   create                         create a domain from an XML file
   define                         define (but don't start) a domain from an XML file
   destroy                        destroy (stop) a domain
   dumpxml                        domain information in XML
   shutdown                       gracefully shutdown a domain
   start                          start a (previously defined) inactive domain
   undefine                       undefine a domain

Suspend / Restore Commands

Suspend

   suspend                        suspend a domain

# virsh suspend target-vm

Resume

   resume                         resume a domain

# virsh resume target-vm

Save

   save                           save a domain state to a file

# virsh save /path/to/target-vm.vmsav

Restore

   restore                        restore a domain from a saved state in a file

# virsh restore /path/to/target-vm.vmsav

Warm Migration Procedure

Moving from source to destination, where the hard drive is not on shared storage is pretty easy, but requires a few steps.

Examine the following sequence, where we save the guest machine's memory state to disk and shut the machine down, then copy the machine, the saved memory and the disk image to the destination KVM host.

[root@centos-vm2 ~]#  virsh list --all
 Id    Name                           State
----------------------------------------------------
 4     openvpn                        running
 8     sfiggins-windows-vm            running

[root@centos-vm2 ~]#  virsh save sfiggins-windows-vm /var/lib/libvirt/saves/sfiggins-windows-vm.vmsav 

Domain sfiggins-windows-vm saved to /var/lib/libvirt/saves/sfiggins-windows-vm.vmsav

[root@centos-vm2 ~]#  virsh list --all
 Id    Name                           State
----------------------------------------------------
 4     openvpn                        running
 -     sfiggins-windows-vm            shut off

[root@centos-vm2 ~]#  virsh dumpxml sfiggins-windows-vm > /var/lib/libvirt/configs/sfiggins-windows-vm.xml
[root@centos-vm2 ~]#  virsh undefine sfiggins-windows-vm
Domain sfiggins-windows-vm has been undefined

[root@centos-vm2 ~]#  virsh list --all
 Id    Name                           State
----------------------------------------------------
 4     openvpn                        running

[root@centos-vm2 ~]#  scp /var/lib/libvirt/saves/sfiggins-windows-vm.vmsav root@centos-vm1://var/lib/libvirt/saves/
[root@centos-vm2 ~]#  scp /var/lib/libvirt/configs/sfiggins-windows-vm.xml root@centos-vm1://var/lib/libvirt/configs
[root@centos-vm2 ~]#  scp /var/lib/libvirt/images/sfiggins-windows-vm.img root@centos-vm1://var/lib/libvirt/images

We now load the guest configuration to the destination KVM host without starting the machine, and then restore the memory state from the saved file.

[root@centos-vm1 ~]#  chown qemu.qemu /var/lib/libvirt/images/sfiggins-windows-vm.img 
[root@centos-vm1 ~]#  virsh define /var/lib/libvirt/configs/sfiggins-windows-vm.xml
Domain sfiggins-windows-vm defined from /var/lib/libvirt/configs/sfiggins-windows-vm.xml

[root@centos-vm1 ~]#  virsh list --all
 Id    Name                           State
----------------------------------------------------
 2     smsm-windows-vm                running
 -     sfiggins-windows-vm            shut off

[root@centos-vm1 ~]#  virsh restore /var/lib/libvirt/saves/sfiggins-windows-vm.vmsav
Domain restored from /var/lib/libvirt/saves/sfiggins-windows-vm.vmsav

[root@centos-vm1 ~]#  virsh list --all
 Id    Name                           State
----------------------------------------------------
 2     smsm-windows-vm                running
 10    sfiggins-windows-vm            running

Live 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