libvirt
The documentation in this section, describes advanced management tasks and configuration options that might help technology innovators implement leading-edge virtualization solutions. It is provided as a courtesy and does not imply that all documented options and tasks are supported by Novell, Inc.
Virtual CD readers can be set up when a virtual machine is created or added to an existing virtual machine. A virtual CD reader can be based on a physical CD/DVD, or based on an ISO image. Virtual CD readers work differently depending on whether they are paravirtual or fully virtual.
A paravirtual machine can have up to 100 block devices composed of virtual CD readers and virtual disks. On paravirtual machines, virtual CD readers present the CD as a virtual disk with read-only access. Virtual CD readers cannot be used to write data to a CD.
After you have finished accessing a CD on a paravirtual machine, it is recommended that you remove the virtual CD reader from the virtual machine.
Paravirtualized guests can use the device type
devtype=cdrom
. This partly emulates the behavior of a
real CD reader, and allows CDs to be changed. It is even possible to use
the eject command to open the tray of the CD reader.
A fully virtual machine can have up to four block devices composed of
virtual CD readers and virtual disks. A virtual CD reader on a fully
virtual machine interacts with an inserted CD in the way you would
expect a physical CD reader to interact. For example, in a Windows* XP*
virtual machine, the inserted CD appears in the Devices with
Removable Storage
section of My Computer
.
When a CD is inserted in the physical CD reader on the host computer,
all virtual machines with virtual CD readers based on the physical CD
reader, such as /dev/cdrom/
, can read the
inserted CD. Assuming the operating system has automount functionality,
the CD should automatically appear in the file system. Virtual CD
readers cannot be used to write data to a CD. They are configured as
read-only devices.
Virtual CD readers can be based on a CD inserted into the CD reader or on an ISO image file.
Make sure that the virtual machine is running and the operating system has finished booting.
Insert the desired CD into the physical CD reader or copy the desired ISO image to a location available to Dom0.
Select a new, unused block device in your VM Guest, such as
/dev/xvdb
.
Choose the CD reader or ISO image that you want to assign to the guest.
When using a real CD reader, use the following command to assign the CD reader to your VM Guest. In this example, the name of the guest is alice:
xl block-attach alice target=/dev/sr0,vdev=xvdb,access=ro
When assigning an image file, use the following command:
xl block-attach alice target=/path/to/file.iso,vdev=xvdb,access=ro
A new block device, such as /dev/xvdb
, is added
to the virtual machine.
If the virtual machine is running Linux, complete the following:
Open a terminal in the virtual machine and enter fdisk
-l
to verify that the device was properly added. You can
also enter ls /sys/block
to see all disks
available to the virtual machine.
The CD is recognized by the virtual machine as a virtual disk with a drive designation, for example:
/dev/xvdb
Enter the command to mount the CD or ISO image using its drive designation. For example,
mount -o ro /dev/xvdb /mnt
mounts the CD to a mount point named /mnt
.
The CD or ISO image file should be available to the virtual machine at the specified mount point.
If the virtual machine is running Windows, reboot the virtual machine.
Verify that the virtual CD reader appears in its My
Computer
section.
Make sure that the virtual machine is running and the operating system has finished booting.
If the virtual CD reader is mounted, unmount it from within the virtual machine.
Enter xl block-list alice
on the host view of the
guest block devices.
Enter xl block-detach alice
block_dev_id to remove the virtual device
from the guest. If that fails, try to add -f
to force
the removal.
Press the hardware eject button to eject the CD.
Some configurations, such as those that include rack-mounted servers,
require a computer to run without a video monitor, keyboard, or mouse.
This type of configuration is often called headless
and
requires the use of remote administration technologies.
Typical configuration scenarios and technologies include:
If a graphical desktop, such as GNOME, is installed on the virtual
machine host, you can use a remote viewer, such as a VNC viewer. On a
remote computer, log in and manage the remote guest environment by
using graphical tools, such as tigervnc
or
virt-viewer
.
You can use the ssh
command from a remote computer
to log in to a virtual machine host and access its text-based console.
You can then use the xl
command to manage virtual
machines and the virt-install
or
vm-install
commands to create new virtual machines.
VNC viewer is used to view the environment of the running guest system in a graphical way. You can use it from Dom0 (known as local access or on-box access), or from a remote computer.
You can use the IP address of a VM Host Server and a VNC viewer to view the display of this VM Guest. When a virtual machine is running, the VNC server on the host assigns the virtual machine a port number to be used for VNC viewer connections. The assigned port number is the lowest port number available when the virtual machine starts. The number is only available for the virtual machine while it is running. After shutting down, the port number might be assigned to other virtual machines.
For example, if ports 1 and 2 and 4 and 5 are assigned to the running virtual machines, the VNC viewer assigns the lowest available port number, 3. If port number 3 is still in use the next time the virtual machine starts, the VNC server assigns a different port number to the virtual machine.
To use the VNC viewer from a remote computer, the firewall must permit access to as many ports as VM Guest systems run from. This means from port 5900 and up. For example, if you want to run 10 VM Guest systems, you need to open the TCP ports 5900:5910.
To access the virtual machine from the local console running a VNC viewer client, enter one of the following commands:
vncviewer ::590#
vncviewer :#
# is the VNC viewer port number assigned to the virtual machine.
When accessing the VM Guest from a machine other than Dom0, use the following syntax:
vncviewer 192.168.1.20::590#
In this case, the IP address of Dom0 is 192.168.1.20.
Although the default behavior of VNC viewer is to assign the first available port number, you might want to assign a specific VNC viewer port number to a specific virtual machine.
To assign a specific port number on a VM Guest, edit the xl setting
of the virtual machine and change the vnclisten
to
the desired value. Note that for example for port number 5902, specify 2
only, as 5900 is added automatically:
vfb = [ 'vnc=1,vnclisten="localhost:2"' ]
For more information regarding editing the xl settings of a guest domain, see Section 20.1, “XL—Xen Management Tool”.
Assign higher port numbers to avoid conflict with port numbers assigned by the VNC viewer, which uses the lowest available port number.
If you access a virtual machine's display from the virtual machine host console (known as local or on-box access), you might want to use SDL instead of VNC viewer. VNC viewer is faster for viewing desktops over a network, but SDL is faster for viewing desktops from the same computer.
To set the default to use SDL instead of VNC, change the virtual machine's configuration information to the following. For instructions, see Section 20.1, “XL—Xen Management Tool”.
vfb = [ 'sdl=1' ]
Remember that, unlike a VNC viewer window, closing an SDL window terminates the virtual machine.
When a virtual machine is started, the host creates a virtual keyboard
that matches the keymap
entry according to the virtual
machine's settings. If there is no keymap
entry
specified, the virtual machine's keyboard defaults to English (US).
To view a virtual machine's current keymap
entry,
enter the following command on the Dom0:
xl list -l vm_name | grep keymap
To configure a virtual keyboard for a guest, use the following snippet:
vfb = [ 'keymap="de"' ]
For a complete list of supported keyboard layouts, see the
Keymaps
section of the xl.cfg
manual page man 5 xl.cfg
.
In Xen it is possible to specify how many and which CPU cores the Dom0 or VM Guest should use to retain its performance. The performance of Dom0 is important for the overall system, as the disk and network drivers are running on it. Also I/O intensive guests' workloads may consume lots of Dom0s' CPU cycles. On the other hand, the performance of VM Guests is also important, to be able to accomplish the task they were set up for.
Dedicating CPU resources to Dom0 results in a better overall performance of the virtualized environment because Dom0 has free CPU time to process I/O requests from VM Guests. Failing to dedicate exclusive CPU resources to Dom0 usually results in a poor performance and can cause the VM Guests to function incorrectly.
Dedicating CPU resources involves three basic steps: modifying Xen boot line, binding Dom0's VCPUs to a physical processor, and configuring CPU-related options on VM Guests:
First you need to append the dom0_max_vcpus=X
to
the Xen boot line. Do so by adding the following line to
/etc/default/grub
:
GRUB_CMDLINE_XEN="dom0_max_vcpus=X"
If /etc/default/grub
already contains a line
setting GRUB_CMDLINE_XEN
, rather append
dom0_max_vcpus=X
to this line.
X
needs to be replaced by the number of VCPUs
dedicated to Dom0.
Update the GRUB 2 configuration file by running the following command:
grub2-mkconfig -o /boot/grub2/grub.cfg
Reboot for the change to take effect.
The next step is to bind (or “pin”) each Dom0's VCPU to a physical processor.
xl vcpu-pin Domain-0 0 0 xl vcpu-pin Domain-0 1 1
The first line binds Dom0's VCPU number 0 to the physical processor number 0, while the second line binds Dom0's VCPU number 1 to the physical processor number 1.
Lastly, you need to make sure no VM Guest uses the physical processors dedicated to VCPUs of Dom0. Assuming you are running an 8-CPU system, you need to add
cpus="2-8"
to the configuration file of the relevant VM Guest.
It is often necessary to dedicate specific CPU resources to a virtual machine. By default, a virtual machine uses any available CPU core. Its performance can be improved by assigning a reasonable number of physical processors to it as other VM Guests are not allowed to use them after that. Assuming a machine with 8 CPU cores while a virtual machine needs to use 2 of them, change its configuration file as follows:
vcpus=2 cpus="2,3"
The above example dedicates 2
processors to the
VM Guest, and these being the 3rd and 4th one, (2
and 3
counted from zero). If you need to assign more
physical processors, use the cpus="2-8"
syntax.
If you need to change the CPU assignment for a guest named “alice” in a hotplug manner, do the following on the related Dom0:
xl vcpu-set alice 2 xl vcpu-pin alice 0 2 xl vcpu-pin alice 1 3
The example will dedicate 2 physical processors to the guest, and bind its VCPU 0 to physical processor 2 and VCPU 1 to physical processor 3. Now check the assignment:
xl vcpu-list alice Name ID VCPUs CPU State Time(s) CPU Affinity alice 4 0 2 -b- 1.9 2-3 alice 4 1 3 -b- 2.8 2-3
In Xen some features are only available for fully virtualized domains. They are not very often used, but still may be interesting in some environments.
Just as with physical hardware, it is sometimes desirable to boot a
VM Guest from a different device than its own boot device. For fully
virtual machines, it is possible to select a boot device with the
boot
parameter in a domain xl configuration file:
boot = boot_device
boot_device can be one of
c
for hard disk, d
for CD-ROM, or
n
for Network/PXE. You can specify multiple options,
and they will be attempted in the given order. For example,
boot = dc
boots from CD-ROM, and falls back to the hard disk if CD-ROM is not bootable.
To be able to migrate a VM Guest from one VM Host Server to a different
VM Host Server, it is mandatory, that the VM Guest system only uses CPU
features that are available on both VM Host Server systems. If the actual CPUs
are different on both hosts, it may be necessary to hide some features
before the VM Guest is started to maintain the possibility to
migrate the VM Guest between both hosts. For fully virtualized guests,
this can be achieved by configuring the cpuid
that is
available to the guest.
To gain an overview of the current CPU, have a look at
/proc/cpuinfo
. This contains all the important
information that defines the current CPU.
To redefine a CPU, first have a look at the respective cpuid definitions of the CPU vendor. These are available from:
cpuid = "host,tm=0,sse3=0"
The syntax is a comma-separated list of key=value pairs, preceded by the
word "host". A few keys take a numerical value, while all others take a
single character which describes what to do with the feature bit. See
man 5 xl.cfg
for a complete list of cpuid keys. The
respective bits may be changed by using the following values:
Force the corresponding bit to 1
Force the corresponding bit to 0
Use the values of the default policy
Use the values defined by the host
Like k
, but preserve the value over migrations
Note that counting bits is done from right to left, starting with bit
0
.
In case you need to increase the default number of PCI-IRQs available to
Dom0 and/or VM Guest, you can do so by modifying the Xen
kernel command line. Use the command
extra_guest_irqs=
domu_irgs,dom0_irgs. The optional first
number domu_irgs is common for all
VM Guests, while the optional second number
dom0_irgs (preceded by a comma) is for
Dom0. Changing the setting for VM Guest has no impact on
Dom0 and vice versa. For example to change Dom0 without
changing VM Guest, use
extra_guest_irqs=,512