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 (live migrations).
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).
VM Guests running a 64-bit operating system can only be migrated to a 64-bit host (whereas 32-bit VM Guests can be moved to a 64 or 32-bit host).
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 Chapter 8, 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 9.3, “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
libvirt connection between the target and the source host
(or vice versa). Refer to
Section 7.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
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.
When using the Virtual Machine Manager to migrate VM Guests, it does not matter on which machine it is started. You can start Virtual Machine Manager on the source or the target host or even on a third host. In the latter case you need to be able to open remote connections to both the target and the source host.
Start Virtual Machine Manager and establish a connection to the target or the source host. If the Virtual Machine Manager was started neither on the target nor the source host, connections to both hosts need to be opened.
Right-click on the VM Guest that is to be migrated and choose. Make sure the guest is running or paused - it is not possible to migrate guests that are shut off.
Choose afor the VM Guest. If the desired target host does not show up, make sure a connection to this host has been established.
By default, a “live” migration is performed. If you prefer an “offline” migration where the VM Guest is paused during the migration, tick .
Clickto start a migration with the default port and bandwidth.
In order to change these defaults, make the advanced options available by clicking the triangle at. Here you can enter the target host's (IP address or hostname), a port and the bandwidth in megabit per second (Mbps). If you specify a , you must also specify an ; the is optional.
Once the migration is complete, thewindow closes and the VM Guest is now listed on the new host in the Virtual Machine Manager Window. The original VM Guest will still be available on the target host (in state shut off).
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]
CONNECTION URI[--migrateuri tcp://
The most important options are listed below. See virsh help migrate for a full list.
Does a live migration. If not specified, an offline migration where the VM Guest is paused during the migration, will be performed.
Does an offline migration and does not restart the VM Guest on the target host.
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.
When specified, the VM Guest definition on the source host will be deleted after a successful migration.
It is recommended to use
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
# offline migration with default parameters virsh migrate 37 qemu+ssh://firstname.lastname@example.org/system # transient live migration with default parameters virsh migrate --live opensuse11 qemu+ssh://email@example.com/system # persistent live migration; delete VM definition on source virsh migrate --live --persistent --undefinesource 37 \ qemu+tls://firstname.lastname@example.org/system # offline migration using port 49152 virsh migrate opensuse11 qemu+ssh://email@example.com/system \ --migrateuri tcp://@jupiter.example.com:49152
After starting Virtual Machine Manager and connecting to the VM Host Server, a CPU usage graph of all the running guests is displayed.
It is also possible to get information about disk and network usage with this tool, however, you must first activate this in the:
Change the tab fromto .
Activate the check boxes forand .
If desired, also change the update interval or the number of samples that are kept in the history.
Activate the graphs that should be displayed under+ .
Afterwards, the disk and network statistics are also displayed in the main window of the Virtual Machine Manager.
More precise data is available from the VNC window. Open a VNC window as described in Section 6.2, “Opening a Graphical Console”. Choose from the toolbar or the menu. The statistics are displayed from the entry of the left-hand tree menu.
kvm_stat can be used to trace KVM performance
events. It monitors
/sys/kernel/debug/kvm, so it
needs the debugfs to be mounted. On openSUSE it should be mounted
by default. In case it is not mounted, use the following command:
mount -t debugfs none /sys/kernel/debug
kvm_stat can be used in three different modes:
kvm_stat # update in 1 second intervals kvm_stat -1 # 1 second snapshot kvm_stat -l > kvmstats.log # update in 1 second intervals in log format # can be imported to a spreadsheet
Example 10.1. Typical Output of kvm_stat
kvm statistics efer_reload 0 0 exits 11378946 218130 fpu_reload 62144 152 halt_exits 414866 100 halt_wakeup 260358 50 host_state_reload 539650 249 hypercalls 0 0 insn_emulation 6227331 173067 insn_emulation_fail 0 0 invlpg 227281 47 io_exits 113148 18 irq_exits 168474 127 irq_injections 482804 123 irq_window 51270 18 largepages 0 0 mmio_exits 6925 0 mmu_cache_miss 71820 19 mmu_flooded 35420 9 mmu_pde_zapped 64763 20 mmu_pte_updated 0 0 mmu_pte_write 213782 29 mmu_recycled 0 0 mmu_shadow_zapped 128690 17 mmu_unsync 46 -1 nmi_injections 0 0 nmi_window 0 0 pf_fixed 1553821 857 pf_guest 1018832 562 remote_tlb_flush 174007 37 request_irq 0 0 signal_exits 0 0 tlb_flush 394182 148
See http://clalance.blogspot.com/2009/01/kvm-performance-tools.html for further information on how to interpret these values.