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.

Only limited support for virtual machine removable media is available in the original version of SUSE Linux Enterprise Server. Much of the following information pertains to functionality available in maintenance updates. If you are installing drivers from the SUSE Linux Enterprise Virtual Machine Driver Pack, proceed by completing one of the following: If you have updated to Virtual Machine Manager 0.3.1-0.24 or later, complete the instructions in Section 5.1.3, “Adding Virtual CD Readers” to set up the ISO image file as a virtual CD reader. The most recent Virtual Machine Manager package is available through the SUSE Linux Enterprise Server update channel. If you are running an earlier version of Virtual Machine Manager, you must set up the ISO image file as a virtual CD reader when you create the virtual machine, or add a virtual CD reader based on the ISO image file following the instructions in Section 5.1.4, “Adding Virtual CD Readers (Command Line Method)”.

dd if=/dev/cdrom of=<path to image>/cdimage.iso

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:

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 Guest 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, remote administration must be enabled on the host. You can use the YaST Remote Administration module.

Figure 5.1. YaST Remote Administration

In addition to this, change vnc-listen in /etc/xen/xend-config.sxp to open the access to the VM Guest. This is necessary, if you encounter messages like vncviewer: ConnectToTcpAddr: connect: Connection refused from a remote host. For more information about modifying xend-config.sxp see Section 4.2, “Controlling the Host by Modifying xend Settings”.

To access the virtual machine from the local console or a remote computer running a VNC viewer client, enter one of the following commands:

where host_ip is the IP address of the virtual machine host and # is the VNC viewer port number assigned to the virtual machine.

# vncviewer 192.168.3.100::5901

If you are using the built-in VNC viewer of an Internet browser, such as Internet Explorer* or Mozilla* Firefox*, use 580# as the port number, where # is the VNC viewer port number assigned to the virtual machine.

Figure 5.2. Mozilla Firefox VNC Viewer

When successfully connected, the VNC viewer shows the display of the running virtual machine.

5.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 might want to assign a specific VNC viewer port number to a specific virtual machine.

