Citrix DL385 - ProLiant - G5 User manual

1
XenServer Virtual Machine Installation
Guide
4.1.0
Published March 2008
1.0 Edition

XenServer Virtual
Machine Installation Guide
2
XenServer Virtual Machine Installation Guide: Release 4.1.0
Published March 2008
Copyright © 2008 Citrix Systems, Inc.
Xen®, Citrix®, XenServer™, XenCenter™ and logos are either registered trademarks or trademarks of Citrix Systems, Inc. in the
United States and/or other countries. Other company or product names are for informational purposes only and may be trademarks
of their respective owners.
This product contains an embodiment of the following patent pending intellectual property of Citrix Systems, Inc.:
1. United States Non-Provisional Utility Patent Application Serial Number 11/487,945, filed on July 17, 2006, and entitled “Using
Writeable Page Tables for Memory Address Translation in a Hypervisor Environment”.
2. United States Non-Provisional Utility Patent Application Serial Number 11/879,338, filed on July 17, 2007, and entitled “Tracking
Current Time on Multiprocessor Hosts and Virtual Machines”.

XenServer Virtual
Machine Installation Guide
3

4
Table of Contents
1. About this document .................................................................................................... 1
1.1. Overview .......................................................................................................... 1
1.2. How this Guide relates to other documentation ................................................... 1
2. Creating VMs .............................................................................................................. 2
2.1. Overview .......................................................................................................... 2
2.2. Virtual memory and disk size limits .................................................................... 2
2.3. XenServer product family virtual device support .................................................. 3
2.4. Physical to Virtual Conversion (P2V) .................................................................. 4
2.4.1. General Guidelines for Virtualizing Physical Servers ................................. 5
2.5. Cloning an existing VM ..................................................................................... 6
2.6. Importing an exported VM ................................................................................. 6
2.6.1. Exporting a VM ...................................................................................... 7
2.6.2. Importing a VM ...................................................................................... 7
3. Installing Windows VMs ............................................................................................... 9
3.1. Making the ISO available to XenServer Hosts ..................................................... 9
3.1.1. Copying ISOs to local storage ............................................................... 10
3.2. Windows paravirtualized drivers ....................................................................... 11
3.3. Remote Desktop ............................................................................................. 11
3.4. Preparing to clone a Windows VM ................................................................... 12
3.5. Release Notes ................................................................................................ 13
3.5.1. General Windows Issues ...................................................................... 13
3.5.2. Windows 2003 Server ........................................................................... 13
3.5.3. Windows XP SP2 ................................................................................. 13
3.5.4. Windows 2000 Server ........................................................................... 13
3.5.5. Windows Vista ...................................................................................... 13
4. Installing Linux VMs ................................................................................................... 14
4.1. Installation of a built-in distribution .................................................................... 15
4.2. Installing Linux from vendor media to a VM ...................................................... 15
4.3. Installing Linux from a network installation server to a VM .................................. 17
4.4. Physical-to-Virtual Installation of a Linux VM ..................................................... 18
4.4.1. Guest Installation Network .................................................................... 18
4.5. Installing the Linux guest agent ........................................................................ 19
4.6. Preparing to clone a Linux VM ......................................................................... 20
4.6.1. Machine Name ..................................................................................... 20
4.6.2. IP address ........................................................................................... 20
4.6.3. MAC address ....................................................................................... 21
4.7. Time handling in Linux VMs ............................................................................. 21
4.8. Configuring VNC for VMs ................................................................................ 21
4.8.1. Setting up Red Hat-based VMs for VNC ................................................ 21
4.8.2. Setting up SLES-based VMs for VNC .................................................... 24
4.8.3. Setting up Debian-based VMs for VNC .................................................. 27
4.8.4. Checking runlevels ............................................................................... 27
4.9. Release Notes ................................................................................................ 27
4.9.1. Debian Sarge 3.1 and Etch 4.0 ............................................................. 27
4.9.2. Red Hat Enterprise Linux 3 ................................................................... 28
4.9.3. Red Hat Enterprise Linux 4 ................................................................... 28
4.9.4. Red Hat Enterprise Linux 5 ................................................................... 29
4.9.5. CentOS 4 ............................................................................................. 30
4.9.6. CentOS 5 ............................................................................................. 30
4.9.7. SUSE Enterprise Linux 9 ...................................................................... 30
4.9.8. SUSE Enterprise Linux 10 SP1 ............................................................. 30

