SUSE Linux Enterprise Server Documentation › Virtualization Guide › Managing Virtual Machines with libvirt › Administrating VM Guests
ContentsContents
Virtualization Guide
  1. About This Manual
  2. I Introduction
    1. 1 Virtualization Technology
    2. 2 Introduction to Xen Virtualization
    3. 3 Introduction to KVM Virtualization
    4. 4 Introduction to Linux Containers
    5. 5 Virtualization Tools
    6. 6 Installation of Virtualization Components
    7. 7 Supported Guests, Hosts and Features
  3. II Managing Virtual Machines with libvirt
    1. 8 Overview
    2. 9 Guest Installation
    3. 10 Basic VM Guest Management
    4. 11 Connecting and Authorizing
    5. 12 Managing Storage
    6. 13 Configuring Virtual Machines
    7. 14 Administrating VM Guests
    8. 15 Save and Restore of Virtual Machines
  4. III Common Tasks
    1. 16 VM Guest Clock Settings
    2. 17 libguestfs
  5. IV Managing Virtual Machines with Xen
    1. 18 Setting Up a Virtual Machine Host
    2. 19 Virtual Networking
    3. 20 Managing a Virtualization Environment
    4. 21 Block Devices in Xen
    5. 22 Virtualization: Configuration Options and Settings
    6. 23 Administration Tasks
    7. 24 XenStore: Configuration Database Shared between Domains
    8. 25 Xen as a High-Availability Virtualization Host
  6. V Managing Virtual Machines with QEMU
    1. 26 QEMU Overview
    2. 27 Guest Installation
    3. 28 Running Virtual Machines with qemu-system-ARCH
    4. 29 KVM Disk Cache Modes
    5. 30 Administrating Virtual Machines with QEMU Monitor
  7. VI Managing Virtual Machines with LXC
    1. 31 Linux Containers
    2. 32 Migration from LXC to libvirt-lxc
  8. Glossary
  9. A Virtual Machine Drivers
  10. B Appendix
  11. C XM, XL Toolstacks and Libvirt framework
  12. D Documentation Updates
  13. E GNU Licenses
Navigation←→
SUSE Linux Enterprise Server Documentation › Virtualization Guide › Managing Virtual Machines with libvirt › Administrating VM Guests
Top
←→
Applies to SUSE Linux Enterprise Server 12

14 Administrating VM Guests

14.1 Migrating VM Guests
14.2 Monitoring

14.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.

14.1.1 Migration Requirements

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

  • It is recommended that the source and destination systems have the same architecture, however it is possible to migrate between hosts with AMD* and Intel* architectures.

  • 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 12, 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 13.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 11.3, “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.

  • All CPU models except host cpu model are supported when migrating VM Guests.

  • SATA disk device type is not migratable.

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

  • The VM Host Server and VM Guest need to have proper timekeeping installed. See Chapter 16, VM Guest Clock Settings.

  • Section 28.3.1.2, “virtio-blk-data-plane” is not supported for migration.

  • No physical devices can be passed from host to guest. Live migration is currently not supported when using devices with PCI passthrough or SR-IOV. In case live migration needs to be supported, you need to use software virtualization (paravirtualization or full virtualization).

  • Cache mode setting is an important setting for migration. See: Section 29.5, “Effect of Cache Modes on Live Migration”.

  • Backward migration is not supported (migration from SP3 to SP2 or SP1 or GA).

  • The image directory should be located in the same path on both hosts.

14.1.2 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.

  1. 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.

  2. Right-click 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 down.

  3. 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.

  4. 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 megabits per second (Mbps). If you specify a Port, you must also specify an Address; the Bandwidth is optional.

  5. 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 shut down state).

14.1.3 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. 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 opensuse131 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 opensuse131 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 opensuse131 qemu+ssh://tux@jupiter.example.com/system \
--migrateuri tcp://@jupiter.example.com:49152
Note
Note: Transient vs. Persistent Migrations

By default virsh migrate creates a temporary (transient) copy of the VM Guest on the target host. A shut down version of the original guest description remains on the source host. A transient copy will be deleted from the server once it is shut down.

In order to create a permanent copy of a guest on the target host, use the switch --persistent. A shut down version of the original guest description remains on the source host, too. Use the option --undefinesource together with --persistent for a “real” move where a permanent copy is created on the target host and the version on the source host is deleted.