To assign a specific port number on a fully virtualized guest, edit the virtual machine’s setting (/etc/xen/vm/name) by including (vncdisplay #) where

vnc=1
vncdisplay=#
vncunused=0

vnc must be set to 1, # is the assigned port number and vncunused must exist and be set to 0 in order to make this work.

On a paravirtualized guest, edit the line vfb=['type=vnc,vncdisplay=#'] to set the viewer port number to the desired value.

Assign higher port numbers to avoid conflict with port numbers assigned by the VNC viewer, which uses the lowest available port number.

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 YaST+System+Boot Loader. 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.

Figure 5.3. Boot Loader Settings

Select the Xen section, then click Edit to manage the way the boot loader and Xen function.

Figure 5.4. Boot Loader Settings: Section Management

You can use the Boot Loader program to specify functionality, such as:

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.

title XEN
 root (hd0,5)
 kernel /boot/xen.gz hyper_parameters
 module /boot/vmlinuz-xen kernel_parameters
 module /boot/initrd-xen

title XEN
 root (hd0,5)
 kernel /boot/xen-pae.gz hyper_parameters
 module /boot/vmlinuz-xenpae kernel_parameters
 module /boot/initrd-xenpae

The title line defines sections in the boot loader file. Do not change this line, because YaST looks for the word XEN 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 kernel_parameters 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.

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, so to specify it, change the value of default from 0 to 1.

If selecting the Xen option from the boot loader starts SUSE Linux desktop environment (domain 0) in text mode, the graphics card is probably not configured correctly. To properly configure the graphics card so you can switch to graphical mode, complete the following steps:

It is recommended that operating systems running in paravirtual mode set up their kernel on a separate partition that uses a non-journaling file system, such as ext2.

Before a paravirtualized operating system can boot, the management domain must construct a virtual machine and place the paravirtualized kernel in it. Then, the paravirtualized operating system boots. To retrieve the kernel during the bootstrapping process, the virtual machine’s boot disk is mounted in read-only mode, the kernel is copied to the virtual machine’s memory, and then the boot disk is unmounted.

When a virtual machine’s operating system crashes, its disks are not shut down in an orderly manner. This should not pose a problem to a virtual machine running in full virtualization mode because the pending disk entries are checked and corrected the next time the operating system starts. If the disk is using a journaling file system, the journal is replayed to update and coordinate any pending disk entries.

This type of system crash poses a potential problem for paravirtualized operating systems. If a paravirtualized operating system using a journaled file system crashes, any pending disk entries cannot be updated and coordinated because the file system is initially mounted in read-only mode.

Therefore, it is recommended that you set virtual machine boot files, such as the kernel and ramdisk, on a separate partition that is formatted with a non-journaling file system, such as ext2.

During the process of creating a new virtual machine, initial startup settings are written to a file created at /etc/xen/vm/. During the creation process, the virtual machine starts according to settings in this file, but the settings are then transferred and stored in xend for ongoing operations.

Modifying the initial startup file to create or make changes to a virtual machine is not recommended. The preferred method for changing a virtual machine’s settings is to use Virtual Machine Manager as described in Section 4.3, “Configuring a Virtual Machine by Modifying its xend Settings” or to follow the instructions in Section 5.4, “The Boot Loader Program”.

When a virtual machine’s settings are stored in xend, it is referred to as a xen-managed domain or xen-managed virtual machine. Whenever the xen-managed virtual machine starts, it takes its settings from information stored in the xend database, not from settings in the initial startup file.

Although it is not recommended, you might need to start an existing virtual machine based on settings in the initial startup file. If you do this, any xend settings stored for the virtual machine are overwritten by the startup file settings. Initial startup files are saved to /etc/xen/vm/ vm_name . Values must be enclosed in single quotes, such as localtime = '0'.

disk = [ 'file:/var/lib/xen/images/VM1_SLES10/hda,xvda,w' ]

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>.

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.

In the device > vfb section, add the desired keymap entry to the file. 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.

To specify a mapping between physical storage and the virtual disk, you might need to edit the virtual machine’s disk information. Follow the instructions in Section 4.3, “Configuring a Virtual Machine by Modifying its xend Settings”, to change the respective device entry to the desired setting.

(vbd
  (dev xvda:disk)
  (uname file:/var/lib/xen/images/oes2l/disk0)
  (mode w)
  (type disk)
  (backend 0)
        )

Virtual disks can be based on the following types of physical devices and files. Each type includes an example statement.

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 to work, 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 is the same architecture. For example, a 64-bit paravirtualized guest running on a 64-bit hypervisor can be migrated 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 filesystems 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 4.2, “Controlling the Host by Modifying xend Settings”.

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 Virtual Machine Manager during and after installing a virtual machine.

Virtual devices are named internally in Xen using the Linux-style major and minor numbers. This is true even for non-Linux virtual machines. The number returned from xm block-list is a decimal representation of the combined major and minor numbers.

For example, if a virtual machine’s virtual disk is designated as hda, the number returned from xm block-list is 768. hda has major number 3 and minor number 0. The major number is stored as a high-order byte; the minor is the lower byte. A decimal representation is (3*256)+0 = 768. Another example, sda3 has major number 8 and minor number 3, so its decimal representation is (8*256)+3 = 2051.

Of course, it is possible to manually work backwards from a number to discover the human-readable device name. For your reference, some common mappings are listed in the following table.

/dev/hda    768
/dev/hdb    832
/dev/hdc    5632
/dev/hdd    5696
/dev/sda    2048
/dev/sdb    2064
/dev/sdc    2080
/dev/sdd    2096
/dev/xvda   51712
/dev/xvdb   51728
/dev/xvdc   51744
/dev/xvdd   51760

When a virtual machine is running, each of its file-backed virtual disks consumes a loopback device on the host. By default, the host allows up to eight loopback devices to be consumed.

To simultaneously run more file-backed virtual disks on a host, you can increase the number of available loopback devices by adding the following option to the host’s /etc/modprobe.conf.local file.

options loop max_loop=x

where x is the maximum number of loopback devices to create.

Changes take effect after the module is reloaded.

Enter rmmod loop and modprobe loop to unload and reload the module. In case rmmod does not work, unmount all existing loop devices or reboot the computer.

The save operation preserves the exact state of the virtual machine’s memory. The operation is slightly similar to hibernating a computer. The virtual machine is off, but it can be quickly restored to its previously-saved running condition. The operation does not make a copy of any portion of the virtual machine’s virtual disk.

When saved, the virtual machine is paused, its current memory state saved to a location you specify, and then the virtual machine is stopped. The amount of time to save the virtual machine depends on the amount of memory allocated. When saved, a virtual machine’s memory is returned to the pool of memory available on the host.

The restore operation is used to return a saved virtual machine to its original running state.

After using the save operation, do not boot, start, or run a virtual machine that you intend to restore. If the virtual machine is at any time restarted before it is restored, the saved memory-state file becomes invalid and should not be used to restore.

The restore operation loads a virtual machine’s previously saved memory-state file and starts the virtual machine. The virtual machine does not boot the operating system but resumes at the point that it was previously saved. The operation is slightly similar to coming out of hibernation.

The restore operation deletes the previously-saved memory-state file and assigns a new ID to the virtual machine. The virtual machine name and UUID remain the same as previously saved.

After using the save operation, do not boot, start, or run the virtual machine you intend to restore. If the virtual machine is at any time restarted before it is restored, the saved memory-state file becomes invalid and should not be used to restore.

A virtual machine’s state can be displayed in Virtual Machine Manager or by viewing the results of the xm list command, which abbreviates the state using a single character.