XenServer Virtual
Machine Installation Guide
5
4.9.9. Oracle Enterprise Linux 5 ..................................................................... 30
5. Updating VMs ............................................................................................................ 31
5.1. Updating Windows operating systems .............................................................. 31
5.2. Updating paravirtualized drivers for Windows VMs ............................................. 31
5.3. Updating Linux kernels and guest utilities ......................................................... 32
A. Creating ISO images ................................................................................................. 33
B. Setting Up a Red Hat Installation Server ..................................................................... 34
B.1. Copy installation media ................................................................................... 34
B.2. Enable remote access ..................................................................................... 34
B.2.1. NFS .................................................................................................... 34
B.2.2. FTP ..................................................................................................... 35
B.2.3. HTTP .................................................................................................. 35
C. Troubleshooting VM problems .................................................................................... 36
C.1. VM crashes .................................................................................................... 36
C.1.1. Linux VMs ........................................................................................... 36
C.1.2. Windows VMs ...................................................................................... 36
C.2. Troubleshooting boot problems on Linux VMs ................................................... 37
Index ............................................................................................................................. 38

1
Chapter 1. About this document
1.1. Overview
This document is a guide to creating Virtual Machines with XenServer™, the platform virtualization solution
from Citrix™. It describes the various methods of getting VMs up and running on XenServer Hosts for each
of the supported operating systems.
This section summarizes the rest of the guide so that you can find the information you need. The following
topics are covered:
• general information about creating VMs
• creating Windows VMs
• creating Linux VMs
• updating VMs
• Creating and using ISO images of vendor media for installing VMs
• Setting up a network repository of vendor media for installing VMs
• Troubleshooting problems with VMs
1.2. How this Guide relates to other documentation
This document is primarily aimed at system administrators who need to set up deployments of XenServer
VMs. Other documentation shipped with this release includes:
•XenServer Installation Guide provides a high level overview of XenServer, along with step-by-step in-
structions on installing XenServer Hosts and the XenCenter management console;
•XenServer Administrator's Guide describes the tasks involved in configuring a XenServer deployment --
how to set up storage, networking and resource pools, and how to administer XenServer Hosts using the
xe command line interface (CLI).
•XenServer Software Development Kit Guide presents an overview of the XenServer SDK -- a selection
of code samples that demonstrate how to write applications that interface with XenServer Hosts.
•XenAPI Specification provides a programmer's reference guide to the XenServer API.
•Release notes provide a list of known issues that affect this release.

2
Chapter 2. Creating VMs
This chapter provides an overview of how VMs are created and lists virtual memory and virtual disk size
minimums, describes the differences in virtual device support for the members of the XenServer product
family. This chapter also discusses physical to virtual conversion (P2V), cloning templates, and importing
previously-exported VMs.
2.1. Overview
VMs are created from templates. A template is a "gold image" that contains all the various configuration
settings to instantiate a specific VM. XenServer ships with a base set of templates, which range from generic
"raw" VMs that can boot an OS vendor installation CD (Windows) or run an installation from a network
repository (Red Hat Enterprise Linux, SUSE Linux Enterprise 10) to complete pre-configured OS instances
(Debian Etch and Sarge).
There are three basic methods by which VMs are created using templates:
• using a complete pre-configured template (Debian Sarge and Etch Linux)
• Installing from a CD or an ISO image onto the appropriate template (Windows 2000 SP4/Windows 2003
Server/Windows XP SP2/Windows Vista, RHEL 5.0, CentOS 5.0)
• Installing from vendor media on a network installation server directly onto a template (Red Hat Enterprise
Linux 4.x and 5.0, and SUSE Linux Enterprise Server 10 SP1)
Creating VMs by installing Windows operating systems onto the appropriate templates is described in Chap-
ter 3, Installing Windows VMs.
Creating VMs by installing Linux operating systems onto the appropriate templates is described in Chapter 4,
Installing Linux VMs.
Additionally, VMs can be created by
• performing a physical to virtual (P2V) conversion on an existing physical server (Red Hat Enterprise Linux
3.6, 3.8, 4.1-4.4, and SUSE Linux Enterprise Server 9 SP2 and SP3)
• importing an existing, exported VM
• converting an existing VM to a template
These methods are describe in this chapter.
2.2. Virtual memory and disk size limits
In general, when installing VMs, be sure to follow the memory and disk space guidelines of the operating
system and any relevant applications that you want to run when allocating resources such as memory and
disk space.
Note that individual versions of the operating systems may also impose their own maximum limits on the
amount of memory supported (for example, for licensing reasons). Also, since XenServer Express Edition
only supports a maximum of 4GB of physical RAM for the XenServer Host, 4GB is the upper limit for a
VM on this platform.

