Chapter 10. Administrating VM Guests

Chapter 10. Administrating VM Guests¶

Contents

10.1. Migrating VM Guests
10.2. Monitoring

10.1. Migrating VM Guests¶

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 a remote 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 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.

10.1.1. Migrating with virt-manager¶

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 Migrate. Make sure the guest is running or paused - it is not possible to migrate guests that are shut off.
Choose a New Host for 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 Migrate offline.
Click Migrate to 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 Advanced Options. Here you can enter the target host's Address (IP address or hostname), a port and the bandwidth in megabit per second (Mbps). If you specify a Port, you must also specify an Address; the Bandwidth is optional.
Once the migration is complete, the Migrate window 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).

10.1.2. Migrating with 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_NAME CONNECTION 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.


It is recommended to use `--persistent` when specifying `--undefinesource`, otherwise the VM Guest configuration will be lost on both hosts when the guest is shut down on the target host.

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://root@jupiter.example.com/system

# transient live migration with default parameters
virsh migrate --live opensuse11 qemu+ssh://root@jupiter.example.com/system

# persistent live migration; delete VM definition on source
virsh migrate --live --persistent --undefinesource 37 \
qemu+tls://root@jupiter.example.com/system

# offline migration using port 49152
virsh migrate opensuse11 qemu+ssh://root@jupiter.example.com/system \
--migrateuri tcp://@jupiter.example.com:49152

10.2. Monitoring¶

10.2.1. Monitoring with Virtual Machine Manager¶

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 Preferences:

Run virt-manager.
Select Edit+Preferences.
Change the tab from General to Stats.
Activate the check boxes for Disk I/O and Network I/O.
If desired, also change the update interval or the number of samples that are kept in the history.
Close the Preferences dialog.
Activate the graphs that should be displayed under View+Graph.

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 Details from the toolbar or the View menu. The statistics are displayed from the Performance entry of the left-hand tree menu.

10.2.2. Monitoring with kvm_stat¶

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.