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 backend 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, then click
.Click
+ .Select the virtual CD-ROM device 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.
![]() | New Feature |
---|---|
PVUSB is a new feature, and although it is tested and considered very useful, due to the complexity of the topic, there may well be flaws to the system. |
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 you installed the package usb-utils
, 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 number
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
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 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.
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 over 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
.