Creating VMs
3
Operating System Minimum RAM Maximum RAM Disk
space
Windows Vista 32-bit 512MB minimum supported,
768MB or more recommended
32GB 16GB
Windows 2003 128MB minimum supported;
256MB or more recommended
32GB 2GB
Windows XP SP2 128MB minimum supported;
256MB or more recommended
32GB 1.5GB
Windows 2000 SP4 128MB minimum supported;
256MB or more recommended
32GB 2GB
CentOS 4 256MB 16GB 800MB
CentOS 5 512MB 16GB 800MB
Red Hat Enterprise Linux 3.6 64MB 32GB 1.5GB
Red Hat Enterprise Linux 4.1, 4.4 256MB 32GB 800MB
Red Hat Enterprise Linux 4.5, 4.6 256MB 16GB 800MB
Red Hat Enterprise Linux 5.0, 5.1 512MB 16GB 800MB
SUSE Linux Enterprise Server 9
SP2
256MB 32GB 1GB
SUSE Linux Enterprise Server 10
SP1
512MB 32GB 1.5GB
Debian Sarge, Etch 128MB 32GB 4GB
2.3. XenServer product family virtual device support
The current version of the XenServer product family has the following general limitations on virtual devices
for VMs. Note that specific guest operating systems may have lower limits for certain features. These limi-
tations are noted in the individual guest installation section.
Virtual device Linux VMs Windows VMs
Number of virtual CPUs 32a8
Number of virtual disks 8 (including virtual CD-ROM) 8 (including virtual CD-ROM)
Number of virtual CD-
ROM drives
1 1
Number of virtual NICs 7b7
Hotplugging virtual disks add/remove add/remove
Hotplugging virtual NICs add/remove add/remove
aA maximum of 8 vCPUs are supported via XenCenter.
bexcept for SLES 10 SP1 and RHEL 3.x, 4.x, and 5.x, which support 3
Express Edition, Standard Edition, and Enterprise Edition also differ in the following ways that are relevant
for creating VMs:
Enterprise
Edition
Standard
Edition
Express
Edition
Amount of physical RAM on XenServer Host up to 128GB up to 128GB up to 4GB

Creating VMs
4
Enterprise
Edition
Standard
Edition
Express
Edition
Number of concurrent VMs 50 50 4
Support for VLANs yes yes no
Support for shared storage yes no no
Support for server pools yes no no
Support for additional QoS control yes no no
If you attempt to create a fifth VM with a Express Edition license, for example, an error message will appear
suggesting that you can upgrade your license. Licenses are applied per-host, and so for a resource pool
setup you must apply a Enterprise Edition license across all hosts before joining them into a pool.
If you downgrade a license on a host, it does not take any immediate action on running domains, but ensures
that the restrictions are enforced from that point onwards (e.g. if you have 5 VMs running and downgrade to
Express Edition, they will continue to run but you cannot start any more). License downgrade is disallowed
in the case of a host that is actively participating in a pool, so it must be ejected and then downgraded.
License expiry on a host also does not take any immediate action on running domains, but prevents new
domains being started. XenCenter will also regularly warn you if your hosts are approaching license expiry
thresholds, in advance of it.
2.4. Physical to Virtual Conversion (P2V)
Physical to Virtual Conversion (P2V) is the process by which an existing operating system on a physical
server — its filesystem, configuration, etc. — is cast into a virtualized instance of the same operating system
and filesystem, transferred, instantiated, and started as a VM on the XenServer Host.
For existing physical instances of Windows servers, a third-party tool is required. Windows P2V software
and documentation is available for download from the Citrix website at http://www.citrixxenserver.com/part-
ners/Pages/PartnerOffers.aspx.
For existing physical instances of Linux servers, this is accomplished by booting from the XenServer instal-
lation CD and choosing the P2V option. The filesystem is copied across the network onto a XenServer Host,
where it appears as a normal VM. We recommend that you perform P2V operations during off-peak hours
since the process involves transferring a large amount of data, which could impact other Virtual Machines
running on the XenServer Host.
The P2V tool requires a 64-bit capable CPU by default. If you have an existing Linux instance on an older
machine that you want to transfer via P2V, you can boot the CD via the p2v-legacy option at the initial
prompt. This does require at least a PAE-enabled machine, so for very old machines you can physically
move the hard drive to a PAE-enabled machine and perform the operation from there.
Procedure 2.1. To P2V an existing Linux server directly to a XenServer Host
1. Reboot the physical server that you want to convert and boot from the XenServer installation CD. If the
boot fails, start again and use the p2v-legacy option.
2. After the initial boot messages, you will see the "Welcome to XenServer" screen. (In this and the screens
that follow, use Tab or Alt+Tab to move between elements, Space to select, and F12 to move to the
next screen.)

