Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Linux Enterprise Server 11 SP4

10 Administration Tasks

10.1 The Boot Loader Program

The boot loader controls how the virtualization software boots and runs. You can modify the boot loader properties by using YaST, or by directly editing the boot loader configuration file.

The YaST boot loader program is located at YaST › System › Boot Loader. The Boot Loader Settings screen lists the sections that appear as options on the boot menu. From this screen, you can change the boot loader so it auto-selects the virtual machine host option when booting.

Boot Loader Settings
Figure 10.1: Boot Loader Settings

Select the Xen section, then click Edit to manage the way the boot loader and Xen function.

Boot Loader Settings: Section Management
Figure 10.2: Boot Loader Settings: Section Management

You can use the Boot Loader program to specify functionality, such as:

  • Pass kernel command line parameters.

  • Specify the kernel image and initial RAM disk.

  • Select a specific hypervisor.

  • Pass additional parameters to the hypervisor (see /usr/share/doc/packages/xen/pdf/user.pdf section Xen Boot Options after installing the package xen-doc-pdf).

You can customize your virtualization environment by editing the /boot/grub/menu.lst file.

If the Xen option does not appear on the GRUB boot menu, you can compare your updated GRUB boot loader file with the examples below to confirm that it was updated correctly.

The first example shows a typical GRUB boot loader file updated to load the kernel that supports virtualization software. The second example shows a GRUB boot loader file that loads the PAE-enabled virtualization kernel.

Example 10.1: Xen Section in the menu.lst File (Typical)
title XEN
 root (hd0,5)
 kernel /boot/xen.gz hyper_parameters
 module /boot/vmlinuz-xen kernel_parameters
 module /boot/initrd-xen

The title line defines sections in the boot loader file. Do not change this line, because YaST looks for the word XEN to verify that packages are installed.

The root line specifies which partition holds the boot partition and /boot directory. Replace hd0,5 with the correct partition. For example, if the drive designated as hda1 holds the /boot directory, the entry would be hd0,0.

The kernel line specifies the directory and filename of the hypervisor. Replace hyper_parameters with the parameters to pass to the hypervisor. A common parameter is dom0_mem=<amount_of_memory>, which specifies how much memory to allocate to Domain0. The amount of memory is specified in KB, or you can specify the units with a K, M, or G suffix, for example 128M. If the amount is not specified, the Domain0 takes the maximum possible memory for its operations.

For more information about hypervisor parameters, see /usr/share/doc/packages/xen/pdf/user.pdf section Xen Boot Options after installing the package xen-doc-pdf.

The first module line specifies the directory and filename of the Linux kernel to load. Replace kernel_parameters with the parameters to pass to the kernel. These parameters are the same parameters as those that can be passed to a standard Linux kernel on physical computer hardware.

The second module line specifies the directory and filename of the RAM disk used to boot the virtual machine host.

To set the GRUB boot loader to automatically boot the Xen virtualization software, change the default entry from 0, which means the first title entry, to the number that corresponds to the title XEN entry. In the example file, Xen is the second title line. To specify it, change the value of default from 0 to 1.

10.2 Sparse Image Files and Disk Space

If the host’s physical disk reaches a state where it has no available space, a virtual machine using a virtual disk based on a sparse image file is unable to write to its disk. Consequently, it reports I/O errors.

The Reiser file system, perceiving a corrupt disk environment, automatically sets the file system to read-only. If this situation happens, you should free up available space on the physical disk, remount the virtual machine’s file system, and set the file system back to read-write.

To check the actual disk requirements of a sparse image file, use the command du -h <image file>.

To increase the available space of a sparse image file, first increase the file size and then the file system.

Warning
Warning: Backup Before Resize

Touching the sizes of partitions or sparse files always bears the risk of data failure. Do not work without a backup.

The resizing of the image file can be done online, while the VM Guest is running. Increase the size of a sparse image file with:

dd if=/dev/zero of=<image file> count=0 bs=1M seek=<new size in MB>

