SUSE Linux Enterprise
www.novell.com11 SP1
August18,2010 Virtualization with Xen
Desktop
Virtualization with Xen
All content is copyright © 2006–2010 Novell, Inc. All rights reserved.
Legal Notice
This manual is protected under Novell intellectual property rights. By reproducing, duplicating or
distributing this manual you explicitly agree to conform to the terms and conditions of this license
agreement.
This manual may be freely reproduced, duplicated and distributed either as such or as part of a bundled
package in electronic and/or printed format, provided however that the following conditions are fullled:
That this copyright notice and the names of authors and contributors appear clearly and distinctively
on all reproduced, duplicated and distributed copies. That this manual, specically for the printed
format, is reproduced and/or distributed for noncommercial use only. The express authorization of
Novell, Inc must be obtained prior to any other use of any manual or part thereof.
For Novell trademarks, see the Novell Trademark and Service Mark list http://www.novell
.com/company/legal/trademarks/tmlist.html. * Linux is a registered trademark of
Linus Torvalds. All other third party trademarks are the property of their respective owners. A trademark
symbol (®, ™ etc.) denotes a Novell trademark; an asterisk (*) denotes a third party trademark.
All information found in this book has been compiled with utmost attention to detail. However, this
does not guarantee complete accuracy. Neither Novell, Inc., SUSE LINUX Products GmbH, the authors,
nor the translators shall be held liable for possible errors or the consequences thereof.
Contents
About This Manual vii
Part I Getting Started with Xen 1
1 Introduction to Xen Virtualization 3
1.1 Basic Components . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Understanding Virtualization Modes . . . . . . . . . . . . . . . . . 5
1.3 Xen Virtualization Architecture . . . . . . . . . . . . . . . . . . . . 5
1.4 The Virtual Machine Host . . . . . . . . . . . . . . . . . . . . . . 6
2 Setting Up a Virtual Machine Host 9
2.1 Best Practices and Suggestions . . . . . . . . . . . . . . . . . . . 10
2.2 Managing Domain0 Memory . . . . . . . . . . . . . . . . . . . . 11
2.3 Network Card in Fully Virtualized Guests . . . . . . . . . . . . . . . 12
2.4 Starting the Virtual Machine Host . . . . . . . . . . . . . . . . . . 14
2.5 PCI Pass-Through . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Setting Up Virtual Machines 19
3.1 Creating a Virtual Machine . . . . . . . . . . . . . . . . . . . . . 20
3.2 Installing an Operating System . . . . . . . . . . . . . . . . . . . 21
3.3 Including Add-On Products in the Installation . . . . . . . . . . . . . 25
3.4 Using the Command Line to Create Virtual Machines . . . . . . . . . . 26
3.5 Deleting Virtual Machines . . . . . . . . . . . . . . . . . . . . . 26
3.6 Using an Existing SUSE Linux Enterprise Desktop Virtual Machine . . . . . 27
3.7 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Updating SLE 10 Systems to SLE 11 29
4.1 Boot Loader Conguration . . . . . . . . . . . . . . . . . . . . . 30
Part II Advanced Congurations 31
5 Managing a Virtualization Environment 33
5.1 Virtual Machine Manager . . . . . . . . . . . . . . . . . . . . . 34
5.2 Controlling the Host by Modifying Xend Settings . . . . . . . . . . . . 36
5.3 Conguring a Virtual Machine by Modifying its Xend Settings . . . . . . 37
5.4
The xm Command . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.5 Automatic Starting of Domains . . . . . . . . . . . . . . . . . . . 40
5.6 Migrating Xen VM Guest Systems . . . . . . . . . . . . . . . . . . 41
6 Virtual Networking 45
6.1 Virtual Bridges . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2 Network Devices for Guest Systems . . . . . . . . . . . . . . . . . 47
6.3 Host Based Routing in Xen . . . . . . . . . . . . . . . . . . . . . 48
6.4 Creating a Masqueraded Network Setup . . . . . . . . . . . . . . . 51
6.5 Special Congurations . . . . . . . . . . . . . . . . . . . . . . . 53
7 Block Devices in Xen 59
7.1 Mapping Physical Storage to Virtual Disks . . . . . . . . . . . . . . . 59
7.2 File-Backed Virtual Disks and Loopback Devices . . . . . . . . . . . . 61
7.3 Resizing Block Devices . . . . . . . . . . . . . . . . . . . . . . . 62
8 Virtualization: Conguration Options and Settings 63
8.1 Virtual CD Readers . . . . . . . . . . . . . . . . . . . . . . . . 63
8.2 Remote Access Methods . . . . . . . . . . . . . . . . . . . . . . 66
8.3 VNC Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.4 Virtual Keyboards . . . . . . . . . . . . . . . . . . . . . . . . . 69
8.5 Using PVUSB . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.6 Using Lock Files . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.7 HVM Features . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Part III Administration and Best Practices 77
9 Administration Tasks 79
9.1 The Boot Loader Program . . . . . . . . . . . . . . . . . . . . . 79
9.2 Sparse Image Files and Disk Space . . . . . . . . . . . . . . . . . . 82
9.3 Migrating Virtual Machines . . . . . . . . . . . . . . . . . . . . . 84
9.4 Passing Key Combinations to Virtual Machines . . . . . . . . . . . . . 84
9.5 Monitoring Xen . . . . . . . . . . . . . . . . . . . . . . . . . . 85
9.6 Extra Guest Descriptions in Xen Conguration . . . . . . . . . . . . . 87
9.7 Providing Host Information for VM Guest Systems . . . . . . . . . . . 88
10 Save and Restore of Virtual Machines 91
10.1 Saving Virtual Machines . . . . . . . . . . . . . . . . . . . . . . 91
10.2 Restoring Virtual Machines . . . . . . . . . . . . . . . . . . . . . 92
10.3 Virtual Machine States . . . . . . . . . . . . . . . . . . . . . . . 93
11 Xen as High Availability Virtualization Host 95
11.1 Xen HA with Remote Storage . . . . . . . . . . . . . . . . . . . . 95
11.2 Xen HA with Local Storage . . . . . . . . . . . . . . . . . . . . . 96
11.3 Xen HA and Private Bridges . . . . . . . . . . . . . . . . . . . . . 97
12 SUSE Linux Virtual Machines 99
12.1 Using the Add-On Products Program . . . . . . . . . . . . . . . . 100
12.2 Virtual Machine Clock Settings . . . . . . . . . . . . . . . . . . . 100
12.3 Updating a Network Installation Source . . . . . . . . . . . . . . . 102
13 Virtual Machine Drivers 105
Part IV Appendix 107
A Virtual Machine Initial Start-Up Files 109
B SXP Conguration Options 113
About This Manual
This manual offers an introduction to virtualization technology of your SUSE Linux
Enterprise Desktop. It features an overview of the various elds of application and installation types of each of the platforms supported by SUSE Linux Enterprise Desktop
as well as a short description of the installation procedure.
Many chapters in this manual contain links to additional documentation resources. This
includes additional documentation that is available on the system as well as documentation available on the Internet.
For an overview of the documentation available for your product and the latest documentation updates, refer to http://www.novell.com/documentation.
Quality service is also available. Experts can answer questions about installation or
conguration, make reliable security updates available, and support development
projects.
Documentation regarding the Open Enterprise Server 2 is found at http://www
.novell.com/documentation/oes2/index.html.
1 Available Documentation
We provide HTML and PDF versions of our books in different languages. The following
manuals for users and administrators are available on this product:
KDE User Guide (↑KDE User Guide)
Introduces the KDE desktop of SUSE Linux Enterprise Desktop. It guides you
through using and conguring the desktop and helps you perform key tasks. It is
intended mainly for users who want to make efcient use of KDE as their default
desktop.
GNOME User Guide (↑GNOME User Guide)
Introduces the GNOME desktop of SUSE Linux Enterprise Desktop. It guides you
through using and conguring the desktop and helps you perform key tasks. It is
intended mainly for end users who want to make efcient use of GNOME desktop
as their default desktop.
Application Guide (↑Application Guide)
Learn how to use and congure key desktop applications on SUSE Linux Enterprise
Desktop. This guide introduces browsers and e-mail clients as well as ofce applications and collaboration tools. It also covers graphics and multimedia applications.
Deployment Guide (↑Deployment Guide)
Shows how to install single or multiple systems and how to exploit the product
inherent capabilities for a deployment infrastructure. Choose from various approaches, ranging from a local installation or a network installation server to a mass deployment using a remote-controlled, highly-customized, and automated installation
technique.
Administration Guide (↑Administration Guide)
Covers system administration tasks like maintaining, monitoring and customizing
an initially installed system.
Security Guide (↑Security Guide)
Introduces basic concepts of system security, covering both local and network security aspects. Shows how to make use of the product inherent security software
like Novell AppArmor (which lets you specify per program which les the program
may read, write, and execute) or the auditing system that reliably collects information about any security-relevant events.
System Analysis and Tuning Guide (↑System Analysis and Tuning Guide)
An administrator's guide for problem detection, resolution and optimization. Find
how to inspect and optimize your system by means of monitoring tools and how
to efciently manage resources. Also contains an overview of common problems
and solutions and of additional help and documentation resources.
Virtualization with Xen (page 1)
Offers an introduction to virtualization technology of your product. It features an
overview of the various elds of application and installation types of each of the
platforms supported by SUSE Linux Enterprise Server as well as a short description
of the installation procedure.
In addition to the comprehensive manuals, several quick start guides are available:
KDE Quick Start (↑KDE Quick Start)
Gives a short introduction to the KDE desktop and some key applications running
on it.
viii Virtualization with Xen
GNOME Quick Start (↑GNOME Quick Start)
Gives a short introduction to the GNOME desktop and some key applications
running on it.
OpenOfce.org Quick Start
Gives a short introduction into the OpenOfce.org suite and its modules for writing
texts, working with spreadsheets, or creating graphics and presentations.
Installation Quick Start (↑Installation Quick Start)
Lists the system requirements and guides you step-by-step through the installation
of SUSE Linux Enterprise Desktop from DVD, or from an ISO image.
Linux Audit Quick Start
Gives a short overview how to enable and congure the auditing system and how
to execute key tasks such as setting up audit rules, generating reports, and analyzing
the log les.
Novell AppArmor Quick Start
Helps you understand the main concepts behind Novell® AppArmor.
Find HTML versions of most product manuals in your installed system under /usr/
share/doc/manual or in the help centers of your desktop. Find the latest documentation updates at http://www.novell.com/documentation where you can
download PDF or HTML versions of the manuals for your product.
2 Feedback
Several feedback channels are available:
Bugs and Enhancement Requests
For services and support options available for your product, refer to http://www
.novell.com/services/.
To report bugs for a product component, please use http://support.novell
.com/additional/bugreport.html.
Submit enhancement requests at https://secure-www.novell.com/rms/
rmsTool?action=ReqActions.viewAddPage&return=www.
About This Manual ix
User Comments
We want to hear your comments and suggestions about this manual and the other
documentation included with this product. Use the User Comments feature at the
bottom of each page in the online documentation or go to http://www.novell
.com/documentation/feedback.html and enter your comments there.
3 Documentation Conventions
The following typographical conventions are used in this manual:
•
/etc/passwd: directory names and lenames
•
placeholder: replace placeholder with the actual value
•
PATH: the environment variable PATH
•
ls, --help: commands, options, and parameters
•
user: users or groups
•
Alt, Alt + F1: a key to press or a key combination; keys are shown in uppercase as
on a keyboard
•
File, File > Save As: menu items, buttons
•
Dancing Penguins (Chapter Penguins, ↑Another Manual): This is a reference to a
chapter in another manual.
x Virtualization with Xen
Part I. Getting Started with Xen
Introduction to Xen Virtualization
Virtualization of operating systems is used in many different computing areas. It nds
its applications in server consolidation, energy saving efforts, or the ability to run older
software on new hardware, for example. This chapter introduces and explains the
components and technologies you need to understand to set up and manage a Xen-based
virtualization environment.
1.1 Basic Components
The basic components of a Xen-based virtualization environment are the Xen hypervisor,
the Domain0, any number of other VM Guests, and the tools, commands, and conguration les that let you manage virtualization. Collectively, the physical computer running all these components is referred to as a VM Host Server because together these
components form a platform for hosting virtual machines.
The Xen Hypervisor
The Xen hypervisor, sometimes referred to generically as a virtual machine monitor,
is an open-source software program that coordinates the low-level interaction between virtual machines and physical hardware.
The Domain0
The virtual machine host environment, also referred to as Domain0 or controlling
domain, is comprised of several components, such as:
1
Introduction to Xen Virtualization 3
• The SUSE Linux operating system, which gives the administrator a graphical
and command line environment to manage the virtual machine host components
and its virtual machines.
NOTE
The term “Domain0” refers to a special domain that provides the management environment. This may be run either in graphical or in command
line mode.
• The xend daemon (xend), which stores conguration information about each
virtual machine and controls how virtual machines are created and managed.
• A modied version of QEMU, which is an open-source software program that
emulates a full computer system, including a processor and various peripherals.
It provides the ability to host operating systems in full virtualization mode.
Xen-Based Virtual Machines
A Xen-based virtual machine, also referred to as a VM Guest or DomU consists
of the following components:
• At least one virtual disk that contains a bootable operating system. The virtual
disk can be based on a le, partition, volume, or other type of block device.
• Virtual machine conguration information, which can be modied by exporting
a text-based conguration le from xend or through Virtual Machine Manager.
• A number of network devices, connected to the virtual network provided by the
controlling domain.
Management Tools, Commands, and Conguration Files
There is a combination of GUI tools, commands, and conguration les to help
you manage and customize your virtualization environment.
4 Virtualization with Xen
1.2 Understanding Virtualization Modes
Guest operating systems are hosted on virtual machines in either full virtualization
mode or paravirtual mode. Each virtualization mode has advantages and disadvantages.
• Full virtualization mode lets virtual machines run unmodied operating systems,
such as Windows* Server 2003 and Windows XP, but requires the computer running
as the VM Host Server to support hardware-assisted virtualization technology, such
as AMD* Virtualization or Intel* Virtualization Technology.
Some guest operating systems hosted in full virtualization mode, can be congured
to run the Novell* Virtual Machine Drivers instead of drivers originating from the
operating system. Running virtual machine drivers improves performance dramatically on guest operating systems, such as Windows XP and Windows Server 2003.
For more information, see Chapter 13, Virtual Machine Drivers (page 105).
• Paravirtual mode does not require the host computer to support hardware-assisted
virtualization technology, but does require the guest operating system to be modied
for the virtualization environment. Typically, operating systems running in paravirtual mode enjoy better performance than those requiring full virtualization mode.
Operating systems currently modied to run in paravirtual mode are referred to as
paravirtualized operating systems and include SUSE Linux Enterprise Desktop 11
and NetWare® 6.5 SP8.
1.3 Xen Virtualization Architecture
The following graphic depicts a virtual machine host with four virtual machines. The
Xen hypervisor is shown as running directly on the physical hardware platform. Note,
that the controlling domain is also just a virtual machine, although it has several additional management tasks compared to all other virtual machines.
Introduction to Xen Virtualization 5
Figure 1.1
On the left, the virtual machine host’s Domain0 is shown running the SUSE Linux operating system. The two virtual machines shown in the middle are running paravirtualized
operating systems. The virtual machine on the right shows a fully virtual machine running an unmodied operating system, such as Windows Server 2003 or Windows XP.
Virtualization Architecture
1.4 The Virtual Machine Host
After you install the virtualization components and reboot the computer, the GRUB
boot loader menu displays a Xen menu option. Selecting the Xen menu option loads
the Xen hypervisor and starts the Domain0 running the SUSE Linux operating system.
Running on Domain0, the SUSE Linux operating system displays the installed text
console or desktop environment, such as GNOME or KDE. The terminals of VM Guest
systems are displayed in their own window inside the controlling Domain0 when opened.
6 Virtualization with Xen
Figure 1.2
Desktop Showing Virtual Machine Manager and Virtual Machines
Introduction to Xen Virtualization 7
Setting Up a Virtual Machine Host
This section documents how to set up and use SUSE Linux Enterprise Desktop 11 SP1
as a virtual machine host.
In most cases, the hardware requirements for the Domain0 are the same as those for
the SUSE Linux Enterprise Desktop operating system, but additional CPU, disk,
memory, and network resources should be added to accommodate the resource demands
of all planned VM Guest systems.
TIP
Remember that VM Guest systems, just like physical machines, perform better
when they run on faster processors and have access to more system memory.
The following table lists the minimum hardware requirements for running a typical
virtualized environment. Additional requirements have to be added for the number and
type of the respective guest systems.
Table 2.1
nent
Hardware Requirements
Minimum RequirementsSystem Compo-
2
Computer with Pentium II or AMD K7 450 MHz processorComputer
512 MB of RAM for the hostMemory
Setting Up a Virtual Machine Host 9
Minimum RequirementsSystem Compo-
nent
7 GB of available disk space for the host.Free Disk Space
DVD-ROM DriveOptical Drive
20 GBHard Drive
Ethernet 100 MbpsNetwork Device
IP Address • One IP address on a subnet for the host.
• One IP address on a subnet for each VM Guest.
Xen virtualization technology is available in SUSE Linux Enterprise Desktop products
based on code path 10 and later. Code path 10 products include Open Enterprise Server
2 Linux, SUSE Linux Enterprise Desktop 10, SUSE Linux Enterprise Desktop 10, and
openSUSE 10.x.
The virtual machine host requires a number of software packages and their dependencies
to be installed. To install all necessary packages, run YaST Software Management, select
View > Patterns and choose Xen Virtual Machine Host Server for installation. The installation can also be performed with YaST using the module Virtualization > Install
Hypervisor and Tools.
After the Xen software is installed, restart the computer.
Updates are available through your update channel. To be sure to have the latest updates
installed, run YaST Online Update after the installation has nished.
2.1 Best Practices and Suggestions
When installing and conguring the SUSE Linux Enterprise operating system on the
host, be aware of the following best practices and suggestions:
10 Virtualization with Xen
•
If the host should always run as Xen host, run YaST System > Boot Loader and
activate the Xen boot entry as default boot section.
•
In YaST, click System > Boot Loader.
•
Change the default boot to the Xen label, then click Set as Default.
•
Click Finish.
• Close Virtual Machine Manager if you are not actively using it and restart it when
needed. Closing Virtual Machine Manager does not affect the state of virtual machines.
• For best performance, only the applications and processes required for virtualization
should be installed on the virtual machine host.
• When using both, iSCSI and OCFS2 to host Xen images, the latency required for
OCFS2 default timeouts in SP2 may not be met. To recongure this timeout, run
/etc/init.d/o2cb configure or edit O2CB_HEARTBEAT_THRESHOLD
in the system conguration.
2.2 Managing Domain0 Memory
When the host is set up, a percentage of system memory is reserved for the hypervisor,
and all remaining memory is automatically allocated to Domain0.
A better solution is to set a default amount of memory for Domain0, so the memory
can be allocated appropriately to the hypervisor. An adequate amount would be 20
percent of the total system memory up to 2 GB. An appropriate minimum amount would
be 512 MB.
2.2.1 Setting a Maximum Amount of
Memory
Determine the amount of memory to set for Domain0.
1
Setting Up a Virtual Machine Host 11
2
At Domain0, type xm info to view the amount of memory that is available on
the machine. The memory that is currently allocated by Domain0 can be deter-
mined with the command xm list.
Run YaST > Boot Loader.
3
Select the Xen section.
4
5
In Additional Xen Hypervisor Parameters, add dom0_mem=mem_amount
where mem_amount is the maximum amount of memory to allocate to Domain0.
Add K, M, or G, to specify the size, for example, dom0_mem=768M.
Restart the computer to apply the changes.
6
2.2.2 Setting a Minimum Amount of Memory
To set a minimum amount of memory for Domain0, edit the dom0-min-mem parameter in the /etc/xen/xend-config.sxp le and restart Xend. For more informa-
tion, see Section 5.2, “Controlling the Host by Modifying Xend Settings” (page 36).
2.3 Network Card in Fully Virtualized Guests
In a fully virtualized guest, the default network card is an emulated Realtek network
card. However, it also possible to use the split network driver to run the communication
between Domain0 and a VM Guest. By default, both interfaces are presented to the
VM Guest, because the drivers of some operating systems require both to be present.
When using SUSE Linux Enterprise, only the paravirtualized network cards are available
for the VM Guest by default. The following network options are available:
emulated
To use a “emulated” network interface like an emulated Realtek card, specify
(type ioemu) in the vif device section of the Xend conguration. An example
conguration would look like:
12 Virtualization with Xen
(device
(vif
(bridge br0)
(uuid e2b8f872-88c7-0a4a-b965-82f7d5bdd31e)
(devid 0)
(mac 00:16:3e:54:79:a6)
(model rtl8139)
(type ioemu)
)
)
Find more details about editing the Xend conguration at Section 5.3, “Conguring
a Virtual Machine by Modifying its Xend Settings” (page 37).
paravirtualized
When not specifying a model or type, Xend uses the paravirtualized network interface:
(device
(vif
(bridge br0)
(mac 00:16:3e:50:66:a4)
(script /etc/xen/scripts/vif-bridge)
(uuid 0a94b603-8b90-3ba8-bd1a-ac940c326514)
(backend 0)
)
)
emulated and paravirtualized
If the administrator should be offered both options, simply specify both, type and
model. The Xend conguration would look like:
(device
(vif
(bridge br0)
(uuid e2b8f872-88c7-0a4a-b965-82f7d5bdd31e)
(devid 0)
(mac 00:16:3e:54:79:a6)
(model rtl8139)
(type netfront)
)
)
In this case, one of the network interfaces should be disabled on the VM Guest.
Setting Up a Virtual Machine Host 13
2.4 Starting the Virtual Machine Host
If virtualization software is correctly installed, the computer boots to display the GRUB
boot loader with a Xen option on the menu. Select this option to start the virtual machine
host.
NOTE: Xen and Kdump
In Xen, the hypervisor manages the memory resource. If you need to reserve
system memory for a recovery kernel in Domain0, this memory has to be reserved by the hypervisor. Thus, it is necessary to add the parameter
crashkernel=size@offset to the kernel line instead of using the line
with the other boot options. For more about Kdump, see also http://www
.novell.com/rc/docrepository/public/37/basedocument
.2007-09-13.2960758124/4622069_f_en.pdf.
If the Xen option is not on the GRUB menu, review the steps for installation and verify
that the GRUB boot loader has been updated. If the installation has been done without
selecting the Xen pattern, run the YaST Software Management, select the lter Patterns
and choose Xen Virtual Machine Host Server for installation.
After booting the hypervisor, the Domain0 virtual machine starts and displays its
graphical desktop environment. If you did not install a graphical desktop, the command
line environment appears.
TIP: Graphics Problems
Sometimes it may happen that the graphics system does not work properly. In
this case, add vga=ask to the boot parameters. To activate permanent settings,
use vga=mode-0x??? where ??? is calculated as 0x100 + VESA mode from
http://en.wikipedia.org/wiki/VESA_BIOS_Extensions, e.g.
vga=mode-0x361.
Before starting to install virtual guests, make sure that the system time is correct. To
do this, congure NTP (Network Time Protocol) on the controlling domain:
In YaST select Network Services > NTP Conguration.
1
14 Virtualization with Xen
Select the option to automatically start the NTP daemon during boot. Provide
2
the IP address of an existing NTP time server, then click Finish.
NOTE: Time Services on Virtual Guests
Hardware clocks commonly are not very precise. All modern operating systems
try to correct the system time compared to the hardware time by means of an
additional time source. To get the correct time on all VM Guest systems, also
activate the network time services on each respective guest or make sure that
the guest uses the system time of the host. For more about Independent
Wallclocks in SUSE Linux Enterprise Desktop see Section 12.2, “Virtual Machine Clock Settings” (page 100).
For more information about managing virtual machines, see Chapter 5, Managing a
Virtualization Environment (page 33).
2.5 PCI Pass-Through
To take full advantage of VM Guest systems, it is sometimes necessary to assign specic PCI devices to a dedicated domain. When using fully virtualized guests, this
functionality is only available if the chipset of the system supports this feature, and if
it is activated from the BIOS.
This feature is available from both, AMD* and Intel*. For AMD machines, the feature
is called IOMMU, in Intel speak, this is VT-d. Note that Intel-VT technology is not
sufcient to use this feature for fully virtualized guests. To make sure that your computer supports this feature, ask your supplier specically to deliver a system that supports
PCI Pass-Through.
Limitations
• Some graphics drivers use highly optimized ways to access DMA. This is not always
supported, and thus using graphics cards may be difcult.
• When accessing PCI devices behind a PCIe bridge, all of the PCI devices must be
assigned to a single guest. This limitations does not apply to PCIe devices.
• Guests with dedicated PCI devices cannot be live migrated to a different host.
Setting Up a Virtual Machine Host 15
The conguration of PCI Pass-Through is twofold. First, the hypervisor must be informed at boot time that a PCI device should be available for reassigning. Second, the
PCI device must be assigned to the VM Guest.
2.5.1 Conguring the Hypervisor for PCI
Pass-Through
1
Select a device to reassign to a VM Guest. To do this run lspci and read the
device number. For example, if lspci contains the following line:
06:01.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43 (rev 41)
In this case, the PCI number is (06:01.0).
Run YaST > System > Boot Loader.
2
3
Select the Xen section and press Edit.
Add the PCI number to the Optional Kernel Command Line Parameter line:
4
pciback.hide=(06:01.0)
5
When preparing for fully virtualized guests, add the parameter iommu=1 to
Additional Xen Hypervisor Parameters.
Press OK and nish YaST.
6
Reboot the system.
7
Check if the device is in the list of assignable devices with the command
8
xm pci-list-assignable-devices
2.5.2 Assigning PCI Devices to VM Guest
Systems
There are several possibilities to dedicate a PCI device to a VM Guest:
16 Virtualization with Xen
Adding the device while installing:
During installation, add the pci line to the conguration le:
pci=['06:01.0']
Hot adding PCI devices to VM Guest systems
The command xm may be used to add or remove PCI devices on the y. To Add
the device with number 06:01.0 to a guest with name sles11 use:
xm pci-attach sles11 06:01.0
Adding the PCI device to Xend
To add the device to the Xend database, add the following section to the Xend
database:
(device
(pci
(dev
(slot 0x01)
(domain 0x0)
(bus 0x06)
(vslt 0x0)
(func 0x0)
)
)
)
For more information about modifying the Xend database, see Section 5.3, “Conguring a Virtual Machine by Modifying its Xend Settings” (page 37).
After assigning the PCI device to the VM Guest, the guest system must care for the
conguration and device drivers for this device.
2.5.3 For More Information
There are several resources that provide interesting information about PCI Pass-Through
in the net:
• http://wiki.xensource.com/xenwiki/VTdHowTo
•
http://software.intel.com/en-us/forums/
virtualization-software-development/topic/56802/page/1/
Setting Up a Virtual Machine Host 17
•
http://software.intel.com/en-us/articles/
intel-virtualization-technology-for-directed-io-vt-d-enhancing-intel-platforms-for-efficient-virtualization-of-io-devices/
•
http://www.amd.com/us-en/assets/content_type/white_papers
_and_tech_docs/34434.pdf
18 Virtualization with Xen
Setting Up Virtual Machines
A virtual machine is comprised of data and operating system les that dene the virtual
environment. Virtual machines are hosted and controlled by the VM Host Server. This
section provides generalized instructions for installing virtual machines.
Virtual machines have few if any requirements above those required to run the operating
system. If the operating system has not been optimized for the virtual machine host
environment, the unmodied OS can run only on hardware-assisted virtualization
computer hardware, in full virtualization mode, and requires specic device drivers to
be loaded. The hardware that is presented to the VM Guest depends on the conguration
of the Xend.
You should be aware of any licensing issues related to running a single licensed copy
of an operating system on multiple virtual machines. Consult the operating system license
agreement for more information.
NOTE: Virtual Machine Architectures
The virtual machine host runs only on x86, AMD64 and Intel 64 hardware. It
does not run on other system architectures such as Itanium, or POWER. A 64bit virtual machine host can also run a 32-bit operating system, while a 32-bit
host cannot run a 64-bit client. This holds true for both, the controlling domain
and all further guests.
3
Setting Up Virtual Machines 19
3.1 Creating a Virtual Machine
Before creating a virtual machine, you need the following:
•
Install a host server as described in Chapter 2, Setting Up a Virtual Machine Host
(page 9).
• If you want to use an automated installation le (AutoYaST, NetWare® Response
File, or RedHat Kickstart), you should create and download it to a directory on the
host machine server or make it available on the network.
• For NetWare and OES Linux virtual machines, you need a static IP address for
each virtual machine you create.
• If you are installing Open Enterprise Server (OES) 2 Linux, you need a network
installation source for OES 2 Linux software. For procedures to create the installation sources, see the SUSE Linux Enterprise Desktop Deployment Guide.
For further prerequisites, consult the manuals of the respective operating system to install.
The Create Virtual Machine Wizard (YaST > Virtualization > Create Virtual Machines)
helps you through the steps required to create a virtual machine and install its operating
system. The information that follows is generalized for installing any operating system.
The actual conguration le for the Xen guests that is used for the installation is stored
at /etc/xen/vm/. The default location for image les is /var/lib/xen/images.
Be aware, that the conguration may be changed later on, but these changes will only
be available in the Xend. For more information about Xend, see Section 5.3, “Conguring a Virtual Machine by Modifying its Xend Settings” (page 37).
Launch the Create Virtual Machine Wizard by using one of the following methods:
•
From the virtualization host server desktop, click YaST > Virtualization > Create
Virtual Machine
•
From within Virtual Machine Manager, click New.
•
At the command line, enter vm-install.
20 Virtualization with Xen
If the wizard does not appear or the vm-install command does not work, review
the process of installing and starting the virtualization host server. The virtualization
software might not be installed properly.
3.2 Installing an Operating System
You can choose to run an installation program or choose a disk or disk image that already
has an installed and bootable operating system.
Figure 3.1
If you choose to run an installation program, you are presented with a list of operating
systems. Select the one you want to install.
The Summary page shows you a summary of the virtual machine you are creating. You
can click on any of the headings to edit the information.
Installing an Operating System
Setting Up Virtual Machines 21
Figure 3.2
Summary
When running through the creation of a VM Guest, the following steps have to be accomplished:
Select if the VM Guest should run as full or paravirtualized guest.
1
If your computer supports hardware-assisted virtualization, you can create a virtual machine that runs in fully virtual mode. If you are installing an operating
system that is modied for virtualization, you can create a virtual machine that
runs in paravirtual mode. For more information about virtualization modes, see
Section 1.2, “Understanding Virtualization Modes” (page 5).
Each virtual machine must have a unique name. The name entered on this page
2
is used to create and name the virtual machine’s conguration le. The conguration le contains parameters that dene the virtual machine and is saved to the
/etc/xen/vm/ directory.
22 Virtualization with Xen
The user interface to the name of the virtual machine also offers the possibility
to add a description to the newly generated guest.
The Hardware page allows you to specify the amount of memory and number of
3
virtual processors for your virtual machine.
Initial Memory
The amount of memory initially allocated to the virtual machine (specied
in megabytes).
Maximum Memory
The largest amount of memory the virtual machine will ever need.
Virtual Processors
If desired, you can specify that the virtual machine has more virtual CPUs
than the number of physical CPUs. You can specify up to 32 virtual CPUs:
however, for best performance, the number of virtual processors should be
less than or equal to the number of physical processors.
Select the graphics mode to use:
4
No Graphics Support
The virtual machine operates like a server without a monitor. You can access
the operating system through operating system supported services, such as
SSH or VNC.
Paravirtualized Graphics Adapter
Requires that an appropriate graphics driver is installed in the operating
system.
A virtual machine must have at least one virtual disk. Virtual disks can be:
5
• File backed, which means that the virtual disk is a single image le on a
larger physical disk.
• A sparse image le, which means that the virtual disk is a single image le,
but the space is not preallocated.
• Congured from a block device, such as an entire disk, partition, or volume.
For more information about available physical storage, see Section 7.1,
“Mapping Physical Storage to Virtual Disks” (page 59).
Setting Up Virtual Machines 23
For best performance, create each virtual disk from an entire disk or a partition.
For the next best performance, create an image le but do not create it as a sparse
image le. A virtual disk based on a sparse image le delivers the most diskspace exibility but slows installation and disk access speeds.
By default, a single, le-backed virtual disk is created as a sparse image le in
/var/lib/xen/images/vm_name where vm_name is the name of the
virtual machine. You can change this conguration to meet your specic requirements.
If you want to install from DVD or CD-ROM, add the drive to the list of available
6
hard disks. To learn about device names of the available optical drives, run
hwinfo --cdrom and search for the line starting with Device File:. Add
this device le to the available hard disks of the VM Guest. The device type that
should be used for DVD or CD-ROMs is tap:cdrom.
Instead of the real DVD or CD-ROM drive, you can also add the ISO image of
an installation medium. For more details, see Section 8.1.1, “Virtual CD Readers
on Paravirtual Machines” (page 63).
Note, that each CD-Rom drive or ISO image can only be used by one VM Guest
at the same time. When installing many VM Guest systems, it may be better to
use a network installation source.
By default, a single virtual network card is created for the virtual machine. It has
7
a randomly generated MAC address that you can change to t your desired conguration. The virtual network card will be attached to a default bridge congured
in the host. You can also create additional virtual network cards in the Network
Adapters page of vm-install. For more details about virtual networking, see
Chapter 6, Virtual Networking (page 45).
NOTE: Using Arbitrary Bridge Names
If installing a fully virtualized guest and you are using a bridge name that
is different than the default names, explicitly specify the bridge by selecting the bridge name from the Source menu on the Virtual Network
Adapter page. Paravirtual guests by denition are aware they are running
on a virtualization platform and therefore, do not need to have the bridge
explicitly specied, thus leaving Source as Default will sufce.
24 Virtualization with Xen
The operating system can be installed from a CD/DVD device or an ISO image
8
le. In addition, if you are installing a SUSE Linux operating system, you can
install the operating system from a network installation source.
If you are installing a paravirtual machine's operating system from CD or DVD,
you probably should remove the virtual CD reader from the virtual machine after
completing the installation. Otherwise it would not be available for other installations.
If the installation program is capable of recognizing an installation prole, response le, or script, you can automate the installation settings by specifying the
location of the prole, response le, or script you want to use. For example,
SUSE Linux uses an AutoYaST prole, NetWare uses a NetWare Response File,
and Red Hat uses a Kickstart le to move through the installation screens with
no interaction.
You can also pass instructions to the kernel at install time by entering parameters
for the Additional Arguments eld. These arguments may either be kernel options,
or options for linuxrc. More information about linuxrc can be found in
the Deployment Guide.
If all the information on the Summary screen is correct, click OK to create the virtual
machine. A Virt Viewer screen appears and at this point you begin the installation of
your OS. From this point on, follow the regular installation instructions for installing
your OS.
3.3 Including Add-On Products in the Installation
In order to include an Add-On product in the installation process of a VM Guest, it is
necessary to provide the installation system with both, the standard installation images
and the image for the Add-On product.
First, add the system disk, the SUSE Linux Enterprise Desktop 11 SP1 installation image
and the physical CD-ROM or Add-On image as disks to the VM Guest. For example,
you may have:
Setting Up Virtual Machines 25
xvda
Main system disk.
xvdb
ISO image of the installation medium.
xvdc
ISO image of the Add-On product.
During the installation, add the Add-On product to the installation by entering the device
path. Commonly, this path looks like hd:///?device=/dev/xvd<letter>. In
the special example with “xvdc” as Add-On product, this would look like:
hd:///?device=/dev/xvdc
3.4 Using the Command Line to Create Virtual Machines
From the command line, you can enter vm-install to run a text version of the Create
Virtual Machine Wizard. The text version of the wizard is helpful in environments
without a graphical user interface. This command defaults to using a graphical user
interface if available and if no options were given on the command line.
For information on scripting a virtual machine installation, see the man pages of
vm-install and vm-install-jobs.
3.5 Deleting Virtual Machines
When you use Virtual Machine Manager or the xm command to delete a virtual machine,
it no longer appears as a virtual machine, but its initial startup le and virtual disks are
not automatically deleted.
To delete all components of a virtual machine congured with a le-backed virtual
disk, you must manually delete its virtual disk image le (/var/lib/xen/images/)
and its initial startup le (/etc/xen/vm).
26 Virtualization with Xen
3.6 Using an Existing SUSE Linux Enterprise Desktop Virtual Machine
In SUSE Linux Enterprise Desktop 10 SP1 and later, the device naming is different
than the device naming of SUSE Linux Enterprise Desktop 10. Therefore, a SUSE
Linux Enterprise Desktop 10 VM Guest will not be able to nd its root le system
when running on a SUSE Linux Enterprise Desktop 11 SP1 VM Host Server.
To be able to still boot the system, you must know which device is used for the root
partition of your virtual system. For example, hdaxx will be changed to xvdaxx
where xx is the partition number.
When booting the system, append an extra root option to the kernel command line, that
tells the system about its root le system. If your VM Guest used to live on /dev/
hda2, append the string root=/dev/xvda2 to the kernel command line. This option
should enable you to boot the system, although additional le systems still will not be
available to the system.
To make all the needed le systems available to the VM Guest, do the following:
In order to have a valid initial RAM disk that knows about the new location of the root
le system, run the command mkinitrd.
1
Start the VM Guest with the extra root= command line as explained above.
2
Log into the system as user root.
3
Edit the le /etc/fstab and correct all device entries.
4
Edit the virtual machine’s /boot/grub/menu.lst le. At the kernel line,
x the root= and the resume= parameters according the new naming schema.
Reboot the virtual machine.
5
Setting Up Virtual Machines 27
3.7 Troubleshooting
In some circumstances, problems may occur during the installation of the VM Guest.
This section describes some known problems and their solutions.
During boot, the system hangs
The software I/O translation buffer allocates a large chunk of low memory early
in the bootstrap process. If the requests for memory exceed the size of the buffer
it usually results in a hung boot process. To check if this is the case, switch to
console 10 and check the output there for a message similar to
kernel: PCI-DMA: Out of SW-IOMMU space for 32768 bytes at device
000:01:02.0
In this case you need to increase the size of the swiotlb. Enter “swiotlb=128”
on the Domain0 command line. Note that the number can be adjusted up or down
to nd the optimal size for the machine.
28 Virtualization with Xen
Updating SLE 10 Systems to SLE 11
The update of a Xen VM Host Server is done similarly to the update of a normal SUSE
Linux Enterprise system. Simply follow the update description of the new SUSE Linux
Enterprise system.
To update a SLE 10 SP1 or later virtual machine to SLE 11, complete the following
procedure.
Make sure the host computer is running the most recent SLE updates. The
1
host computer must be running software that is more recent than the software
planned for the virtual machine update.
Shut down the virtual machine you want to update.
2
Prepare the virtual machine’s operating system environment for the update
3
by completing any prerequisite tasks. It is recommended to make a copy of
the entire virtual disk.
4
View or print the virtual machine’s conguration found with xm list -l
<vm_name>.
Use the Virtual Machine Manager to update the virtual machine.
5
4
Choose the operating system that is currently used on the virtual machine.
6
Select the virtual machine from the list to update.
7
Updating SLE 10 Systems to SLE 11 29
Specify the SUSE Linux Enterprise installation source as the Installation
8
Source for the virtual machine.
Run through the virtual machine update the same way, as if it would be a
9
physical machine.
Click OK to create the virtual machine and start the installation program.
10
A new window displaying the installation program opens on the Domain0.
During the installation program, select Update from the Installation Mode
11
screen.
Continue the installation/update by following the instructions on the screen.
12
After the installation program is completed, the virtual machine should run
SLE 11 and be registered with Xend.
Log in to the SLE 11 virtual machine.
13
If you want the SLE 11 virtual machine to run in GUI mode, complete the
14
following from its command line:
14a
Enter init 3.
14b
Enter sax2 to congure the GUI environment.
14c
Enter init 5 to restart the GUI.
4.1 Boot Loader Conguration
After the upgrade of Domain0, Xen is no longer selected as the default boot option in
the grub boot menu. To make it default, start YaST and select System > Boot Loader.
Then select XEN and press Set as Default. Finish with OK.
30 Virtualization with Xen
Part II. Advanced Congurations
Managing a Virtualization Environment
Graphical utilities, text-based commands, and modied conguration les are methods
you can choose from to manage your virtualization environment.Virtual Machine
Manager is a graphical utility available in YaST that can be launched from the virtual
machine Domain0.
Figure 5.1
Desktop Showing Virtual Machine Manager and Virtual Machines
5
Managing a Virtualization Environment 33
From a command line interface on the virtual machine host, you can use the
vm-install and xm commands to create and manage virtual machines. You can also
edit conguration les to change the settings of the virtual machine host or a virtual
machine.
5.1 Virtual Machine Manager
The YaST Virtual Machine Manager provides a graphical user interface you can use
to create and manage virtual machines. This utility can be run either locally on the VM
Host Server or remote. The connection is then secured either with an SSL/TLS with
x509 certicate, or with a tunnel over SSH.
NOTE
Close Virtual Machine Manager if you are not actively using it and restart it
when needed. Closing Virtual Machine Manager does not affect the state of
virtual machines.
Figure 5.2
When starting the Virtual Machine Manager locally on the controlling Domain0, it is
directly connected to the Xen managing demon. All locally managed domains are displayed and can be modied.
34 Virtualization with Xen
Virtual Machine Manager Main Console
From remote, the Virtual Machine Manager can also be started as normal user without
administrative rights. To start it, run the command virt-manager. If the local ma-
chine does not manage virtual domains, the Virtual Machine Manager rst has to connect
the managing domain of a Xen VM Host Server. To do this, use the following procedure:
Make sure that Domain0 on the VM Host Server accepts incoming SSH connec-
1
tions. If in doubt, run YaST > Security and Users > Firewall and make sure that
Secure Shell Server is added to the Allowed Services.
Run File > Open Connection.
2
Select Xen at the Hypervisor pull-down menu.
3
Select Remote Tunnel over SSH at the Connection pull down menu.
4
Enter the hostname of the controlling Domain0 into the Hostname text eld.
5
Press Connect to initiate the connection.
6
7
On request, enter the password of the root user of the controlling Domain0.
This is not necessary when using SSH keys and conguring the local user as
authorized for root access on the controlling Domain0.
When connected to a controlling Domain0, the Virtual Machine Manager offers several
conguration possibilities.
•
Selec a virtual machine and click Open to display the virtual machine window
showing the virtual machine’s current state.
•
Click Run on the virtual machine window to boot the virtual machine and display
the user interface or text console running on the virtual machine.
•
Select a virtual machine and click Details to let you view performance and congure
hardware details associated with the virtual machine.
•
Click New in Virtual Machine Manager to launch the Create Virtual Machine
Wizard, which walks you through the steps required to set up a virtual machine.
See also Section 3.1, “Creating a Virtual Machine” (page 20). This option is only
available when the Xen host is selected.
Managing a Virtualization Environment 35
5.2 Controlling the Host by Modifying Xend Settings
The Xend is a key component of Xen virtualization. It performs management functions
and stores settings that relate to the host environment and each virtual machine. You
can customize Xend to meet your specic conguration requirements.
Important services that must be congured in this le are:
• Settings for live migrations, dene migration hosts
•
Path to Xend lock les. These can be used to prevent Xen from starting a guest
a second time on a migration host.
•
To specify Xend operating parameters, edit the /etc/xen/xend-config.sxp
le. The settings take effect the next time Xend starts.
# -*- sh -*-
#
# Xend configuration file.
#
# This example configuration is appropriate for an installation that
# utilizes a bridged network configuration. Access to Xend via http
# is disabled.
# Commented out entries show the default for that entry, unless otherwise
# specified.
#(logfile /var/log/xen/xend.log)
#(loglevel DEBUG)
# The Xen-API server configuration.
#
# This value configures the ports, interfaces, and access controls for
the
# Xen-API server. Each entry in the list starts with either unix, or a
port
•
To start the Xend daemon, enter rcxend start.
36 Virtualization with Xen
•
To stop the Xend daemon, enter rcxend stop.
•
To restart the Xend daemon, enter rcxend restart.
•
To check the status of the Xend daemon, enter rcxend status.
The parameters in the xend-config.sxp le can be customized to meet your requirements for virtualization. For a full list of all available options, read the manual
page of xend-config.sxp.
5.3 Conguring a Virtual Machine by
Modifying its Xend Settings
The machine settings of each virtual guest are stored in an internal database managed
by xend. You can change a virtual machine’s settings by modifying the settings stored
in Xend. This process requires you to export a virtual machine’s settings from the Xend
database to a text le, edit the settings in the le to meet your conguration requirements,
import the le back into Xend, and restart the virtual machine.
Some commonly used congurations can be done online with the xm command. These
include the attachment or detachment of virtual block, network or PCI devices. For
more details, see the manual page of xm.
NOTE
It is no longer recommended that you edit the initial start-up les stored in
/etc/xen/vm, because they are used only during the creation of a new virtual
machine.
To modify a virtual machine’s settings that is administrated with the virtual machine
manager, rst shut it down and then:
At Domain0, enter
1
xm list -l vm_name > filename
Managing a Virtualization Environment 37
where vm_name is the name of the virtual machine you want to modify and
filename is whatever you want to name the text le.
Use a text editor to make and save any desired changes.
2
(domain
(domid 1)
(bootloader /usr/bin/pygrub)
(on_crash destroy)
(uuid aa6969f3-8012-24f0-1e3a-35f150001950)
(bootloader_args -q)
(vcpus 2)
(name sles11)
(cpus (() ()))
(on_reboot restart)
(on_poweroff destroy)
(maxmem 512)
(memory 512)
(shadow_memory 0)
(features )
(on_xend_start ignore)
(on_xend_stop ignore)
(start_time 1240210933.16)
(cpu_time 35.841108115)
(online_vcpus 2)
....
3
Delete the existing conguration from Xend with the command xm del
vm_name
4
Enter xm new -F filename to import the virtual machine’s new settings
into Xend.
5
Enter xm start vm_name to start the virtual machine with its new settings.
You should repeat the entire process of exporting the le each time you want to
make changes to a virtual machine’s settings.
5.4 The xm Command
The xm command provides a command line interface for managing virtual machines.
It can be used to create, pause, and shut down virtual machines. It can also be used to
list the current domains, enable or pin virtual CPUs, and attach or detach block devices.
38 Virtualization with Xen
For a complete list of the available xm commands, run xm help. For each command,
there is a more detailed help available that is obtained with the extra parameter --help.
More information about the respective subcommands is available in the manual page
of xm.
For example, the xm list --help displays all options that are available to the list
command. As an example, the xm list command displays the status of all virtual
machines.
# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 457 2 r----- 2712.9
OES 7 512 1 -b---- 16.3
SLES10 512 1 12.9
The State information tells if a machine is running, and in which state it is. The most
common ags are r (running) and b (blocked) where blocked means it is either waiting
for IO, or just sleeping because there is nothing to do. For more details about the state
ags, see man 1 xm. The syntax of the xm command usually follows the format:
xm <subcommand> [domain-id] [OPTIONS]
where subcommand is the xm command to run, domain-id is the ID number assigned
to a domain or the name of the virtual machine, and OPTIONS indicates subcommand-
specic options.
Other useful xm commands include:
•
xm start starts a virtual machine
•
xm reboot reboots a virtual machine
•
xm destroy immediately terminates a virtual machine
•
xm block-list displays all virtual block devices attached to a virtual machine
•
All xm operations require that the Xen control daemon, Xend, be running. For this
reason, you should make sure Xend starts whenever the host boots.
•
Most xm commands require root privileges to allow interaction with the Xen hypervisor. Entering the xm command when you are not logged in as root returns an error.
Managing a Virtualization Environment 39
•
Some xm commands return no textual information even though the action is completed. In some instances, for example, when shutting down a virtual machine, the
action can take several seconds to complete. To verify that the action has completed,
you might need to view its status another way, such as, using the xm list command.
5.5 Automatic Starting of Domains
If you need automatic starting of domains at boot time, or after a crash, the Xend must
be congured to execute the desired behavior. There are ve different situations that
need to be handled.
After boot of the Hypervisor
Set the Xend variable on_xend_start to the desired value. For more details,
see the section called “on_xend_start” (page 129). Example:
(on_xend_start start)
When shutting down Xend
Xend can tell the VM Guest system to shut down. However, it does not to check
if the guest was stopped when doing a system shutdown of Domain0. Thus, it is
not recommended to rely on this feature. Example:
(on_xend_stop shutdown)
When rebooting the VM Guest
Xend has control about what to do when a VM Guest does a reboot. By default, it
is restart the guest:
(on_reboot restart)
During poweroff of a VM Guest
When a guest is shut off, the Xend by default destroys the guest without shutting
it down.
(on_poweroff destroy)
After a crash of the VM Guest
After a VM Guest crashes, the Xend can restart the guest. This is also the default:
(on_crash restart)
40 Virtualization with Xen
5.6 Migrating Xen VM Guest Systems
With Xen it is possible to migrate a VM Guest system from one VM Host Server to
another with almost no service interruption. This could be used for example to move a
busy VM Guest to a VM Host Server that has stronger hardware or is not yet loaded.
Or, if a service of a VM Host Server is required, all VM Guest systems running on this
machine can be migrated to other machines in order to avoid interruption of service.
These are only two examples, many more reasons may apply to your personal situation.
Before starting, some preliminary considerations regarding the VM Host Server should
be taken:
• All VM Host Server systems should use a similar CPU. The frequency is not so
important, but they should be using the same CPU family. To get more information
about the used CPU, see cat /proc/cpuinfo.
• All resources that are used by a specic guest system must be available on all involved VM Host Server systems. This means, the network bridges must be in the
same subnet, and all used block devices must exist on both VM Host Server systems.
•
Using special features like PCI Pass-Through may be problematic. Do not
implement these when deploying for an environment that should migrate VM Guest
systems between different VM Host Server systems.
• For fast migrations, a fast network is mandatory. If possible, use GB Ethernet and
fast Switches. Deploying VLAN might also help avoiding collisions.
5.6.1 Conguring Xend for Migrations
To prepare a VM Host Server system for migrating, edit the conguration le /etc/
xen/xend-config.sxp. Search for the following lines:
#(xend-relocation-server no)
#(xend-relocation-port 8002)
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')
Change the lines to match the following strings:
Managing a Virtualization Environment 41
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$ \
^<relocation_host>')
These changes must be done on all VM Host Server systems that should participate in
migrating guests.
5.6.2 Preparing Block Devices for Migrations
The block devices needed by the VM Guest system must be available on all involved
VM Host Server systems. This is done by implementing some kind of shared storage
that serves as container for the root le system of the migrated VM Guest system.
Common possibilities include:
•
iSCSI can be set up to give access to the same block devices from different systems
at the same time. For more information about iSCSI, see http://www.novell
.com/documentation/sles11/stor_admin/data/cha_inst_system
_iscsi.html.
•
NFS is a widely used root le system that can easily be accessed from different
locations.
•
DRBD can be used, if only two VM Host Server systems are involved. This gives
some extra data security, because the used data is mirrored over the network. For
more information, see http://www.novell.com/documentation/
sles11/book_sleha/data/cha_ha_drbd.html.
•
SCSI can also be used, if the available hardware permits shared access to the same
disks.
•
NPIV is a special mode to use bre channel disks. However, in this case all migration hosts must be attached to the same bre channel switch. For more information
about NPIV, see Section 7.1, “Mapping Physical Storage to Virtual Disks”
(page 59). Commonly, this works if the bre channel environment supports 4 GBit
or faster connections.
42 Virtualization with Xen
5.6.3 Migrating VM Guest Systems
The actual migration of the VM Guest system is done with the command:
xm migrate --live <domain_name> <host>
The option --live must be set to migrate a system that is currently running.
The speed of the migration depends on how fast the memory print can be saved to disk,
sent to the new VM Host Server and loaded there. This means, that small VM Guest
systems can be migrated faster than big systems with a lot of memory.
Managing a Virtualization Environment 43
Virtual Networking
All VM Guest need some means to communicate either with other VM Guest systems
or with a local network. The network interface to the VM Guest system is made of a
split device driver, which means, that any virtual Ethernet device has a corresponding
network interface in Domain0. This interface is set up to access a virtual network that
is run in Domain0. The bridged virtual network is fully integrated into the system conguration of SUSE Linux Enterprise Desktop and can be congured with YaST.
When installing a Xen VM Host Server, a bridged network conguration will be proposed during normal network conguration. The user can choose to change the conguration during the installation and customize it to the local needs.
If desired, Xen VM Host Server can be installed after performing a default Physical
Server installation using the Install Hypervisor and Tools module in YaST.
This module will prepare the system for hosting virtual machines, including invocation
of the default bridge networking proposal.
In case the necessary packages for a Xen VM Host Server are installed manually with
rpm or zypper, the remaining system conguration has to be done by the administrator
manually or with the help of YaST.
The network scripts that are provided by Xen are not used by default in SUSE Linux
Enterprise Desktop. They are only delivered for reference but disabled. The network
conguration that is used in SUSE Linux Enterprise Desktop is done by means of the
YaST system conguration similar to the conguration of network interfaces in SUSE
Linux Enterprise Desktop.
6
Virtual Networking 45
6.1 Virtual Bridges
When using SUSE Linux Enterprise Desktop the system congures one bridge for each
physical network device by default. For each virtual bridge, a physical Ethernet device
is enslaved, and the IP address assigned to the bridge.
To add a new bridge, for example, after installing an additional Ethernet device, or to
create a bridge that is not connected to a real network, proceed as follows:
Start yast2 > Network Devices > Network Settings.
1
Click on the tab Overview and press Add.
2
Select Device Type Bridge. The parameter Conguration Name will be set to the
3
next free number. Click Next.
Either use Dynamic Address (DHCP) as selected by default, or assign a static IP
4
address to the bridge. Using Dynamic Address is only useful, when also assigning
a device to the bridge that is connected to some DHCP server.
If you intend to create a virtual bridge that has no connection to a real Ethernet
device, use Statically assigned IP Address. In this case, it is a good idea to use
addresses from the private IP address ranges, for example, 192.168.x.x or
10.x.x.x.
To create a bridge that should only serve as a connection between the different
guests without connection to the host system, set the IP address to 0.0.0.0
and the netmask to 255.255.255.255. The network scripts handle this special
address as an unset IP address.
After the bridge is created, it may be used by any of the Xen VM Guest systems. A
purely virtual bridge without connection to a real network device is good to provide
fast network connections between different VM Guest systems. If you provide a DHCP
server on Domain0 that also denes routing information to the respective guest for the
bridge, the network setup of the respective VM Guest is simplied.
46 Virtualization with Xen
6.2 Network Devices for Guest Systems
The Xen hypervisor is able to provide different types of network interfaces to the VM
Guest systems. The preferred network device should be a paravirtualized network interface. This yields the highest transfer rates with the lowest requirements to the system.
Up to eight network interfaces may be provided for each VM Guest.
Systems that are not aware of paravirtualized hardware, may not have this option. To
connect systems to a network that can only run fully virtualized, several emulated network interfaces are available. The following emulations are at your disposal:
• Realtek 8139 (PCI). This is the default emulated network card.
• AMD PCnet32 (PCI)
• NE2000 (PCI)
• NE2000 (ISA)
• Intel e100 (PCI)
• Intel e1000 (PCI)
All the network interfaces are just software interfaces. Because every network interface
must have a unique MAC address, an address range has been assigned to Xensource
that can be used by these interfaces.
TIP: Virtual Network Interfaces and MAC Addresses
The default conguration of MAC addresses in virtualized environments just
creates a random MAC address that looks like 00:16:3E:xx:xx:xx. Normally, the
amount of available MAC addresses should be big enough to get only unique
addresses. However, if you have a very big installation, or if you want to make
sure that no problems arise from random MAC address assignment, you can
also manually assign these addresses.
For debugging or system management purposes, it may be useful to know which virtual
interface in Domain0 is connected to which Ethernet device in a running guest. This
Virtual Networking 47
information may be read from the device naming in Domain0. All virtual devices follow
the rule vif<domain number>.<interface_number>.
For example, if you want to know the device name for the third interface (eth2) of the
VM Guest with id 5, the device in Domain0 would be vif5.2. To obtain a list of all
available interfaces, run the command ip a.
The device naming does not contain any information to which bridge this interface is
connected. However, this information is available in Domain0. To get an overview
about which interface is connected to which bridge, run the command brctl show.
The output may look like the following:
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.001cc0309083 no eth0
br1 8000.000476f060cc no eth1
br2 8000.000000000000 no
vif2.1
vif2.0
In this example, there are three congured bridges: br0, br1 and br2. Currently, br0 and
br1 each have a real Ethernet device added: eth0 and eth1, respectively. There is one
VM Guest running with the id 2 that has two Ethernet devices available. eth0 on the
VM Guest is bridged with eth1 on the VM Host Server and eth1 on the VM Guest is
connected to eth0 on the VM Host Server. At this time, the third bridge with name br2
is not connected to any VM Guest nor real Ethernet device.
6.3 Host Based Routing in Xen
Xen can be set up to use host based routing in the controlling Domain0. Unfortunately,
this is not yet well supported from YaST and requires quite an amount of manual editing
of conguration les. Thus, this is a task, that requires an advanced administrator.
The following conguration will only work when using xed IP addresses. Using DHCP
is not realizable with this procedure, because the IP address must be known to both,
the VM Guest and the VM Host Server system.
The easiest way to create a routed guest is to change the networking from a bridged to
a routed network. As a requirement to the following procedures, a VM Guest with a
bridged network setup must be installed. For example, the VM Host Server is named
48 Virtualization with Xen
earth with the IP 192.168.1.20, and the VM Guest has the name alice with the IP
192.168.1.21.
Procedure 6.1
1
Make sure that alice is shut down. Either use virt-manager or the respective
Conguring a routed IPv4 VM Guest
xm commands to shutdown and check.
Prepare the network conguration on the VM Host Server earth:
2
Create a hotplug interface that will be used to route the trafc. To accomplish
2a
this, create a le named /etc/sysconfig/network/ifcfg-alice
.0 with the following content:
NAME="Xen guest alice"
BOOTPROTO="static"
STARTMODE="hotplug"
2b
Edit the le /etc/sysconfig/SuSEfirewall2 and add the following
congurations:
• Add alice.0 to the devices in FW_DEV_EXT:
FW_DEV_EXT="br0 alice.0"
• Switch on the routing in the rewall:
FW_ROUTE="yes"
• Tell the rewall, which address should be forwarded:
FW_FORWARD="192.168.1.21/32,0/0"
• Finally, restart the rewall with the command:
rcSuSEfirewall2 restart
Add a static route to the interface of alice. To accomplish this, add the fol-
2c
lowing line to the end of /etc/sysconfig/network/routes:
192.168.1.21 - - alice.0
Virtual Networking 49
To make sure that the switches and routers that the VM Host Server is con-
2d
nected to know about the routed interface, activate proxy_arp on earth.
Add the following lines to /etc/sysctl.conf:
net.ipv4.conf.default.proxy_arp = 1
net.ipv4.conf.all.proxy_arp = 1
Activate all changes with the commands:
2e
/etc/init.d/boot.sysctl start
rcnetwork restart
Proceed with conguring the Xen conguration of the VM Guest.
3
Change the vif interface conguration for alice as described in Section 5.3,
3a
“Conguring a Virtual Machine by Modifying its Xend Settings” (page 37).
Remove the entry:
3b
(bridge br0)
Add the following line to the conguration:
3c
(vifname alice.0)
Change the script that is used to set up the interface to the following:
3d
(script /etc/xen/scripts/vif-route-ifup)
Activate the new conguration and start the VM Guest.
3e
The remaining conguration tasks must be accomplished from inside the VM
4
Guest.
4a
Open a console to the VM Guest either with virt-manager or with xm
console and log on.
Check that the guest IP is set to 192.168.1.21.
4b
Add a host route and the default gateway to the VM Host Server. Do this by
4c
adding the following lines to /etc/sysconfig/network/routes:
50 Virtualization with Xen
192.168.1.20 - - eth0
default 192.168.1.20 - -
Finally, test the network connection from the VM Guest to the world outside as
5
well as from the network to your VM Guest.
6.4 Creating a Masqueraded Network
Setup
Creating a masqueraded network setup is quite similar to the routed setup. However,
there is no proxy_arp needed, and some rewall rules are different. To create a masqueraded network to a guest dolly with the IP address 192.168.100.1 where the host
has its external interface on br0, proceed as follows. For easier conguration, only an
already installed guest is modied to use a masqueraded network:
Procedure 6.2
1
Shutdown the VM Guest system with virt-manager or xm shutdown.
Prepare the network conguration on the VM Host Server:
2
Create a hotplug interface that will be used to route the trafc. To accomplish
2a
this, create a le named /etc/sysconfig/network/ifcfg-dolly
.0 with the following content:
NAME="Xen guest dolly"
BOOTPROTO="static"
STARTMODE="hotplug"
2b
Edit the le /etc/sysconfig/SuSEfirewall2 and add the following
congurations:
Conguring a masqueraded IPv4 VM Guest
• Add dolly.0 to the devices in FW_DEV_DMZ:
FW_DEV_DMZ="dolly.0"
• Switch on the routing in the rewall:
Virtual Networking 51
FW_ROUTE="yes"
• Switch on masquerading in the rewall:
FW_MASQUERADE="yes"
• Tell the rewall, which network should be masqueraded:
FW_MASQ_NETS="192.168.100.1/32"
• Remove the networks from the masquerading exceptions:
FW_NOMASQ_NETS=""
• Finally, restart the rewall with the command:
rcSuSEfirewall2 restart
Add a static route to the interface of dolly. To accomplish this, add the fol-
2c
lowing line to the end of /etc/sysconfig/network/routes:
192.168.100.1 - - dolly.0
Activate all changes with the command:
2d
rcnetwork restart
Proceed with conguring the Xen conguration of the VM Guest.
3
Change the vif interface conguration for dolly as described in Section 5.3,
3a
“Conguring a Virtual Machine by Modifying its Xend Settings” (page 37).
Remove the entry:
3b
(bridge br0)
Add the following line to the conguration:
3c
(vifname dolly.0)
Change the script that is used to set up the interface to the following:
3d
(script /etc/xen/scripts/vif-route-ifup)
52 Virtualization with Xen
Activate the new conguration and start the VM Guest.
3e
The remaining conguration tasks has to be accomplished from inside the VM
4
Guest.
4a
Open a console to the VM Guest either with virt-manager or with xm
console and log on.
Check whether the guest IP is set to 192.168.100.1.
4b
Add a host route and the default gateway to the VM Host Server. Do this by
4c
adding the following lines to /etc/sysconfig/network/routes:
192.168.1.20 - - eth0
default 192.168.1.20 - -
Finally, test the network connection from the VM Guest to the outside world.
5
6.5 Special Congurations
There are many network conguration possibilities available to Xen. The following
congurations are not activated by default:
6.5.1 Bandwidth Throtteling in Virtual
Networks
With Xen, you may limit the network transfer rate a virtual guest may use to access a
bridge. This conguration option is not available from a graphical user interface at this
time. To congure this, you will have to modify the VM Guest conguration as described
in Section 5.3, “Conguring a Virtual Machine by Modifying its Xend Settings”
(page 37).
In the conguration le, rst search for the device that is connected to the virtual bridge.
The conguration looks like the following:
Virtual Networking 53
...
(device
(vif
(bridge br0)
(mac 00:16:3e:4f:94:a9)
(backend 0)
(uuid bf840a86-6aa9-62df-f8df-a7cf8c192c24)
(script /etc/xen/scripts/vif-bridge)
)
)
...
To add a maximum transfer rate, add a parameter rate to this conguration as in:
...
(device
(vif
(bridge br0)
(mac 00:16:3e:4f:94:a9)
(rate 100Mb/s)
(backend 0)
(uuid bf840a86-6aa9-62df-f8df-a7cf8c192c24)
(script /etc/xen/scripts/vif-bridge)
)
)
...
Note, that the rate is either Mb/s (megabit per second) or MB/s (megabyte per second).
In the above example, the maximum transfer rate of the virtual interface is 100 megabit.
By default, there is no limitation to the bandwidth of a guest to the virtual bridge.
It is even possible to ne tune the behavior by specifying the time window that is used
to dene the granularity of the credit replenishment:
...
(device
(vif
(bridge br0)
(mac 00:16:3e:4f:94:a9)
(rate 100Mb/s@20ms)
(backend 0)
(uuid bf840a86-6aa9-62df-f8df-a7cf8c192c24)
(script /etc/xen/scripts/vif-bridge)
)
)
...
54 Virtualization with Xen
6.5.2 Monitoring the Network Trafc
To monitor the trafc on a specic interface, the little application iftop is a nice
program that displays the current network trafc in a terminal.
When running a Xen VM Host Server, you have to dene the interface that is monitored.
The interface that Domain0 uses to get access to the physical network is the bridge de-
vice, for example br0. This, however, may vary on your system. To monitor all trafc
to the physical interface, run a terminal as root and use the command:
iftop -i br0
To monitor the network trafc of a special network interface of a specic VM Guest,
just supply the correct virtual interface. For example, to monitor the rst ethernet device
of the domain with id 5, use the command:
іftop -i vif5.0
To quit iftop, press the key Q. More options and possibilities are available in the
manual page man 8 iftop.
6.5.3 Setup Bonding Devices
For some systems, it is desired to implement network connections that comply to more
than the standard data security or availability requirements of a typical Ethernet device.
In these cases, several Ethernet devices can be aggregated to a single bonding device.
The conguration of the bonding device is done by means of bonding module options.
The behavior is mainly affected by the mode of the bonding device. By default, this is
mode=active-backup which means that a different slave device will become active
if the active slave fails.
TIP: Bonding and Xen
Using bonding devices is only interesting for machines where you have multiple
real network cards available. In most congurations, this means that you should
use the bonding conguration only in Domain0. Only if you have multiple
network cards assigned to a VM Guest system it may also be useful to set up
the bond in a VM Guest.
Virtual Networking 55
To congure a bonding device, use the following procedure:
Run YaST > Network Devices > Network Settings.
1
Use Add and change the Device Type to Bond. Proceed with Next.
2
Select how to assign the IP address to the bonding device. Three methods are at
3
your disposal:
• No IP Address
• Dynamic Address (with DHCP or Zeroconf)
• Statically assigned IP Address
Use the method that is appropriate for your environment.
Select the Ethernet devices that should be included into the bond by activating
4
the check box in front of the respective Bond Slave.
Edit the Bond Driver Options. The modes that are available for conguration are
5
the following:
• balance-rr
• active-backup
56 Virtualization with Xen
• balance-xor
• broadcast
• 802.3ad
• balance-tlb
• balance-alb
6
Make sure that the parameter miimon=100 is added to the Bond Driver Options.
Without this parameter, the data integrity is not checked regularly.
Click Next and leave YaST with OK to create the device.
7
All modes, and lots of more options are explained in detail in the Linux Ethernet
Bonding Driver HOWTO found at /usr/src/linux/Documentation/
networking/bonding.txt after installing the package kernel-source.
6.5.4 Using VLAN Interfaces
Sometimes, it is necessary to create a private connection either between two Xen hosts
or between a number of VM Guest systems. For example, if you want to migrate VM
Guest to hosts in a different network segment, or if you want to create a private bridge
that only VM Guest systems may connect to, even when running on different VM Host
Server systems. An easy way to build such connections is to set up VLAN networks.
VLAN interfaces are commonly set up on the VM Host Server and either just interconnect the different VM Host Server systems, or they may be set up as physical interface
to an otherwise virtual only bridge. It is even possible to create a bridge with a VLAN
as physical interface that has no IP address in the VM Host Server. That way, the guest
systems have no possibility to access Domain0 over this network.
Run the YaST module Network Devices > Network Settings. Follow this procedure to
actually set up the VLAN device:
Procedure 6.3
Press Add to create a new network interface.
1
Setting up VLAN Interfaces with YaST
Virtual Networking 57
In the Hardware Dialog, select Device Type VLAN.
2
Change the value of Conguration Name to the ID of your VLAN. Note that
3
VLAN ID 1 is commonly used for managing purposes.
Press Next.
4
Select the interface that the VLAN device should connect to below Real Interface
5
for VLAN.
If the desired interface does not appear in the list, rst set up the this interface
without IP Address.
Select the desired method for assigning an IP address to the VLAN device.
6
Press Next to nish the conguration.
7
It is also possible to use the VLAN interface as physical interface of a bridge. This
makes it possible to connect several VM Host Server only networks and allows to live
migrate VM Guest systems that are connected to such a network.
YaST does not always allow to set no IP address. However, this may be a desired feature
especially if VM Host Server only networks should be connected. In this case, use the
special address 0.0.0.0 with netmask 255.255.255.255. The system scripts
handle this address as no IP address set.
58 Virtualization with Xen
Block Devices in Xen
7.1 Mapping Physical Storage to
Virtual Disks
Virtual disks can be based on the following types of physical devices and les. Each
type includes an example statement.
• A physical disk device, such as a DVD, that is accessible as a device to the host.
phy:/dev/cdrom
• A le that contains a disk image accessible from the le system of the host. Disk
images can be encoded as raw, QEMU, or VMware.
file:/mnt/disks/sles10sp1.iso
tap:aio:/mnt/disks/sles10sp1.iso species a raw disk that might be
taken from a different virtualization platform.
tap:qcow:/mnt/disks/sles10sp1.iso.qcow
tap:vmdk:/mnt/disks/sles10sp1.iso.vmdk
7
• A remote storage device specied using the Internet SCSI (iSCSI) protocol.
iscsi:iqn.2001-04.com.acme@0ac47ee2-216e-452a-a341-a12624cd0225
Block Devices in Xen 59
• A remote storage device specied using a Fibre Channel (NPIV) protocol.
npiv:210400e08b80c40f
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 5.3,
“Conguring a Virtual Machine by Modifying its Xend Settings” (page 37), to change
the respective device entry to the desired setting.
Example 7.1
(vbd
(dev xvda:disk)
(uname file:/var/lib/xen/images/sles11/disk0)
(mode w)
(type disk)
(backend 0)
)
Table 7.1
phy:
Example: Virtual Machine Output from Xend
Available uname Settings
Block devices, such as a physical disk,
in domain 0
le:
Raw disk images accessed by using
loopback
Raw disk images accessed by using NBDnbd:
tap:aio:
Raw disk images accessed by using
blktap. Similar to loopback but with-
out using loop devices.
ExampleDescriptionProtocol
phy:/dev/sdc
file:/path/file
ndb: ip_port
tap:aio:/path/file
CD reader block devicestap:cdrom
tap:vmdk:
VMware disk images accessed by using
blktap
60 Virtualization with Xen
tap:cdrom:/dev/sr0
tap:vmdk:/path/file
ExampleDescriptionProtocol
tap:qcow:
iscsi:
npiv:
QEMU disk images accessed by using
blktap
iSCSI targets using connections initiated
from domain 0
Fibre Channel connections initiated from
domain 0
tap:qcow:/path/file
iscsi:IQN,LUN
npiv:NPIV,LUN
7.2 File-Backed Virtual Disks and
Loopback Devices
When a virtual machine is running, each of its le-backed virtual disks consumes a
loopback device on the host. By default, the host allows up to 64 loopback devices to
be consumed.
To simultaneously run more le-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 le.
options loop max_loop=x
where x is the maximum number of loopback devices to create.
Changes take effect after the module is reloaded.
TIP
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.
Block Devices in Xen 61
7.3 Resizing Block Devices
While it is always possible to add new block devices to a VM Guest system, it is
sometimes more desirable to increase the size of an existing block device. In case such
a system modication is already planned during deployment of the VM Guest, some
basic considerations should be done:
• Use a block device that may be increased in size. LVM devices and le system
images are commonly used.
• Do not partition the device inside the VM Guest, but use the main device directly
to apply the le system. For example, use /dev/xvdb directly instead of adding
partitions to /dev/xvdb.
• Make sure that the le system to be used can be resized. Sometimes, for example
with ext3, some features must be switched off to be able to resize the le system.
A le system that can be resized online and mounted is XFS. Use the command
xfs_growfs to resize that le system after the underlying block device has been
increased in size. For more information about XFS, see man 8 xfs_growfs.
When resizing a LVM device that is assigned to a VM Guest, the new size is automatically known to the VM Guest. No further action is needed to inform the VM Guest
about the new size of the block device.
When using le system images, a loop device is used to attach the image le to the
guest. For more information about resizing that image and refreshing the size information
for the VM Guest, see Section 9.2, “Sparse Image Files and Disk Space” (page 82).
62 Virtualization with Xen
Virtualization: Conguration
Options and Settings
The documentation in this section, describes advanced management tasks and conguration 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.
8.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.
8.1.1 Virtual CD Readers on Paravirtual
Machines
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.
8
After you have nished accessing a CD on a paravirtual machine, it is recommended
that you remove the virtual CD reader from the virtual machine.
Virtualization: Conguration Options and Settings 63
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.
8.1.2 Virtual CD Readers on Fully Virtual
Machines
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 le system. Virtual CD readers
cannot be used to write data to a CD. They are congured as read-only devices.
8.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 le.
Make sure that the virtual machine is running and the operating system has
1
nished booting.
Insert the desired CD into the physical CD reader or copy the desired ISO
2
image to a location available to Domain0.
3
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.
4
When using a real CD reader, use the following command to assign the CD
5
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
64 Virtualization with Xen
When assigning an image le, use the following command:
6
xm block-attach alice file:/path/to/file.iso xvdb r
7
The image les 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.
8
A new block device, such as /dev/xvdb, is added to the virtual machine.
If the virtual machine is running Linux, complete the following:
9
9a
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.
9b
For example,
mount -o ro /dev/xvdb /mnt
mounts the CD to a mount point named /mnt.
The CD or ISO image le should be available to the virtual machine at the
specied mount point.
If the virtual machine is running Windows, reboot the virtual machine.
10
Verify that the virtual CD reader appears in its My Computer section
8.1.4 Removing Virtual CD Readers
Make sure that the virtual machine is running and the operating system has n-
1
ished booting.
Virtualization: Conguration Options and Settings 65
If the virtual CD reader is mounted, unmount it from within the virtual machine.
2
TIP
Enter cat /proc/partitions in the virtual machine's terminal to
view its block devices.
Run Virtual Machine Manager.
3
Select the virtual machine, then click Details.
4
Click Hardware > Disk.
5
Select the virtual CD-ROM device to remove.
6
Click Remove to remove the virtual CD-ROM device.
7
Press the hardware eject button to eject the CD.
8
8.2 Remote Access Methods
Some congurations, such as those that include rack-mounted servers, require a computer to run without a video monitor, keyboard, or mouse. This type of conguration
is often referred to as headless and requires the use of remote administration technologies.
Typical conguration scenarios and technologies include:
Graphical Desktop with X Window Server
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.
Text and Graphical Applications
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
66 Virtualization with Xen
can then use Virtual Machine Manager and the xm command to manage virtual
machines and the vm-install command to create them.
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 the xm command
to manage virtual machines and the vm-install command to create new virtual
machines.
8.3 VNC Viewer
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 rewall 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” (page 36).
Virtualization: Conguration Options and Settings 67
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.
8.3.1 Assigning VNC Viewer Port Numbers
to Virtual Machines
Although the default behavior of VNC viewer is to assign the rst available port number,
you might want to assign a specic VNC viewer port number to a specic virtual machine.
To assign a specic 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” (page 34).
68 Virtualization with Xen
TIP
Assign higher port numbers to avoid conict with port numbers assigned by
the VNC viewer, which uses the lowest available port number.
8.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 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 conguration
information to the following. For instructions, see Section 5.3, “Conguring a Virtual
Machine by Modifying its Xend Settings” (page 37).
•
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.
8.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
in the virtual machine's settings, the host uses the keymap entry specied in host's
Xend le ( xend-config.sxp). If there is no keymap entry in either the host's
Xend le 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 specied in the host's Xend le
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
Virtualization: Conguration Options and Settings 69
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 specic machines.
• To specify a global keymap entry for virtual machines on the host, edit the host's
xend-config.sxp le.
• To specify a keymap entry for a specic virtual machine, edit the virtual machine's
settings by following instructions in Section 5.3, “Conguring a Virtual Machine
by Modifying its Xend Settings” (page 37).
In the device > vfb section, add the desired keymap entry to the le /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 specied 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 specied are not automatically
updated. These virtual machines start with the keyboard specied 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
70 Virtualization with Xen
Keymap SettingLanguage
daDanish
deGerman
de-chSwiss-German
en-gbEnglish (UK)
Keymap SettingLanguage
en-usEnglish (US)
esSpanish
Finnish
frFrench
fr-beFrench-Belgium
fr-caFrench-Canada
fr-chFrench-Switzerland
huHungarian
isIcelandic
itItalian
jaJapanese
nlDutch
nl-beDutch-Belgium
noNorwegian
plPolish
ptPortuguese
pt-brPortuguese-Brazil
ruRussian
svSwedish
Virtualization: Conguration Options and Settings 71
8.5 Using PVUSB
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.
NOTE: 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 aws 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
Plug the USB keyboard device into the VM Host Server.
1
2
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:
3
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
4
command:
modprobe xen-hcd
72 Virtualization with Xen
Adding an USB keyboard to a VM Guest
5
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
6
the command xm usb-list alice
On the VM Host Server system, check, which devices may be assigned to a guest
7
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
8
The device that should be assigned to alice has the number 4-2. To assign this
device to the rst 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
Virtualization: Conguration Options and Settings 73
8.6 Using Lock Files
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 le before a guest is started. In order to
use this mechanism, a distributed le system like NFS or a cluster le system is needed.
For example, a distributed le system mounted to /srv/xen may be used.
The Xen domain lock functionality is congured in the Xend conguration le /etc/
xen/xend-config.sxp. At the end of this le, 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.
8.7 HVM Features
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.
8.7.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, the managing
program virt-manager provides a possibility to achieve this.
74 Virtualization with Xen
Procedure 8.2
1
Start virt-manager and connect to the needed Xen host.
Right-click the stopped machine, and select Open.
2
Choose Details to get an overview over the VM Guest.
3
Select Boot Options.
4
A drop down box appears, that gives you a selection of bootable devices. Select
5
the correct device and press Apply
Then press Run to start the VM Guest. The Console is also available from the
6
screen.
Depending on the desired tasks, it may be necessary to reset the boot device
7
again.
Select Boot Device in virt-manager
8.7.2 Changing CPUIDs for Guests
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 conguring 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 denes the current CPU.
To redene a CPU, rst have a look at the respective cpuid denitions of the CPU
vendor. These are available from:
AMD
http://www.amd.com/us-en/assets/content_type/white
_papers_and_tech_docs/25481.pdf
Virtualization: Conguration Options and Settings 75
Intel
http://www.intel.com/Assets/PDF/appnote/241618.pdf
The cpuid is organized in several 32 bit bitmasks. In an sxp conguration, 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:
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 dened by the host
s
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 conguration scripts in /etc/xen/
vm, see /etc/xen/examples/xmexample.hvm.
76 Virtualization with Xen
Part III. Administration and Best
Practices
Administration Tasks
9.1 The Boot Loader Program
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
conguration le.
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.
9
Administration Tasks 79
Figure 9.1
Select the Xen section, then click Edit to manage the way the boot loader and Xen
function.
Boot Loader Settings
Figure 9.2
You can use the Boot Loader program to specify functionality, such as:
• Pass kernel command line parameters.
Boot Loader Settings: Section Management
80 Virtualization with Xen
• Specify the kernel image and initial RAM disk.
• Select a specic hypervisor.
•
Pass additional parameters to the hypervisor (see /usr/share/doc/packages/
xen/pdf/user.pdf section “Xen Boot Options” after installing the package
xen-doc-pdf).
You can customize your virtualization environment by editing the /boot/grub/
menu.lst le.
If the Xen option does not appear on the GRUB boot menu, you can compare your updated GRUB boot loader le with the examples below to conrm that it was updated
correctly.
The rst example shows a typical GRUB boot loader le updated to load the kernel
that supports virtualization software. The second example shows a GRUB boot loader
le that loads the PAE-enabled virtualization kernel.
Example 9.1
title XEN
root (hd0,5)
kernel /boot/xen.gz hyper_parameters
module /boot/vmlinuz-xen kernel_parameters
module /boot/initrd-xen
Xen Section in the menu.lst File (Typical)
The title line denes sections in the boot loader le. Do not change this line, because
YaST looks for the word XEN to verify that packages are installed.
The root line species 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 species the directory and lename of the hypervisor. Replace
hyper_parameters with the parameters to pass to the hypervisor. A common parameter is dom0_mem=<amount_of_memory>, which species how much memory
to allocate to Domain0. The amount of memory is specied in KB, or you can specify
the units with a K, M, or G sufx, for example 128M. If the amount is not specied,
the Domain0 takes the maximum possible memory for its operations.
Administration Tasks 81
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 rst module line species the directory and lename 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 species the directory and lename 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 rst title entry, to the number
that corresponds to the title XEN entry. In the example le, Xen is the second
title line. To specify it, change the value of default from 0 to 1.
9.2 Sparse Image Files and Disk Space
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 le is unable to write to its disk.
Consequently, it reports I/O errors.
The Reiser le system, perceiving a corrupt disk environment, automatically sets the
le system to read-only. If this situation happens, you should free up available space
on the physical disk, remount the virtual machine’s le system, and set the le system
back to read-write.
To check the actual disk requirements of a sparse image le, use the command du -h
<image file>.
To increase the available space of a sparse image le, rst increase the le size and
then the le system.
WARNING: Backup Before Resize
Touching the sizes of partitions or sparse les always bears the risk of data
failure. Do not work without a backup.
82 Virtualization with Xen
The resizing of the image le can be done online, while the VM Guest is running. Increase the size of a sparse image le with:
dd if=/dev/zero of=<image file> count=0 bs=1M seek=<new size in MB>
For example, to increase the le /var/lib/xen/images/sles11/disk0 to a
size of 16GB, use the command:
dd if=/dev/zero of=/var/lib/xen/images/sles11/disk0 count=0 bs=1M seek=16000
NOTE: Increasing Non Sparse Images
It is also possible to increase the image les of devices that are not sparse les.
However, you must know exactly where the previous image ends. Use the seek
parameter to point to the end of the image le and use a command similar to
the following:
dd if=/dev/zero of=/var/lib/xen/images/sles11/disk0 seek=8000 bs=1M
count=2000
Be sure to use the right seek, else data loss may happen.
If the VM Guest is running during the resize operation, also resize the loop device that
provides the image le to the VM Guest. First detect the correct loop device with the
command:
losetup -j /var/lib/xen/images/sles11/disk0
Then resize the loop device, for example, /dev/loop0 with the following command:
losetup -c /dev/loop0
Finally check the size of the block device inside the guest system with the command
fdisk -l /dev/xvdb. The device name depends on the actually increased device.
The resizing of the le system inside the sparse le involves tools that are depending
on the actual le system. This is described in detail in the Storage Administration Guide,
found at http://www.novell.com/documentation/sles11/stor_admin/
data/bookinfo.html.
Administration Tasks 83
9.3 Migrating Virtual Machines
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 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 has the same architecture. For
example, a 64-bit paravirtualized guest running on a 64-bit hypervisor can be migrated
to 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 le systems are available on both machines.
The options to accomplish this task include Network Block Devices (NBD),
iSCSI, NFS, DRBD and ber 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 le, 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 5.2, “Controlling the Host by
Modifying Xend Settings” (page 36). For more details about using xm to migrate VM
Guest systems, see Section 5.6, “Migrating Xen VM Guest Systems” (page 41).
9.4 Passing Key Combinations to
Virtual Machines
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.
84 Virtualization with Xen
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 the Virtual Machine Manager during and
after installing a virtual machine.
9.5 Monitoring Xen
For a regular operation of many virtual guests, having a possibility to check the sanity
of all the different VM Guest systems indispensable. Xen offers several tools besides
the system tools to gather information about the system.
9.5.1 Monitor Xen with virt-manager
After starting virt-manager and connecting to the VM Host Server, an overview
of the CPU usage of all the running guests is displayed.
It is also possible to get information about disk and network usage with this tool, however, you must rst activate this in the preferences:
1
Run virt-manager and connect to the VM Host Server system.
Select Edit > Preferences.
2
Change the tab from General to Stats.
3
Activate the check boxes for Disk I/O and Network I/O.
4
If desired, also change the update interval or the number of samples that are kept
5
in the history.
Afterwards, the disk and network statistics are also displayed in the main window of
the Virtual Machine Manager.
To get more precise data of the respective machine, select the machine, click Open and
then Details. The statistics are displayed from the Performance entry of the left-hand
tree menu.
Administration Tasks 85
9.5.2 Monitor Xen with xentop
Information is also available when only a standard terminal is available on no X environment. The preferred tool to gather information in this case is xentop. Unfortunately,
this tool needs a rather broad terminal, else it inserts line breaks into the display.
xentop has several command keys that can give you more information about the
system that is monitored. Some of the more important are:
D
Change the delay between the refreshs of the screen
N
Also display network statistics. Note, that only standard congurations will be
displayed. If you use a special conguration like a routed network, no network will
be displayed at all.
B
Display the respective block devices and their cumulated usage count.
For more information about xentop see the manual page man 1 xentop.
9.5.3 More Helpful Tools
There are many different system tools that also help monitoring or debugging a running
SUSE Linux Enterprise system. Many of these are covered in the ofcial SUSE Linux
Enterprise documentation. Especially useful for monitoring a virtualization environment
are the following tools:
ip
The command line utility ip may be used to monitor arbitrary network interfaces.
This is especially useful, if you did set up a network that is routed or applied a
masqueraded network. To monitor a network interface with the name alice.0,
run the following command:
watch ip -s link show alice.0
86 Virtualization with Xen
brctl
In a standard setup, all the Xen VM Guest systems are attached to a virtual network
bridge. brctl allows you to determine the connection between the bridge and the
virtual network adapter in the VM Guest system. For example, the output of brctl
show may look like the following:
bridge name bridge id STP enabled interfaces
br0 8000.000476f060cc no eth0
br1 8000.00001cb5a9e7 no vlan22
This shows, that there are two virtual bridges dened on the system. One is connected to the physical ethernet device eth0, the other one is connected to a vlan
interface vlan22.
There is only one guest interface active in this setup, vif1.0. This means, that
the guest with id 1 has an ethernet interface eth0 assigned, that is connected to
br0 in the VM Host Server.
iptables-save
Especially when using masquerade networks, or if several ethernet interfaces are
set up together with a rewall setup, it may be helpful to check the current rewall
rules.
The command iptables may be used to check all the different rewall settings.
To list all the rules of a chain, or even of the complete setup, you may use the
commands iptables-save or iptables -S
vif1.0
9.6 Extra Guest Descriptions in Xen
Conguration
With Xen, it is possible to add an extra descriptions to the conguration of each guest.
This may be helpful for example to document the purpose of the guest, or the responsible
person to handle the guest.
The description can be set during the installation of the guest. When running
vm-install, in the Summary screen you can set the Name of Virtual Machine. The
Administration Tasks 87
graphical interface for changing the name also contains an extra description line, that
may be used to add a single line of text.
When using the Xen conguration les in /etc/xen/vm, the syntax for setting the
description looks like this:
description="Responsible: tux@example.com"
It is also possible to change the SXP conguration to add or change the description as
described in Section 5.3, “Conguring a Virtual Machine by Modifying its Xend Set-
tings” (page 37). The description is added directly below the domain element and
looks like this:
(domain
...
(description 'Responsible: tux@example.com')
...
To retrieve the description of a specic VM Guest, for example, a guest with the name
alice, run the command:
xm list -l alice | grep description
9.7 Providing Host Information for
VM Guest Systems
In a standard Xen environment, the VM Guest systems have only very limited information about the VM Host Server system they are running on. If a guest should know
more about the VM Host Server it runs on, vhostmd can provide more information
to selected guests. To set up your system to run vhostmd, proceed as follows:
Install the package vhostmd on the VM Host Server.
1
2
Edit the le /etc/vhostmd/vhostmd.conf if you want to add or remove
metric sections from the conguration. However, the default works well.
3
Check the validity of the vhostmd.conf conguration le with the command:
cd /etc/vhostmd
xmllint --postvalid --noout vhostmd.conf
88 Virtualization with Xen
4
Start the vhostmd daemon with the command rcvhostmd start.
If vhostmd should be started automatically during startup of the system, run the
command:
chkconfig vhostmd on
5
Attach the image le /dev/shm/vhostmd0 to the VM Guest system named
alice with the command:
xm block-attach alice tap:aio:/dev/shm/vhostmd0 xvdb r
Log on on the VM Guest system.
6
7
Install the client package vm-dump-metrics.
8
Run the command vm-dump-metrics. If you would like to have the result
in a le, use the option -d <filename>.
The result of the vm-dump-metrics is an XML output. The respective metric entries
follow the DTD /etc/vhostmd/metric.dtd.
For more information, see the manual pages man 8 vhostmd and /usr/share/
doc/vhostmd/README on the VM Host Server system. On the guest, see the manual page man 1 vm-dump-metrics.
Administration Tasks 89
Loading...