Creating VMs
5
Select OK to proceed.
3. The installer does some hardware detection and initialization, then presents a screen with four choices.
Select Convert an existing OS on this machine to a VM (P2V) and choose OK to proceed.
4. A "Welcome to XenServer P2V" screen with a descriptive message is displayed next. Click OK to
proceed and follow the on-screen prompts.
When the P2V process is complete and the new VM is created, you will need to create and attach a VIF
for it to have external network connectivity. Similarly, extra disks may also be added to take advantage of
additional storage capacity available to the XenServer host.
Since the VM has new virtual network hardware, the MAC addresses it sees will also be different. Follow the
Linux cloning guidelines (see Section 4.6, “Preparing to clone a Linux VM”) for customizing the configuration
files to make the VM re-run any hardware detection scripts at startup.
2.4.1. General Guidelines for Virtualizing Physical Servers
When considering how to best begin virtualizing a collection of physical servers, it is best to gain some com-
fort level and experience with virtualizing servers that are more simply configured, moving later to servers
with more complex configurations.
Good candidates typically include servers that are used for test and development environments, and servers
used for in-house IT infrastructure (intranet web servers, DNS, NIS, and other network services, etc.). Typ-
ically servers that are doing heavily CPU-intensive tasks (sophisticated mathematical modeling, video ren-
dering) or are I/O-intensive (high-traffic commercial web sites, highly-used database servers, streaming au-
dio/video servers) are not the best candidates for virtualization at the start.
Once you've identified some physical servers that seem reasonable to work on first, you should take a close
look at how you are currently using them. What applications are they hosting? How I/O intensive are they?
How CPU-intensive are they?
To make a reasonable assessment, you should gather a reasonable amount of data on the current physical
servers that you are thinking about virtualizing. Look at system monitoring data for disk usage, CPU usage,
memory usage, and network traffic, and consider both peak and average values.
Good candidates for virtualization are:
• servers whose CPU and memory usage and NIC and disk throughput are low will be more likely to coexist
as a VM on a XenServer Host with a few other VMs without unduly constraining its performance.
• servers that are a few years old - so their performance as VMs hosted on a newer server would be
comparable to their existing state.
• servers that don't use any incompatible hardware which cannot be virtualized, such as dongles, serial or
parallel ports, or other unsupported PCI cards (serial cards, crypto accelerators, etc.).
Once you have identified a set of machines that you want to virtualize, you should plan the process to
accomplish the task. First, provision the physical servers that will serve as your XenServer Hosts. The chief
constraint on the number of VMs you can run per XenServer Host is system memory.
Next, plan how you will create the VMs. Your choices are to P2V an existing server, install a fresh server
from network-mounted vendor media, or install a base operating system using a pre-existing template.

