29 Virtualization: configuration options and settings #
The documentation in this section, describes advanced management tasks and configuration options that may 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.
29.1 Virtual CD readers #
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.
29.1.1 Virtual CD readers on paravirtual machines #
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.
29.1.2 Virtual CD readers on fully virtual machines #
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.
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.
29.1.3 Adding virtual CD readers #
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:
>
sudo
xl block-attach alice target=/dev/sr0,vdev=xvdb,access=roWhen assigning an image file, use the following command:
>
sudo
xl block-attach alice target=/path/to/file.iso,vdev=xvdb,access=roA 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 enterls /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,
>
sudo
mount -o ro /dev/xvdb /mntmounts 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.
29.1.4 Removing virtual CD readers #
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.
29.2 Remote access methods #
Certain 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:
- Graphical desktop with X Window System server
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
orvirt-viewer
.- Text only
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 thexl
command to manage virtual machines, and thevirt-install
command to create new virtual machines.
29.3 VNC viewer #
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 may 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, 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.
29.3.1 Assigning VNC viewer port numbers to virtual machines #
Although the default behavior of VNC viewer is to assign the first available port number, you should 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. 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 27.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.
29.3.2 Using SDL instead of a VNC viewer #
If you access a virtual machine's display from the virtual machine host console (known as local or on-box access), you should 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 27.1, “XL—Xen management tool”.
vfb = [ 'sdl=1' ]
Remember that, unlike a VNC viewer window, closing an SDL window terminates the virtual machine.
29.4 Virtual keyboards #
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
man page man 5 xl.cfg
.
29.5 Dedicating CPU resources #
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. However, the performance of VM Guests is also important, to be able to accomplish the task they were set up for.
29.5.1 Dom0 #
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 may 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 settingGRUB_CMDLINE_XEN
, rather appenddom0_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:
>
sudo
grub2-mkconfig -o /boot/grub2/grub.cfgReboot for the change to take effect.
The next step is to bind (or “pin”) each Dom0's VCPU to a physical processor.
>
sudo
xl vcpu-pin Domain-0 0 0 xl vcpu-pin Domain-0 1 1The 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.
29.5.2 VM Guests #
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 third and fourth 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:
>
sudo
xl vcpu-set alice 2>
sudo
xl vcpu-pin alice 0 2>
sudo
xl vcpu-pin alice 1 3
The example dedicates 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:
>
sudo
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
29.6 HVM features #
In Xen, certain features are only available for fully virtualized domains. They are rarely used, but still may be interesting in specific environments.
29.6.1 Specify boot device on boot #
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.
29.6.2 Changing CPUIDs for guests #
To be able to migrate a VM Guest from one VM Host Server to a different
VM Host Server, the VM Guest system may only use 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 certain features before the
VM Guest is started. This maintains 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:
- 1
Force the corresponding bit to
1
- 0
Force the corresponding bit to
0
- x
Use the values of the default policy
- k
Use the values defined by the host
- s
Like
k
, but preserve the value over migrations
Remember that counting bits is done from right to left, starting with
bit 0
.
29.6.3 Increasing the number of PCI-IRQs #
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
29.7 Virtual CPU scheduling #
The Xen hypervisor schedules virtual CPUs individually across physical CPUs. With modern CPUs supporting multiple threads on each core, virtual CPUs can run on the same core in different threads and thus influence each other. The performance of a virtual CPU running in one thread can be noticeably affected by what other virtual CPUs in other threads are doing. When these virtual CPUs belong to different guest systems, these guests can influence each other. The effect can vary, from variations in the guest CPU time accounting to worse scenarios such as side channel attack.
Scheduling granularity addresses this problem. You can specify it at boot time by using a Xen boot parameter:
sched-gran=GRANULARITY
Replace GRANULARITY with one of:
- cpu
The regular scheduling of the Xen hypervisor. Virtual CPUs of different guests can share one physical CPU core. This is the default.
- core
Virtual CPUs of a virtual core are always scheduled together on one physical core. Two or more virtual CPUs from different virtual cores will never be scheduled on the same physical core. Therefore, certain physical cores may have several of their CPUs left idle, even if there are virtual CPUs wanting to run. The impact on performance will depend on the actual workload being run inside of the guest systems. In most of the analyzed cases, the observed performance degradation, especially if under considerable load, was smaller than disabling HyperThreading, which leaves all the cores with just one thread (see the
smt
boot option at https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#smt-x86).- socket
The granularity goes even higher to a CPU socket level.