Contents
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
+ + . 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.Select the
section, then click to manage the way the boot loader and Xen function.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 9.1. Xen Section in the menu.lst
File (Typical)
title XEN root (hd0,5) kernel /boot/xen.gzhyper_parameters
module /boot/vmlinuz-xenkernel_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
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
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.
kernel_parameters
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.
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.
![]() | 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
![]() | 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.novell.com/documentation/sles11/stor_admin/data/bookinfo.html.
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”.
In a virtual machine window, some key combinations, such as Ctrl+Alt+F1, 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 Ctrl+Alt+F2 to a Linux virtual machine, press Ctrl three times, then press Alt+F2. You can also press Alt three times, then press Ctrl+F2.
The sticky key functionality is available in the Virtual Machine Manager during and after installing a virtual machine.
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.
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:
Run virt-manager and connect to the VM Host Server system.
Select
+ .Change the tab from
to .Activate the check boxes for
and .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
.To get more precise data of the respective machine, select the machine, click
and then . The statistics are displayed from the entry of the left-hand tree menu.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:
Change the delay between the refreshs of the screen
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.
Display the respective block devices and their cumulated usage count.
For more information about xentop see the manual page man 1 xentop.
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:
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
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.
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
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 screen you can set the . 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
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:
Install the package vhostmd on the VM Host Server.
Edit the file /etc/vhostmd/vhostmd.conf
if you
want to add or remove metric
sections from the
configuration. However, the default works well.
Check the validity of the vhostmd.conf
configuration file with the command:
cd /etc/vhostmd xmllint --postvalid --noout vhostmd.conf
Start the vhostmd daemon with the command rcvhostmd start.
If vhostmd should be started automatically during startup of the system, run the command:
chkconfig vhostmd on
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
Log on on the VM Guest system.
Install the client package vm-dump-metrics
.
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.