Creating VMs
6
If you P2V an existing server, it's best to P2V a test instance of the server, and run it in parallel with the
existing physical server until you are satisfied that everything works properly in the virtual environment
before re-purposing the existing physical machine.
Next, plan how to arrange the desired VMs on the XenServer Hosts. Don't "mix up" servers - assign VMs
to specific XenServer Hosts, giving consideration to complementary resource consumption (mixing CPU-
intensive and I/O-intensive workloads) and complementary peak usage patterns (for instance, assigning
overnight batch processing and daytime interactive workloads to the same XenServer Host).
For configuring individual VMs themselves, keep these guidelines in mind:
• create single-processor VMs unless you are serving a multi-threaded application that will perform demon-
strably better with a second virtual CPU.
• when you configure the memory settings for a VM, consult the documentation for the guest operating
system you plan to run in that VM and for the applications you plan to run on them.
2.5. Cloning an existing VM
You can make a copy of an existing VM by cloning from a template. Templates are just ordinary VMs which
are intended to be used as master copies to instantiate copies from. A VM can be customized and converted
into a template, but be sure to follow the appropriate preparation procedure for the VM (see Section 3.4,
“Preparing to clone a Windows VM” for Windows and Section 4.6, “Preparing to clone a Linux VM” for Linux).
Templates cannot be used as normal VMs without first cloning them.
XenServer has two mechanisms for cloning VMs: a full copy, or a faster "Copy-on-Write" (CoW) mode which
only writes modified blocks to disk. The CoW mode is only supported for file-backed VMs. CoW is designed
to save disk space and allow fast clones, but will slightly slow down normal disk performance. A template
can be fast-cloned multiple times without slowdown, but if a template is cloned into a VM and the clone
converted back into a template, disk performance can linearly decrease depending on the number of times
this has happened. In this event, the vm-copy CLI command can be used to perform a full copy of the disks
and restore expected levels of disk performance.
Resource pools introduce some complexities around creating custom templates and cloning them. If you
create a template on a server in the pool, and all virtual disks of the source VM are on shared storage
repositories (SR), the operation of cloning that template will be forwarded to any server in the pool that can
see those shared SRs. However, if you create the template from a source VM that has any virtual disks on
a local SR, then the clone operation can only execute on the server that can see this SR.
2.6. Importing an exported VM
You can make a VM by importing an existing exported VM. Like cloning, exporting and importing a VM is a
means for creating additional VMs of a certain configuration. You might, for example, have a special-purpose
server configuration that you use many times. Once you have set up a VM the way you want it, you can export
it, and import it later at any time you want to create another copy of your specially-configured VM. Export
and import also provides a way to move a VM to another XenServer Host that is not part of a resource pool.
When importing a VM, you can choose to preserve the MAC address on any virtual network interfaces as-
sociated with it. If you do choose to generate a new MAC address, be sure to follow the appropriate prepa-
ration procedure for the imported VM (see Section 3.4, “Preparing to clone a Windows VM” for Windows
and Section 4.6, “Preparing to clone a Linux VM” for Linux).
Importing an exported VM will take some time, and depends on the size of the VM and the speed and
bandwidth of the network connection between the XenServer Host and XenCenter.

Creating VMs
7
Note
Note that an exported VM that originated on one XenServer Host might or might not be able to be
resumed on a different XenServer Host. For example, if a Windows VM created on a XenServer
Host with an Intel VT-enabled CPU is exported, then imported to a XenServer Host with an AMD-
V CPU, it will not start.
2.6.1. Exporting a VM
An existing VM can be exported via XenCenter or via the CLI. This section describes using the CLI. For
details on exporting using XenCenter, see the XenCenter online Help.
The following procedure assumes that you have multiple XenServer Hosts and that you are administering
them using the CLI on a separate machine (that is, a machine that is not one of the XenServer Hosts) where
you can maintain a library of export files. Avoid exporting a VM to a XenServer Host filesystem.
Procedure 2.2. To export a VM using the CLI
1. If it is running, shut down VM that you want to export.
2. Export the VM:
xe vm-export -h <hostname> -u <root> -pw <password> vm=<VM name> \
filename=<pathname of file>
Note
Be sure to include the .xva extension when specifying the export filename. If the exported VM
does not have this extension and you attempt to import it via XenCenter, it will fail to recognize
the file as a valid XVA file.
3. The export process will probably take some time. When finished, the command prompt returns.
2.6.2. Importing a VM
An existing exported VM file can be imported via XenCenter or via the CLI. This section describes using the
CLI. For details on importing using XenCenter, see the XenCenter online Help.
The following procedure assumes that you are administering the XenServer Host using the CLI on a separate
machine (that is, a machine that is not one of your XenServer Hosts) where you maintain a library of export
files.
Procedure 2.3. To import a VM using the CLI
1. To import the VM to the default SR on the target XenServer Host:
xe vm-import -h <hostname> -u <root> -pw <password> \
filename=<pathname of export file>
You can import the VM to another SR on the target XenServer Host by adding the optional sr-uuid
parameter:

Creating VMs
8
xe vm-import -h <hostname> -u <root> -pw <password> \
filename=<pathname of export file> sr-uuid=<UUID of target SR>
You can also preserve the MAC address of the original VM by adding the optional preserve set to
true:
xe vm-import -h <hostname> -u <root> -pw <password> \
filename=<pathname of export file> preserve=true
2. The import process will probably take some time. When finished, the command prompt returns the
UUID of the newly-imported VM.

