Difference between revisions of "KVM Command Reference"
Line 16: | Line 16: | ||
start start a (previously defined) inactive domain | start start a (previously defined) inactive domain | ||
undefine undefine a domain | undefine undefine a domain | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Suspend / Restore Commands == | == Suspend / Restore Commands == | ||
Line 180: | Line 103: | ||
</pre> | </pre> | ||
+ | |||
+ | == 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''' | ||
+ | |||
+ | <nowiki>virsh migrate 37 qemu+ssh://tux@jupiter.example.com/system</nowiki> | ||
+ | |||
+ | '''Transient live migration with default parameters''' | ||
+ | |||
+ | <nowiki>virsh migrate --live opensuse11 qemu+ssh://tux@jupiter.example.com/system</nowiki> | ||
+ | |||
+ | '''Persistent live migration; delete VM definition on source''' | ||
+ | |||
+ | <nowiki>virsh migrate --live --persistent --undefinesource 37 \ | ||
+ | qemu+tls://tux@jupiter.example.com/system</nowiki> | ||
+ | |||
+ | '''Offline migration using port 49152''' | ||
+ | |||
+ | <nowiki>virsh migrate opensuse11 qemu+ssh://tux@jupiter.example.com/system \ | ||
+ | --migrateuri tcp://@jupiter.example.com:49152</nowiki> | ||
+ | |||
+ | '''Firewall command to allow migration ports''' | ||
+ | |||
+ | firewall-cmd --add-port 49152-49215/tcp | ||
+ | firewall-cmd --add-port 49152-49215/tcp --permanent |
Revision as of 01:44, 3 March 2016
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
Moving a guest to a new machine
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