Contents
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 comprised 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
tap:cdrom:. This partly emulates the behavior of the
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 comprised of
virtual CD readers and virtual disks. A virtual CD reader on a fully
virtual machine interacts with the inserted CD in the way you 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/, are able to 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 Domain0.
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:
xm block-attach alice tap:cdrom:/dev/sr0 xvdb r
When assigning an image file, use the following command:
xm block-attach alice file:/path/to/file.iso xvdb r
The image files may easily be removed by using virt-manager. However, note that when adding CD readers, virt-manager uses a different device back-end for the CD reader that is not capable of changing CDs.
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 cat /proc/partitions in the virtual machine's terminal to view its block devices. | |
Run Virtual Machine Manager.
Select the virtual machine, click , and inside the VM's console window, choose +.
In the left pane, click the item and select the drive whose matches the one you want to remove.
Click to remove the virtual CD-ROM device.
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 referred to as
headless and requires the use of remote administration
technologies.
Typical configuration scenarios and technologies include:
If a graphical desktop, such as GNOME or KDE, 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 host environment by using graphical tools, such as Virtual Machine Manager.
If neither a graphical desktop nor the X Window Server, but the X Windows libraries are installed on the virtual machine host, you can use the ssh -X command from the remote computer to log in and manage the virtualization host environment. You can then use Virtual Machine Manager and the xm command to manage virtual machines and the vm-install command to create them.
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 xm command to manage virtual machines and the vm-install command to create new virtual machines.
By default, Virtual Machine Manager uses the VNC viewer to show the display of a virtual machine. You can also use VNC viewer from Domain0 (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 will have to open the tcp ports 5900:5910.
In addition to this, change vnc-listen in
/etc/xen/xend-config.sxp to open the access to the
VM Guest. For more information about modifying
xend-config.sxp see
Section 5.2, “Controlling the Host by Modifying Xend Settings”.
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 Domain0, use the following syntax:
vncviewer 192.168.1.20::590#
In this case, the IP address of Domain0 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 Xend setting of the virtual machine and change the location to the desired value:
(device
(vfb
(type vnc)
(location localhost:5902)
)
)
For more information regarding editing the Xend settings of a machine, see Section 5.1, “Virtual Machine Manager”.
![]() | |
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 5.3, “Configuring a Virtual Machine by Modifying its Xend Settings”.
If it is a fully virtual machine, use vnc=0 and sdl=1.
If it is a paravirtual virtual machine, use vfb=["type=sdl"].
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 in the
virtual machine's settings, the host uses the keymap
entry specified in host's Xend file (
xend-config.sxp). If there is no
keymap entry in either the host's Xend file or the
virtual machine's settings, the virtual machine's keyboard defaults to
English (US).
Unless you manually specify it, a keymap entry is not specified in the host's Xend file or for any virtual machine. Therefore, by default, all virtual machine settings use the English (US) virtual keyboard. It is recommended that you specify a keymap setting for Xend and for each virtual machine, especially, if you want to migrate virtual machines to different hosts
To view a virtual machine's current keymap entry, enter the following command on the Domain0:
xm list -l vm_name | grep keymap
You can specify a keymap entry to be used for all virtual machines and keymap entries for specific machines.
To specify a global keymap entry for virtual machines on the host, edit
the host's xend-config.sxp file.
To specify a keymap entry for a specific virtual machine, edit the virtual machine's settings by following instructions in Section 5.3, “Configuring a Virtual Machine by Modifying its Xend Settings”.
In the device > vfb section, add
the desired keymap entry to the file
/etc/xen/xend-config.sxp. For example, you can
specify a German keyboard. Make sure the virtual machine's operating
system is set to use the specified keyboard. After you specify the host's
keymap setting, all virtual machines created by using
the Create Virtual Machine Wizard on the host add the host's
keymap entry to their virtual machine settings.
Virtual machines created before a host's keymap entry is specified are not automatically updated. These virtual machines start with the keyboard specified by the host, but the keymap entry is not a permanent part of the virtual machine's settings. For the entry to be permanent, it must be explicitly stated in the virtual machine's settings.
Table 8.1. Language and Keymap Settings
|
Language |
Keymap Setting |
|---|---|
|
Danish |
da |
|
German |
de |
|
Swiss-German |
de-ch |
|
English (UK) |
en-gb |
|
English (US) |
en-us |
|
Spanish |
es |
|
Finnish |
fi |
|
French |
fr |
|
French-Belgium |
fr-be |
|
French-Canada |
fr-ca |
|
French-Switzerland |
fr-ch |
|
Hungarian |
hu |
|
Icelandic |
is |
|
Italian |
it |
|
Japanese |
ja |
|
Dutch |
nl |
|
Dutch-Belgium |
nl-be |
|
Norwegian |
no |
|
Polish |
pl |
|
Portuguese |
pt |
|
Portuguese-Brazil |
pt-br |
|
Russian |
ru |
|
Swedish |
sv |
USB (Universal Serial Bus) is a common method to extend the capabilities of a workstation. It is possible to attach an arbitrary number of devices to the machine, providing for example extended storage, additional keyboard or mouse, Webcams and other devices.
Xen allows to dedicate USB devices that are attached to the physical machine to a VM Guest. Note, that USB devices will not survive live migrations and it is recommended to remove any USB device before using the migration feature of Xen. Xen supports pass-through of USB devices from VM Host Server to VM Guests using two different methods:
This method only supports fully virtualized guests, but is available since Xen 3.x. It is a low-performance method which does not require any special drivers neither in Domain0 or VM Guest.
This method supports both fully virtualized and paravirtualized guests, but is available in Xen 4.0 and newer only. It requires special paravirtual Kernel drivers both in Domain0 or VM Guest.
Qemu-dm used for Xen fully virtualized guests supports pass-through of USB devices from Domain0 to the guest. Qemu-dm emulates USB 1.1 UHCI 2-port controller, which is slow and limited in features and device support. The main advantage is that the emulation pass-through is supported in all Xen 3.x and newer versions and does not require any additional back-end drivers in Domain0 or any additional front-end drivers in VM Guest.
There are several ways to assign a USB device to a VM Guest. For all of them, you need to run lsusb on the host and read the device ID number. For example, if lsusb contains the following line
Bus 001 Device 003: ID 054c:04be Any Corp.
then the device ID number is 054c:04be. This ID will
be the user in the following examples.
This method lets you quickly assign host USB devices to a VM Guest. No restart of VM Guest is needed to access the connected USB device. This device assignment is temporary and will be forgotten after you shut the VM Guest down.
Insert the relevant USB device in the USB port of the host machine and identify its ID number with lsusb..
Press Ctrl+Alt+2 to open QEMU console and enter usb_add host:054c:04be.
Verify if the assignment has been successful by checking the output of lsusb on the VM Guest. The relevant line should contain the same device ID as the host.
Note that usb_del host:054c:04be will disconnect the USB device from the VM Guest.
Another way to quickly assign (or disconnect) USB device to a VM Guest is to use xm usb-add and xm usb-del commands:
List all assignable USB devices in Domain0 with xm
usb-list-assignable-devices. Note the device ID
xxxx:yyyy for the device you want to connect to
the VM Guest.
Check existing VM Guests (xm list) and pick the one you want to assign the USB device to.
Connect the USB device to the selected VM Guest with
xm usb-add alice host:054c:04be
where alice is the VM Guest name and
054c:04be the ID of the USB device.
To permanently assign a USB device to a specified VM Guest, you need
to modify its configuration file in the
/etc/xen/vm directory. Just add the following
lines
usb = 1 usbdevice = "host:xxxx:yyyy"
and restart the relevant VM Guest. Please note that
xxxx:yyyy stands for the USB device ID to assign.
PVUSB is a new high performance method of doing USB pass-through from
Domain0 to VM Guests. It supports both USB 2.0 and USB 1.1 devices and
can be used with both fully virtualized and paravirtualized guests. It
requires special pvusb drivers in Domain0's Kernel
(xen-usbback) and the front-end driver
(xen-usbfront) in the VM Guest.
To assign a USB device with paravirtualized drivers, you first need to create a new virtual host controller (if there not already exists one) on the VM Guest, and then attach the physical USB device to it. To assign a USB device as, for example, a USB keyboard device to a VM Guest, proceed as follows:
Procedure 8.1. Adding an USB Keyboard to a VM Guest
Plug the USB keyboard device into the VM Host Server.
Make sure that the Kernel module usbbk is loaded by
the system with the command:
lsmod | grep usbbk
If the module is not loaded, load the module with the command:
modprobe usbbk
Create a virtual host controller for the VM Guest with the command:
xm usb-hc-create alice 2 8
This creates a virtual USB 2.0 host controller on the guest that has 8 ports.
On the VM Guest system, load the front-end Kernel module of PVUSB with the command:
modprobe xen-hcd
If the package usb-utils has been installed,
you can now see the host controller in the USB device list with the
command lsusb.
Check if you can list the virtual host controller from the VM Host Server with the command xm usb-list alice
On the VM Host Server system check which devices may be assigned to a guest with the command:
xm usb-list-assignable-devices
The result should look similar to the following:
4-2 : ID 047b:0002 SILITEK USB Keyboard and Mouse
The device that should be assigned to alice has the number
4-2. To assign this device to the first virtual
host controller with number 0 on its port 1, run the command:
xm usb-attach alice 0 1 4-2
After completing this procedure, you may use the keyboard, for example, to type inside a VNC window.
To detach the USB device, you need to know the number of the virtual
host controller and the port number of the assigned device inside the
VM Guest. The port numbers of the host controllers start with the
0, and the port numbers with 1.
List currently assigned devices with the command xm usb-list
alice. The result should look similar to the following:
# xm usb-list alice Idx BE state usb-ver BE-path 0 0 4 USB2.0 /local/domain/0/backend/vusb/2/0 port 1: 4-2 [ID 047b:0002 SILITEK USB Keyboard and Mouse] port 2: port 3: port 4: port 5: port 6: port 7: port 8:
Remove this device with the command:
xm usb-detach alice 0 1
![]() | Assigning the Whole Controller |
|---|---|
You can also use PCI pass-through to pass through the whole USB controller PCI device, with all USB devices connected to it. For more information see Section 2.5, “PCI Pass-Through”. | |
While xm usb-attach is a “hot-plugging” way of connecting a USB device to a VM Guest and the related device assignment will be forgotten after the guest system is switched off, you can add corresponding configuration options to the VM Guest's configuration file make the assignment permanent.
The same effect that can be reached with
xm usb-hc-create alice 2 4 && xm usb-attach alice 0 1 1-8
can be accomplished by adding the following line
vusb=['usbver=2, numports=4, port_1=1-8']
to the VM Guest's configuration file in the
/etc/xen/vm directory and restarting it.
usbver= specifies the USB version,
numports= specifies the number of ports of the
virtual controller, and port_1= specifies which
physical USB device will be assigned to port 1 of the controller (can
be up to port_16=).
In Xen it is possible to specify how many and which CPU cores the Domain0 or VM Guest should use to retain its performance. The performance of Domain0 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 Domain0′s 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 Domain0 results in a better overall performance of the virtualized environment because Domain0 has free CPU time to process I/O requests from VM Guests. Failing to dedicate exclusive CPU resources to Domain0 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 Domain0'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 in /boot/grub/menu.lst, where
X is the number of VCPUs dedicated to Domain0. An
example Kernel boot entry follows:
title Xen -- SUSE Linux Enterprise Server 11 SP2 - 3.0.4-0.11 root (hd0,1) kernel /boot/xen.gz dom0_max_vcpus=2 module /boot/vmlinuz-3.0.4-0.11-xen module /boot/initrd-3.0.4-0.11-xen
Restart the Xen Kernel for the change to take effect.
The next step is to bind (or “pin”) each Domain0's VCPU to a physical processor.
xm vcpu-pin Domain-0 0 0 xm vcpu-pin Domain-0 1 1
The first line binds Domain0's VCPU number 0 to the physical processor number 0, while the second line binds Domain0'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 Domain0. Assuming you are running a 8-CPU system, you need to add
cpus="2-8"
to the configuration file of the relevant VM Guest.
It is often needed 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 make use of 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 it is exactly the 3rd and 4rd 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 Domain0:
xm vcpu-set alice 2 xm vcpu-pin alice 0 2 xm 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:
xm 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
When working with several VM Host Server systems that may run a pool of guests, a common task is to ensure that the guest systems are not started twice. Depending on the used block and network devices, this could lead to network problems as well as corrupted block devices.
Xen provides a mechanism that checks a lock file before a guest is
started. In order to use this mechanism, a distributed file system like
NFS or a cluster file system is needed. For example, a distributed file
system mounted to /srv/xen may be used.
The Xen domain lock functionality is configured in the Xend
configuration file /etc/xen/xend-config.sxp. At the
end of this file, the two parameters
xend-domain-lock and
xend-domain-lock-path control the behavior. To
use the directory /srv/xen as a locking directory,
modify the settings as follows:
(xend-domain-lock yes) (xend-domain-lock-path /xen/lock)
Activate the new settings either by rebooting the VM Host Server system, or by
restarting xend with the command rcxend
restart.
When all VM Host Server systems use this locking directory, Xen will refuse to start a VM Guest twice.
Xen 4.1 introduced xenpaging — an advanced way of VM Guests' memory management. Xenpaging allows memory over-commit where the total memory used by all running guests exceeds the amount of memory available on the host. It writes memory pages of a given guest to a file and moves the pages back to the pool of available memory. Once the guest wants to access the paged-out memory, the page is read from the disk and placed into the guest's memory. This allows the sum of all running guests to use more memory than physically available on the host.
To enable xenpaging for an already running VM Guest, find the guest's ID
with xm list. Change to a directory where you want to
create the pagefile (/var/lib/xen/xenpaging/) and
run the following command on Domain0
xenpaging 1 32768
where 1 is the ID of the guest you want to enable
xenpaging for, and 32768 is the number of memory pages
you want to save (32768 corresponds to 128MB pagefile).
After rebooting the guest, its ID changes dynamically, and the current
xenpaging binary has no target anymore. To automate restarting of
xenpaging after a guest reboot, specify the number of pages in the guest
configuration file in the /etc/xen/vm/ directory:
xenpaging=32768
Then redo the guest with xm create /etc/xen/vm/<vm_guest_name> to activate the changes.
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, the managing program virt-manager provides a possibility to achieve this.
Procedure 8.2. Select Boot Device in virt-manager
Start virt-manager and connect to the needed Xen host.
Right-click the stopped machine, and select .
Choose + to get an overview of the VM Guest.
Select .
A drop down box appears, that gives you a selection of bootable devices. Select the correct device and press
Then press to start the VM Guest. The is also available from the screen.
Depending on the desired tasks, it may be necessary to reset the boot device again.
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 of the
features before the VM Guest is started in order 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:
The cpuid is organized in several 32 bit bitmasks. In an sxp configuration, a cpuid entry that just supplies values with the default policy would look like the following:
(cpuid
( (0
(
(eax xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
(edx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
(ebx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
(ecx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
)
)
) )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 the left, starting with
bit 0.
For an example about how to use this feature with configuration scripts
in /etc/xen/vm, see
/etc/xen/examples/xmexample.hvm.