9
Chapter 3. Installing Windows VMs
XenServer allows you to install Windows 2000 SP4, Windows Server 2003 (32-/64- bit), or Windows XP
SP2 into a VM. Installing Windows VMs on XenServer Host requires hardware virtualization support (Intel
VT or AMD-V).
Installing a Windows VM can be broken down into two main steps:
• installing the Windows operating system
• installing the paravirtualized device drivers
Windows VMs are installed by cloning an appropriate template from either XenCenter or the CLI. The tem-
plates for individual guests have predefined platform flags set which define the configuration of the virtual
hardware. For example, all Windows VMs are installed with the ACPI Hardware Abstraction Layer (HAL). If
you subsequently change one of these VMs to have multiple virtual CPUs, Windows automatically switches
the HAL to multi-processor mode.
The available Windows templates are:
•Windows Vista: can be used to install Windows Vista 32-bit. The Enterprise edition is supported.
•Windows Server 2003: can be used to install Windows Server 2003 32-bit SP0, SP1, and SP2. The
Server, Enterprise, Data Centre, and SBS editions are supported.
•Windows Server 2003 x64: can be used to install Windows Server 2003 64-bit. The Server, Enterprise,
Data Centre, and SBS editions are supported.
•Windows 2000 SP4: can be used to install Windows 2000 Server Service Pack 4. Earlier service packs
are not supported.
•Windows XP SP2: can be used to install Windows XP Service Pack 2. Earlier service packs are not
supported.
The Windows VM can be installed either from a install CD in a physical CD-ROM on the XenServer Host, or
from an ISO image of your Windows media (see Appendix A, Creating ISO images for information on how
to make an ISO image from a Windows install CD and make it available for use).
3.1. Making the ISO available to XenServer Hosts
To make an ISO library available to XenServer Hosts, create an external NFS or SMB/CIFS share directo-
ry. The NFS or SMB/CIFS server must be set to allow root access to the share. For NFS shares, this is
accomplished by setting the no_root_squash flag when you create the share entry in /etc/exports
on the NFS server.
Then either use XenCenter to attach the ISO library, or connect to the host console and type in:
xe-mount-iso-sr host:/volume
Additional arguments to the mount command may be passed in, for advanced use.

Installing Windows VMs
10
If making a Windows SMB/CIFS share available to the XenServer host, either use XenCenter to make it
available, or connect to the host console and type in:
xe-mount-iso-sr unc_path -t smbfs -o username=myname/myworkgroup
The unc_path argument should have back-slashes replaces by forward-slashes. -t cifs can be used for
CIFS instead of SMB. Examples:
xe-mount-iso-sr //server1/myisos -t cifs -o username=johndoe/mydomain
xe-mount-iso-sr //server2/iso_share -t smbfs -o username=alice
After mounting the share, any ISOs in it should be available by name from the CD pulldown list in XenCenter,
or as CD images from the CLI commands. The ISO should be attached to an appropriate Windows template:
• Windows Server 2003
• Windows Server 2003 x64
• Windows 2000 SP4
• Windows XP SP2
3.1.1. Copying ISOs to local storage
In XenServer 3.2 and earlier, ISOs could be copied directly to the control domain into the /opt/xen-
source/packages/iso directory. In XenServer 4.1.0 hosts, this directory is reserved for use of the built-
in ISO images, and is not intended for general use. This directory is considered to be identical across hosts
in a resource pool, and CD images may fail to attach if the contents are modified.
Procedure 3.1. To use local ISO storage from the control domain
1. Log onto the host console.
2. Create a directory to copy the local ISOs into:
mkdir -p /var/opt/xen/iso_import
3. Create an ISO storage repository by:
xe sr-create name-label=<name> type=iso \
device-config:location=/var/opt/xen/iso_import/<name> \
device-config:legacy_mode=true content-type=iso
4. Copy the ISO images into this directory, taking care not to fill up the control domain filesystem.
5. Verify that the ISO image is available for use by xe vdi-list, or checking the CD drop-down box in
XenCenter.