For example, to increase the file /var/lib/xen/images/sles11/disk0 to a size of 16GB, use the command:

dd if=/dev/zero of=/var/lib/xen/images/sles11/disk0 count=0 bs=1M seek=16000
Note
Note: Increasing Non Sparse Images

It is also possible to increase the image files of devices that are not sparse files. However, you must know exactly where the previous image ends. Use the seek parameter to point to the end of the image file and use a command similar to the following:

dd if=/dev/zero of=/var/lib/xen/images/sles11/disk0 seek=8000 bs=1M count=2000

Be sure to use the right seek, else data loss may happen.

If the VM Guest is running during the resize operation, also resize the loop device that provides the image file to the VM Guest. First detect the correct loop device with the command:

losetup -j /var/lib/xen/images/sles11/disk0

Then resize the loop device, for example, /dev/loop0 with the following command:

losetup -c /dev/loop0

Finally check the size of the block device inside the guest system with the command fdisk -l /dev/xvdb. The device name depends on the actually increased device.

The resizing of the file system inside the sparse file involves tools that are depending on the actual file system. This is described in detail in the Storage Administration Guide, found at http://www.suse.com/doc/sles11/stor_admin/data/bookinfo.html.

10.3 Migrating Virtual Machines

A running virtual machine can be migrated from its source virtual machine host to another virtual machine host. This functionality is referred to as live migration. For live migration the virtual machine being migrated must have access to its storage in exactly the same location on both, source and destination host platforms.

Live migration only works when every entity involved has the same architecture. For example, a 64-bit paravirtualized guest running on a 64-bit hypervisor can be migrated to a host running a 64-bit hypervisor. If any of the pieces do not match exactly, migration will fail.

Another requirement is, that the involved file systems are available on both machines. The options to accomplish this task include Network Block Devices (NBD), iSCSI, NFS, DRBD and fiber channel devices. Furthermore, the routing of the network connection to the virtual network device must be correct.

The following Xend options, which are located in the /etc/xen/xend-config.sxp file, need to be set on both hosts to make live migration work.