It is not recommended to use --undefinesource without the --persistent option, since this will result in the loss of both VM Guest definitions when the guest is shut down on the target host.

14.1.4 Step-by-Step Example

14.1.4.1 Exporting the Storage

First you need to export the storage, to share the Guest image between host. This can be done by an NFS server. In the following example we want to share the /volume1/VM directory for all machines that are on the network 10.0.1.0/24. We will use a SUSE Linux Enterprise NFS server. As root user, edit the /etc/exports file and add: 

/volume1/VM 10.0.1.0/24  (rw,sync,no_root_squash)

You need to restart the NFS server: 

root # systemctl restart nfsserver
root # exportfs 
/volume1/VM      10.0.1.0/24

14.1.4.2 Defining the Pool on the Target Hosts

On each host where you want to migrate the VM Guest, the pool must be defined to be able to access the volume (that contains the Guest image). Our NFS server IP address is 10.0.1.99, its share is the /volume1/VM directory, and we want to get it mounted in the /var/lib/libvirt/images/VM directory. The pool name will be VM. To define this pool, create a VM.xml file with the following content: 

     <pool type='netfs'>
  <name>VM</name>name>
  <source>
    <host name='10.0.1.99'/>>
    <dir path='/volume1/VM'/>>
    <format type='auto'/>>
  </source>source>
  <target>
    <path>/var/lib/libvirt/images/VM</path>path>
    <permissions>
      <mode>0755</mode>mode>
      <owner>-1</owner>owner>
      <group>-1</group>group>
    </permissions>permissions>
  </target>target>
  </pool>pool>

Then load it into libvirt using the pool-define command: 

root # virsh pool-define VM.xml

An alternative way to define this pool is to use the virsh command: 

root # virsh pool-define-as VM --type netfs --source-host 10.0.1.99 \
     --source-path /volume1/VM --target /var/lib/libvirt/images/VM
Pool VM created

Then the pool can be set to start automatically at host boot (autostart option): 

virsh # pool-autostart VM
Pool VM marked as autostarted

If you want to disable the autostart: 

virsh # pool-autostart VM --disable
Pool VM unmarked as autostarted

Check if the pool is present: 

virsh # pool-list --all
 Name                 State      Autostart
-------------------------------------------
 default              active     yes
 VM                   active     yes

virsh # pool-info VM
Name:           VM
UUID:           42efe1b3-7eaa-4e24-a06a-ba7c9ee29741
State:          running
Persistent:     yes
Autostart:      yes
Capacity:       2,68 TiB
Allocation:     2,38 TiB
Available:      306,05 GiB
Warning
Warning

Remember: this pool must be defined on each host where you want to be able to migrate your VM Guest.

14.1.4.3 Creating the Volume

The pool has been defined—now we need a volume which will contain the disk image: 

virsh # vol-create-as VM sled12.qcow12 8G --format qcow2
Vol sled12.qcow12 created

The volume names shown will be used later to install the guest with virt-install.

14.1.4.4 Creating the VM Guest

Let's create a SUSE Linux Enterprise Desktop VM Guest with the virt-install command. The VM pool will be specified with the --disk option, cache=none is recommended if you don't want to use the --unsafe option while doing the migration. 

root # virt-install --connect qemu:///system --virt-type kvm --name \
   sled12 --memory 1024 --disk vol=VM/sled12.qcow2,cache=none --cdrom \
   /mnt/install/ISO/SLE-12-Desktop-DVD-x86_64-Build0327-Media1.iso --graphics \
   vnc --os-variant sled12
Starting install...
Creating domain...

14.1.4.5 Migrate the VM Guest

Everything is ready to do the migration now. Just run the migrate command on the VM Host Server that is currently hosting the VM Guest, and choose the destination. 

virsh # migrate --live sled12 --verbose qemu+ssh://IP/Hostname/system
Password:
Migration: [ 12 %]

14.2 Monitoring

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

  1. Run virt-manager.

  2. Select Edit › Preferences.

  3. Change the tab from General to Stats.

  4. Activate the check boxes for Disk I/O and Network I/O.

  5. If desired, also change the update interval or the number of samples that are kept in the history.

  6. Close the Preferences dialog.

  7. 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 10.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.

14.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 SUSE Linux Enterprise Server 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 14.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.

→Chapter 15 Save and Restore of Virtual Machines←Chapter 13 Configuring Virtual Machines
Print this page

© 2015 SUSE