Installing Windows VMs
11
Warning
Be extremely careful with copying ISOs directly onto the control domain filesystem, as it has limited
space available. A network share is a much safer mechanism for storing large numbers of ISO
images. If the control domain does fill up, unpredictable behavior will result.
3.2. Windows paravirtualized drivers
The Citrix paravirtualizated network and SCSI drivers provide high performance I/O services without the
overhead of traditional device emulation found in first-generation virtualization products. During the instal-
lation of a Windows operating system, Xen will use traditional device emulation to present a standard IDE
controller and a standard network card to the Virtual Machine. This allows Windows to complete its instal-
lation using built-in drivers, but with reduced performance due to the overhead inherent in emulation of the
controller drivers.
After Windows is installed, you install the Citrix high-speed paravirtualized drivers. These are on an ISO
available to the virtual CD-ROM drive of the Virtual Machine. These drivers replace the emulated devices
and provide high-speed transport between Windows and the XenServer product family software.
Note
While a Windows VM will function without them, performance is significantly hampered unless these
drivers are installed. Running Windows VMs without these drivers is not supported. Some features,
such as live relocation across physical hosts, will only work with the paravirtual drivers installed
and active.
The Windows paravirtualized drivers ISO can be attached to the VM by using the Install Tools menu in
XenCenter, or by directly inserting the built-in xs-tools.iso ISO image to the VM using the CLI. Once the
ISO is attached, double-click on the xensetup.exe installer executable and follow the on-screen prompts.
Normally, the Windows paravirtualized drivers are installed by default in the directory C:\Program Files
\XenSource\Drivers on the VM.
3.3. Remote Desktop
The graphical console for Windows can be either a standard console via emulated graphics card, or an
RDP connection.
For Windows VMs, there is a Switch to Remote Desktop button on the Console tab. Clicking it disables the
standard graphical console, and switches to using Remote Desktop instead.
The button will be grayed out if you do not have Remote Desktop enabled in the VM, and the paravirtualized
drivers must be installed.
Procedure 3.2. To enable Remote Desktop on a Windows VM
1. From the Start menu, select Control Panel.
2. From the Control Panel window, select System.
3. In the System Properties dialog box, select the Remote tab.

Installing Windows VMs
12
4. In the Remote Desktop section of this dialog box, check the checkbox labeled Allow users to connect
remotely to this computer (Windows XP) or Enable Remote Desktop on this computer (Windows 2003
Server).
5. If you want to select any non-administrator users that can connect to this Windows VM, click the Select
Remote Users... button and provide the usernames. (Users with Administrator privileges on the Win-
dows domain can connect by default.)
3.4. Preparing to clone a Windows VM
You need to use the Windows utility sysprep to prepare a Windows VM for cloning. This is the only supported
way to properly clone a Windows VM.
Computers running Windows operating systems use a Security ID (SID) to uniquely identify themselves.
When cloning a Windows VM, it is important to take steps to ensure the uniqueness of these Security IDs.
Cloning an installation without taking the recommended system preparation steps can lead to duplicate SIDs
and other problems. Because the SID identifies the computer or domain as well as the user, it is critical that
it is unique. Refer to the Microsoft KnowledgeBase article 162001, "Do not disk duplicate installed versions
of Windows," for more information.
Sysprep modifies the local computer Security ID (SID)to make it unique to each computer. The Sysprep
binaries are on the Windows product CDs in the \support\tools\deploy.cab file.
Here are the overall steps you need to follow to clone Windows VMs:
1. Create, install, and configure the Windows VM as desired.
2. Apply all relevant Service Packs and updates.
3. Install the Citrix PV drivers.
4. Install any applications and perform any other tailoring that is desired.
5. Copy the contents of \support\tools\deploy.cab from the Windows product CD to a new
\sysprep folder in the VM.
6. Run sysprep (this will shut down the VM when it completes).
7. In XenCenter, convert the VM into a template.
8. Clone the newly created template into new VMs as required.
9. When the cloned VM starts, it will get a new system ID and name, then run a mini-setup to prompt for
configuration values as necessary, and finally restart, before being available for use.
Note
The original, sysprepped VM (the "source" VM) should not be restarted again after the sysprep
stage, and should be converted to a template immediately afterwards to prevent this. If the source
VM is restarted, sysprep must be run on it again before it can be safely used to make additional
clones.
For more information on using sysprep, refer to the Microsoft TechNet page "Windows System Preparation
Tool."

Installing Windows VMs
13
3.5. Release Notes
There are many versions and variations of Windows with different levels of support for the features provided
by XenServer. This section lists notes and errata for the known differences.
3.5.1. General Windows Issues
• When installing Windows virtual machines, users should start off with fewer than four disks. Once the VM
and XenServer tools have been installed, users can then add additional virtual disks. The boot device
should always be on the lower four disks so that the VM can boot without the XenServer tools.
• Multiple VCPUs are exposed as CPU sockets to Windows guests, and are subject to the licensing limita-
tions present in the guest. The number of CPUs present in the guest can be confirmed by checking the
Device Manager. The number of CPUs actually being used by Windows can be seen in the Task Manager.
• The disk enumeration order in a Windows guest may differ from the order in which they were initially
added. This is a behavioral artifact between the paravirtualized drivers and the PnP subsystem in Win-
dows. For example, the first disk may show up as Disk 1, the next disk hotplugged as Disk 0, a subsequent
disk as Disk 2, and then upwards in the expected fashion.
• There is a bug in the VLC player DirectX backend that causes yellow to be replaced by blue when playing
video if the Windows display properties are set to 24-bit color. VLC using OpenGL as a backend works
correctly, and any other DirectX- or OpenGL-based video player works fine, too. It is not a problem if the
guest is set to use 16-bit color rather than 24.
3.5.2. Windows 2003 Server
No known issues.
3.5.3. Windows XP SP2
Windows XP does not support disks larger than 2TB (terabytes) in size. See this article in the Windows
Hardware Developer Central website.
3.5.4. Windows 2000 Server
No known issues.
3.5.5. Windows Vista
Microsoft Vista recommends a root disk of size 18GB or higher. The default size when installing this template
is 16GB, which is 3GB greater than the minimum. However, users should consider increasing this to comply
with the Microsoft recommendations when they install Vista VMs.