(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address ")
(xend-relocation-hosts-allow ")

For information on modifying Xend settings, see Section 5.2, “Controlling the Host by Modifying Xend Settings”. For more details about using xm to migrate VM Guest systems, see Section 5.6, “Migrating Xen VM Guest Systems”.

10.4 Passing Key Combinations to Virtual Machines

In a virtual machine window, some key combinations, such as CtrlAltF1, are recognized by the virtual machine host but are not passed to the virtual machine. To bypass the virtual machine host, Virtual Machine Manager provides sticky key functionality. Pressing Ctrl, Alt, or Shift three times makes the key sticky, then you can press the remaining keys to pass the combination to the virtual machine.

For example, to pass CtrlAltF2 to a Linux virtual machine, press Ctrl three times, then press AltF2. You can also press Alt three times, then press CtrlF2.

The sticky key functionality is available in the Virtual Machine Manager during and after installing a virtual machine.

10.5 Monitoring Xen

For a regular operation of many virtual guests, having a possibility to check the sanity of all the different VM Guest systems indispensable. Xen offers several tools besides the system tools to gather information about the system.

10.5.1 Monitor Xen with virt-manager

After starting virt-manager and connecting to the VM Host Server, an overview of the CPU usage 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:

  1. Run virt-manager and connect to the VM Host Server system.

  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.

Afterwards, the disk and network statistics are also displayed in the main window of the Virtual Machine Manager.

To get more precise data of the respective machine, select the machine, click Open and then Details. The statistics are displayed from the Performance entry of the left-hand tree menu.

10.5.2 Monitor Xen with xentop

Information is also available when only a standard terminal is available on no X environment. The preferred tool to gather information in this case is xentop. Unfortunately, this tool needs a rather broad terminal, else it inserts line breaks into the display.

xentop has several command keys that can give you more information about the system that is monitored. Some of the more important are:

D

Change the delay between the refreshs of the screen

N

Also display network statistics. Note, that only standard configurations will be displayed. If you use a special configuration like a routed network, no network will be displayed at all.

B

Display the respective block devices and their cumulated usage count.

For more information about xentop see the manual page man 1 xentop.

10.5.3 More Helpful Tools

There are many different system tools that also help monitoring or debugging a running SUSE Linux Enterprise system. Many of these are covered in the official SUSE Linux Enterprise documentation. Especially useful for monitoring a virtualization environment are the following tools:

ip

The command line utility ip may be used to monitor arbitrary network interfaces. This is especially useful, if you did set up a network that is routed or applied a masqueraded network. To monitor a network interface with the name alice.0, run the following command:

watch ip -s link show alice.0
brctl

In a standard setup, all the Xen VM Guest systems are attached to a virtual network bridge. brctl allows you to determine the connection between the bridge and the virtual network adapter in the VM Guest system. For example, the output of brctl show may look like the following:

bridge name     bridge id               STP enabled     interfaces
br0             8000.000476f060cc       no              eth0
                                                        vif1.0
br1             8000.00001cb5a9e7       no              vlan22

This shows, that there are two virtual bridges defined on the system. One is connected to the physical ethernet device eth0, the other one is connected to a vlan interface vlan22.

There is only one guest interface active in this setup, vif1.0. This means, that the guest with id 1 has an ethernet interface eth0 assigned, that is connected to br0 in the VM Host Server.

iptables-save

Especially when using masquerade networks, or if several ethernet interfaces are set up together with a firewall setup, it may be helpful to check the current firewall rules.

The command iptables may be used to check all the different firewall settings. To list all the rules of a chain, or even of the complete setup, you may use the commands iptables-save or iptables -S

10.6 Extra Guest Descriptions in Xen Configuration

With Xen, it is possible to add an extra descriptions to the configuration of each guest. This may be helpful for example to document the purpose of the guest, or the responsible person to handle the guest.

The description can be set during the installation of the guest. When running vm-install, in the Summary screen you can set the Name of Virtual Machine. The graphical interface for changing the name also contains an extra description line, that may be used to add a single line of text.

When using the Xen configuration files in /etc/xen/vm, the syntax for setting the description looks like this:

description="Responsible: tux@example.com"

It is also possible to change the SXP configuration to add or change the description as described in Section 5.3, “Configuring a Virtual Machine by Modifying its Xend Settings”. The description is added directly below the domain element and looks like this:

(domain
...  
    (description 'Responsible: tux@example.com')
...

To retrieve the description of a specific VM Guest, for example, a guest with the name alice, run the command:

xm list -l alice | grep description

10.7 Providing Host Information for VM Guest Systems

In a standard Xen environment, the VM Guest systems have only very limited information about the VM Host Server system they are running on. If a guest should know more about the VM Host Server it runs on, vhostmd can provide more information to selected guests. To set up your system to run vhostmd, proceed as follows:

  1. Install the package vhostmd on the VM Host Server.

  2. Edit the file /etc/vhostmd/vhostmd.conf if you want to add or remove metric sections from the configuration. However, the default works well.

  3. Check the validity of the vhostmd.conf configuration file with the command:

    cd /etc/vhostmd
    xmllint --postvalid --noout vhostmd.conf
  4. Start the vhostmd daemon with the command rcvhostmd start.

    If vhostmd should be started automatically during start-up of the system, run the command:

    chkconfig vhostmd on
  5. Attach the image file /dev/shm/vhostmd0 to the VM Guest system named alice with the command:

    xm block-attach alice tap:aio:/dev/shm/vhostmd0 xvdb r
  6. Log on on the VM Guest system.

  7. Install the client package vm-dump-metrics.

  8. Run the command vm-dump-metrics. If you would like to have the result in a file, use the option -d <filename>.

The result of the vm-dump-metrics is an XML output. The respective metric entries follow the DTD /etc/vhostmd/metric.dtd.

For more information, see the manual pages man 8 vhostmd and /usr/share/doc/vhostmd/README on the VM Host Server system. On the guest, see the manual page man 1 vm-dump-metrics.

Print this page