14
Chapter 4. Installing Linux VMs
XenServer supports the installation of many Linux distributions into paravirtualized VMs. There are four
installation mechanisms at present: complete distributions provided as built-in templates, Physical-to-Virtual
(P2V) conversion of an existing native instance (see Section 2.4, “Physical to Virtual Conversion (P2V)”),
using the vendor media in the server's physlca DVD/CD drive, and using the vendor media to perform a
network installation.
Installing Linux VMs requires the Linux Pack to be installed onto the XenServer Host.
Warning
If you have not installed the Linux Pack, and you are using XenCenter to install VMs, the New VM
wizard will show only Windows choices in the list. You might be tempted to select Other install media
to install a Linux VMs. This will not work properly and is not supported.
The Other install media template is meant for advanced users who want to attempt installing VMs
running other unsupported operating systems. XenServer has been tested running only the sup-
ported distributions and specific versions covered by the standard supplied templates, and any VMs
installed using the Other install media template are not supported.
The supported Linux distributions are:
Distribution Built-in P2V Vendor Install from
CD
Vendor Install from
network repository
Debian Sarge 3.1 X
Debian Etch 4.0 X
Red Hat Enterprise Linux 3.6-3.8 X
Red Hat Enterprise Linux 4.1-4.5 X X
Red Hat Enterprise Linux 5.0-5.1 32-
bit
X X
Red Hat Enterprise Linux 5.0-5.1 64-
bit
X X
SUSE Linux Enterprise Server 9 X
SUSE Linux Enterprise Server 10
SP1
X
CentOS 4.5-4.6 X X
CentOS 5.0-5.1 32-bit X X
CentOS 5.0-5.1 64-bit X X
Oracle Enterprise Linux 5.0-5.1 32-
bit
X X
Oracle Enterprise Linux 5.0-5.1 64-
bit
X X
Note
Distributions which use the same installation mechanism as Red Hat Enterprise Linux 5 (e.g. Fedora
Core 6) might be successfully installed using the same template. However, distributions not present
in the above list are not supported.

Installing Linux VMs
15
4.1. Installation of a built-in distribution
This is the simplest way of installing a VM. The template provided with XenServer can be used to directly
create a VM running version 3.1 (Sarge) or 4.0 (Etch) of the Debian Linux distribution without need for
vendor installation media and without performing a P2V conversion of an existing physical server.
The VMs are instantiated by using the vm-install from the CLI, or by cloning the template using XenCenter.
For example, using the CLI on Linux:
# xe vm-install template=Debian\ Etch\ 4.0 new-name-label=ExampleVM
f21cd819-5b7d-002d-7a1e-861a954e770
When the VM is first booted, it will prompt you for a root password, a VNC password (for graphical use),
and a hostname. After values are entered for these, it will finish at a standard login prompt, ready for use.
You will need to add a network interface if installed via the CLI.
4.2. Installing Linux from vendor media to a VM
This version of XenServer supports installation of the following Linux operating systems from vendor media
in the XenServer Host DVD/CD-ROM drive:
• Red Hat Enterprise Linux 5.0-5.1, 32-bit
• Red Hat Enterprise Linux 5.0-5.1, 64-bit
• CentOS 4.5-4.6
• CentOS 5.0-5.1, 32-bit
• CentOS 5.0-5.1, 64-bit
• Oracle Enterprise Linux 5.0-5.1, 32-bit
• Oracle Enterprise Linux 5.0-5.1, 64-bit
Other Linux operating systems need to be installed from a network installation server. See Section 4.3,
“Installing Linux from a network installation server to a VM”.
Procedure 4.1. To install a supported Linux VM from vendor media via the CLI
1. Insert the vendor installation CD into the XenServer Host's CD drive.
2. Enter the command
# xe template-list
to find the name of the template corresponding to the OS you want to install.
3. Enter the command