Citrix* XenServer* 5.5.0 Installation Guide Intel® Server Board S3420GP
www.intel.com/go/esaa
The information contained in this document is provided for informational purposes only and represents the current view of Intel Corporation (“Intel”)
and its contributors ("Contributors") on, as of the date of publication. Intel and the Contributors make no commitment to update the information
contained in this document, and Intel reserves the right to make changes at any time, without notice.
DISCLAIMER. THIS DOCUMENT, IS PROVIDED “AS IS.” NEITHER INTEL, NOR THE CONTRIBUTORS MAKE ANY REPRESENTATIONS OF ANY KIND WITH
RESPECT TO PRODUCTS REFERENCED HEREIN, WHETHER SUCH PRODUCTS ARE THOSE OF INTEL, THE CONTRIBUTORS, OR THIRD PARTIES. INTEL,
AND ITS CONTRIBUTORS EXPRESSLY DISCLAIM ANY AND ALL WARRANTIES, IMPLIED OR EXPRESS, INCLUDING WITHOUT LIMITATION, ANY
WARRANTIES OF MERCHANTABILITY, FITNESS FOR ANY PARTICULAR PURPOSE, NON-INFRINGEMENT, AND ANY WARRANTY ARISING OUT OF THE
INFORMATION CONTAINED HEREIN, INCLUDING WITHOUT LIMITATION, ANY PRODUCTS, SPECIFICATIONS, OR OTHER MATERIALS REFERENCED
HEREIN. INTEL, AND ITS CONTRIBUTORS DO NOT WARRANT THAT THIS DOCUMENT IS FREE FROM ERRORS, OR THAT ANY PRODUCTS OR OTHER
TECHNOLOGY DEVELOPED IN CONFORMANCE WITH THIS DOCUMENT WILL PERFORM IN THE INTENDED MANNER, OR WILL BE FREE FROM
INFRINGEMENT OF THIRD PARTY PROPRIETARY RIGHTS, AND INTEL, AND ITS CONTRIBUTORS DISCLAIM ALL LIABILITY THEREFOR.
INTEL, AND ITS CONTRIBUTORS DO NOT WARRANT THAT ANY PRODUCT REFERENCED HEREIN OR ANY PRODUCT OR TECHNOLOGY DEVELOPED IN
RELIANCE UPON THIS DOCUMENT, IN WHOLE OR IN PART, WILL BE SUFFICIENT, ACCURATE, RELIABLE, COMPLETE, FREE FROM DEFECTS OR SAFE
FOR ITS INTENDED PURPOSE, AND HEREBY DISCLAIM ALL LIABILITIES THEREFOR. ANY PERSON MAKING, USING OR SELLING SUCH PRODUCT OR
TECHNOLOGY DOES SO AT HIS OR HER OWN RISK.
Licenses may be required. Intel, its contributors and others may have patents or pending patent applications, trademarks, copyrights or other
intellectual proprietary rights covering subject matter contained or described in this document. No license, express, implied, by estoppel or
otherwise, to any intellectual property rights of Intel or any other party is granted herein. It is your responsibility to seek licenses for such
intellectual property rights from Intel and others where appropriate.
Limited License Grant. Intel hereby grants you a limited copyright license to copy this document for your use and internal distribution only. You may
not distribute this document externally, in whole or in part, to any other person or entity.
LIMITED LIABILITY. IN NO EVENT SHALL INTEL, OR ITS CONTRIBUTORS HAVE ANY LIABILITY TO YOU OR TO ANY OTHER THIRD PARTY, FOR ANY
LOST PROFITS, LOST DATA, LOSS OF USE OR COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY DIRECT, INDIRECT,
SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF YOUR USE OF THIS DOCUMENT OR RELIANCE UPON THE INFORMATION CONTAINED
HEREIN, UNDER ANY CAUSE OF ACTION OR THEORY OF LIABILITY, AND IRRESPECTIVE OF WHETHER INTEL, OR ANY CONTRIBUTOR HAS ADVANCE
NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. THESE LIMITATIONS SHALL APPLY NOTWITHSTANDING THE FAILURE OF THE ESSENTIAL PURPOSE
OF ANY LIMITED REMEDY.
Intel, the Intel logo, and Intel Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other
countries.
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.:
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”.
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”.
Enterprise-Ready Features in XenServer* 5.5.0 ....................................................................................................... 6
System Requirements ........................................................................................................................... 9
XenServer* Host System Requirements .......................................................................................................................... 9
VM Support .............................................................................................................................................................................................. 10
Install a License File with XenCenter* ............................................................................................................................ 11
Install a License File with the “xe” CLI ............................................................................................................................. 11
Install the XenServer* and XenCenter* Software ........................................................... 12
Install the XenServer* Host ...................................................................................................................................................... 12
Install or Upgrade the XenServer* Host ........................................................................................................................ 13
XenServer* Installation and Deployment Scenarios ....................................................... 18
XenServer* Hosts with Local Storage ............................................................................................................................ 18
XenServer* Hosts with Shared NFS Storage ........................................................................................................... 19
Setup an NFS Share on an NFS Server ........................................................................................................................... 19
Create a Pool-Level SR on the NFS Share ................................................................................................................... 20
XenServer* Hosts with Shared iSCSI Storage ......................................................................................................... 20
Prepare the iSCSI Storage .......................................................................................................................................................... 21
Configure the iSCSI IQN for Each XenServer* Host via the CLI ............................................................... 21
Create a Pool-Level SR on the iSCSI Share via the CLI .................................................................................... 22
Upgrade, Update, or Reinstall XenServer* ............................................................................ 22
Prepare to Upgrade XenServer* Hosts .......................................................................................................................... 22
Apply Updates with the CLI ...................................................................................................................................................... 24
Reinstall the Same XenServer* Version ........................................................................................................................ 25
Backup and Restore XenServer* Hosts and VMs ............................................................. 26
Backup Pooled Installations ...................................................................................................................................................... 27
Restore the Backup on a New Set of Hosts ............................................................................................................. 27
Setup the PXE Boot Environment ...................................................................................................................................... 30
Setup a TFTP Server for PXE-Booting ........................................................................................................................... 30
Setup a DHCP Server ....................................................................................................................................................................... 32
Setup the Installation Media Host ...................................................................................................................................... 32
Prepare the Destination System .......................................................................................................................................... 33
Create an Answerfile for Unattended PXE Installation .................................................................................. 33
Installation Media Repository Format ............................................................................................................................. 35
Installation Media Repository Metadata ....................................................................................................................... 35
Best Practice Notes ......................................................................................................................................................................... 37
Set Control Domain Memory .................................................................................................................................................... 38
Support Information ........................................................................................................................... 39
Intel® ESAA – Your Recipe for Success .................................................................................... 39
This Intel® ESAA recipe is an installation guide for Citrix* XenServer* 5.5.0, a platform virtualization
solution. The XenServer package contains everything needed to create a network of virtual x86
computers running on Xen*, the open-source paravirtualizing hypervisor with near-native performance.
This recipe contains information for the installation, configuration, and initial operation of XenServer.
This recipe also contains information about troubleshooting problems that may occur during
installation, and where to go for further information.
Additional Documentation
Other documentation shipped with this release includes:
XenServer Virtual Machine Installation Guide - Describes how to install Linux* and Windows* VMs
on top of a XenServer* deployment. In addition to explaining how to install new VMs from install
media or via the VM templates provided with the XenServer release, this guide also explains how
to create VMs from existing physical machines, via a process called “P2V”.
XenServer Administrator's Guide - Describes the steps to configure 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 - Provides a list of known issues that affect this release.
Enterprise-Ready Features in XenServer* 5.5.0
XenServer* 5.5.0 includes a number of new features and ongoing improvements in hardware support,
performance and scalability. For a detailed list, refer to the XenServer 5.5.0 Release Notes. The
following is a summary of features in XenServer 5.5.0 that deliver enterprise-class virtualization
infrastructure, with those added in version 5.5.0 indicated
New Guest Support
The following new guest operating systems have been added in XenServer* 5.0.0 and XenServer
5.5.0:
Windows Server* 2008 32-bit and 64-bit support, with WHQL signed paravirtual drivers and initial
enlightenment optimizations.
Windows XP* Service Pack 3 and Vista* Service Pack 1 support.
SUSE* Enterprise Linux* 9 SP4 32-bit and 10 SP1/2 and 11 64-bit support.
Red Hat* Enterprise Linux* 4.7 32-bit and 5.2 and 5.3 32-bit/64-bit support, including graphical
installation.
SUSE* Enterprise Linux* 10 installation directly from CD or ISO images as well as network
repositories.
6
Page 7
Citrix* XenServer* 5.5.0 Installation Guide -
Intel® Server Board S3420GP
Linux* guests have been refreshed to their latest upstream versions, including the bundled XenServer*
kernels which fixes stability issues not addressed in the upstream releases.
Business Continuity
XenServer* supports several features to maximize service uptime in the event of infrastructure failure.
These include:
Redundant storage (via multipath) and network (via NIC bonding) heartbeats eliminate single
points of network failure and permit reliable detection of genuine host failure.
Generate e-mail and XenCenter* alerts on host failures.
Integrated disaster recovery to enable regular backups of virtual machine metadata. Peer-to-peer
"self-healing" architecture ensures there is no single point of management failure.
When combined with SAN storage replication, this provides an efficient way to migrate entire
resource pools to another physical site and continue running services with little interruption. It also
permits the use of storage repositories, including the metadata for VMs installed on them, which
permits a "transportable VM" model across resource pools.
iSCSI multipath support, configurable from the XenCenter* GUI. This ensures redundant storage
links to an iSCSI SR and permits link failures without loss of service.
Improved network reliability by support active/active NIC aggregation. Existing active/passive NIC
bonds on older installations are upgraded to aggregation mode for active/active usage, permitting
full use of all available bandwidth while still maintaining redundant links.
Multiple management network interfaces can be defined in the control domain, and individual
networks can be dedicated for use by network storage, e.g., iSCSI or NFS. This improves isolation
between VMs and storage infrastructure traffic.
With the addition of Citrix* Essentials* for XenServer*, resource pools can be configured for
automated high-availability. This addresses individual host failures by restarting VMs running on a host
onto the next available machine in the resource pool. Additional reliability features in Citrix Essentials
include:
The ability to set VM restart priorities individually to control the order services are restarted in a
host failure.
Dynamic failure planning algorithms allow administrators to see how many hosts failures can be
tolerated without compromising services.
One of the most common reasons for system failure is misconfiguration by an operator. Citrix
Essentials for XenServer now provides e-mail and XenCenter alerting for potentially dangerous
configurations, for example, when VM performance will be degraded or a resource pool is
overcommitted with respect to high availability.
Storage and Provisioning
Diskless virtual machines running on Citrix* Provisioning Server* now support more advanced PXE
configurations, such as DHCP Proxy ARP responses or wide-area DHCP relays. Support for PXE servers
such as Altiris* and Windows Deployment Services* (WDS) is improved. There is support in XenServer*
5.5.0 for VM storage snapshots for backup enablement, and CLI-only support for quiesced, fully
consistent VM storage snapshots for Windows* VMs.
7
Page 8
Citrix* XenServer* 5.5.0 Installation Guide Intel® Server Board S3420GP
Citrix* Essentials* for XenServer includes a new storage integration service called StorageLink. Via
StorageLink, administrators may directly manage the fast cloning, snapshot, and thin provisioning
capabilities of many models of intelligent storage.
Usability and Reliability
Performance statistics now persist in a round-robin database on the XenServer* pool, with decreasing
granularity as time passes. This enables long-term trending and resource optimization for complex
data center deployments. The XenCenter* GUI supports connecting to hosts running the current and
previous release, and has several new features:
Host networking configuration support, including dedicating network interfaces for storage use.
Permit editing settings on existing SRs, and improved workflow for detaching and reattaching SRs.
Support user-defined grouping and searching across VMs, hosts and resource pools, including
defining custom fields and tags to identify resources.
New interactive graphing interface to display persistent performance statistics across resource
pools.
Detect when a host has been re-installed and warn the administrator.
Enhanced support for keeping hosts up-to-date with the latest improvements:
Rolling zero-downtime resource pool upgrades from the previous release to XenServer* hosts.
XenCenter* support to automatically check for updates and generate alerts for the administrators
if any are available.
Integration with StorageLink SRs (only in Citrix Essentials)
A menu-driven text console is now present when connecting to the main screen of the XenServer*
host. This new interface provides an alternative to XenCenter* for common operations or when
networking is not otherwise available. The boot process is more user-friendly, with a graphical splash
screen and progress indicator.
Performance and Hardware
The core Xen* hypervisor has been upgraded to a version based on the stable 3.3.1 release. Major
improvements include:
Support for Intel® Xeon® processor 5500 series, (Intel® microarchitecture, code named Nehalem)
including Enhanced Page Table (EPT) optimizations and other performance improvements
Improvements to emulating legacy 16-bit code means a wider variety of older applications and
bootloaders will run successfully. Support for foreign-language versions of Windows* are
improved.
The Windows* paravirtual storage drivers now utilize a SCSI filter interface which reduces
overhead and increases performance when used with multiple virtual disks.
Citrix* XenApp* performance is further optimized with improvements to Xen* shadow page-table
handling.
Reduced memory usage in the control domain increases the maximum number of VMs supported.
8
Page 9
Citrix* XenServer* 5.5.0 Installation Guide -
CPUs
One or more 64-bit x86 CPU(s), 1.5 GHz minimum, 2 GHz or faster multicore CPU
recommended
To support VMs running Windows*, an Intel® VT 64-bit x86-based system with one or more
(up to 32) CPUs is required.
Note: To run Windows* VMs, hardware support for virtualization must be enabled on the
XenServer* host. This is an option in the BIOS. It is possible the system BIOS might have
virtualization support disabled. Consult BIOS documentation for more details.
To support VMs running supported paravirtualized Linux*, a standard 64-bit x86-based
system with one or more (up to 32) CPUs is required.
RAM
1 GB minimum; 2 GB or more recommended.
Disk Space
Locally attached storage SATA, SAS with 16 GB of disk space minimum.
60 GB of disk space recommended
General disk space requirements for VMs:
Product installation creates two 4GB partitions for the XenServer* host control domain;
the remaining space is available for VMs:
VMs based on the Debian* templates are allocated a 4 GB root device, and a 512 MB
swap device.
Linux* VMs are allocated an 8 GB root device.
Windows* Vista* VMs are allocated a 16 GB root device; other Windows VMs default
to 8 GB.
Network
100 Mbit/s or faster network interface card (NIC). A gigabit NIC is recommended for faster
P2V and export/import data transfers and for live relocation of VMs.
Intel® Server Board S3420GP
System Requirements
XenServer* requires at least two separate physical x86 computers:
One to be the XenServer* host.
One to run the XenCenter* application.
The XenServer host machine is dedicated to the task of hosting VMs and is not used for other
applications. The computer that runs XenCenter can be any general-purpose Windows* computer with
the hardware requirements, and can be used to run other applications simultaneously.
XenServer* Host System Requirements
The XenServer* host is a 64-bit, x86 server-class machine devoted to hosting multiple VMs. This
machine runs a stripped-down Linux* operating system with a Xen*-enabled kernel that controls the
interaction between the virtualized devices seen by VMs and the physical hardware. The following are
the system requirements for the XenServer host:
Table 3 – System Requirements for the XenServer* Host
XenCenter* Requirements
The remote XenCenter* application for managing the XenServer* host can be installed and run on any
Windows* 2003*, Windows XP*, Windows Vista* workstation or laptop.
The following are the system requirements for XenCenter*:
9
Page 10
Citrix* XenServer* 5.5.0 Installation Guide -
Operating system
Windows* XP*, Windows Server* 2003, or Windows Vista*.
.NET framework
Version 2.0 or above.
CPU Speed
750 MHz minimum, 1 GHz or faster recommended.
RAM
1 GB minimum; 2 GB or more recommended.
Disk space
100 MB minimum.
Network interface card
100Mb or faster NIC.
Intel® Server Board S3420GP
Table 4 – System Requirements for XenCenter
VM Support
Windows* VMs can be created only on XenServer* hosts equipped with Intel® VT-enabled CPUs. All
Windows VMs are created by installing the operating system from either the Microsoft* installation
media in the XenServer host physical CD/DVD-ROM drive or a network-accessible ISO image to the
appropriate template.
Linux* VMs do not require XenServer hosts equipped with Intel® VT-enabled CPUs.
For a list of supported Windows* and Linux* distributions, refer to the XenServer Virtual Machine Installation Guide.
XenServer* Licensing
When XenServer* 5.5.0 is first installed, the product is enabled with the XenServer* feature set for 30
days. To continue using the product beyond the 30-day window or to enable the more advanced
capabilities found in Citrix Essentials for XenServer, a corresponding license key, in the form of a
license file, must be installed on each system.
The license key is provided in the form of a license file with the “.xslic” extension. Extending the
XenServer activation period is done via the XenCenter console. In-product activation extends the
XenServer license for a year; the product must be reactivated at no cost annually. Citrix* Essentials*
license files are issued to the designated organization by Citrix; they are perpetual licenses, and do not
require annual renewal. License files can be installed on a XenServer host system in a number of
different ways including:
Applying the license file to a selected server from within XenCenter*.
With the “xe” command line interface (CLI) “xe host-license-add” command.
10
Page 11
Citrix* XenServer* 5.5.0 Installation Guide -
Intel® Server Board S3420GP
Install a License File with XenCenter*
To install a license file, open XenCenter* and perform these steps:
1) Select the server in the “Resources” pane.
2) In the “Server” menu, click “Install License Key”.
3) Locate the license file and click “Open”. By default, only license files with the “.xslic” extension is
displayed.
Install a License File with the “xe” CLI
To install a license file with the “xe” CLI, on the server console, enter the command:
Note: Each host system in a resource pool must be individually licensed. For example, if supporting
four XenServer hosts in a resource pool, apply four unique license files to each of the four host
systems.
The following are scenarios regarding the XenServer 5.5.0 license:
Q: The XenServer* (annual, not-for-resale, or trial) license has expired. What is going to happen?
A: If the license on a XenServer host expires while the system is still running, all active virtual
machines continue to run as long as the host system is not disrupted. However, new VMs cannot
be launched. If the host system is disrupted, VMs cannot be restarted.
Note: Citrix* strongly encourages customers who opt for the XenServer* annual license to renew
their new annual license before the expiration date to ensure the greatest degree of continuity.
XenCenter alerts will be generated daily from 30 days before the license is due to expire, to give
enough notice to upgrade.
Q: The license file from a previous version of XenServer* does not work with XenServer 5.0.0
A: All license files, beginning with XenServer* 3.x, are incompatible with XenServer 5.0.0.
XenServer 3.x customers under valid software maintenance or Subscription Advantage
agreements will receive a valid XenServer 4.x license file from Citrix* and these newly-issued
license files should be used in conjunction with XenServer 5.0.0. XenServer 4.0.1 and 4.1.0 license
files are forward-compatible with XenServer 5.0.0 and 5.5.0.
Q: This XenServer* 4.0.1 license file has a “.txt” extension, but the product licensing instructions
reference a license file with the “.xslic” extension. Does this mean the XenServer 4.0 license is
incompatible?
A: No. In general, XenServer* 4.0 license files are forward-compatible with XenServer 5.0.0 and
up and as a result, Xen-Center* can import valid XenServer 4.x license files of any extension. For
some administrators, it may be easier to rename an older XenServer 4.0 license key with a “.txt”
extension to a file with the “.xslic” extension prior to applying the license file in XenCenter.
Q: Is there a way to manually install a XenServer* license file without using XenCenter*?
11
Page 12
Citrix* XenServer* 5.5.0 Installation Guide Intel® Server Board S3420GP
A: Yes. First, license files can be manually installed using the “xe” CLI. The “host-license-add”
command allows a local license file to be installed on a particular XenServer* host. For more
information about using the “xe” command, refer to the XenServer Administrator's Guide. Another
option is to use Secure Copy (SCP) to upload a license file from a system where the license file
resides to a XenServer host. The target path on the XenServer host system must be
“/etc/xensource/license”. Citrix* strongly recommends using SCP to apply a license file only as a
last resort, such as when the XenCenter console or “xe” CLI are unavailable.
Install the XenServer* and XenCenter* Software
Any XenServer* network, from the simplest deployment to the most complex, is made up of one or
more XenServer hosts, each running a given number of VMs, and one or more workstations running
XenCenter* to administer the XenServer hosts. To create resource pools and enable XenMotion* (live
migration of VMs), shared storage also needs to be deployed on the network. This version of the
XenServer product family supports Fibre Channel, NetApp* filers, LVM over iSCSI, and NFS shared
storage.
This section explains how to:
Install XenServer* host software on physical servers.
Install XenCenter* on Windows* workstations.
Connect them to form the infrastructure for a network of Virtual Machines.
Included in the detailed installation steps for the XenServer* host and XenCenter* are deployment
scenarios and information specific to each scenario. Installers for the XenServer host and XenCenter
are included in the installation media. The installation media also includes:
A set of XenServer* product documents in Adobe* Acrobat* PDF format.
A P2V tool to create VM templates from existing instances of supported Linux* distributions
running on physical servers. See the XenServer Virtual Machine Installation Guide for details.
A tool to restore a backed-up XenServer host control domain file system. See the Backup a
XenServer Host section on page 28 for details.
Install the XenServer* Host
The XenServer* host consists of:
A Xen*-enabled Linux* operating system.
A management agent.
VM templates.
A local storage repository reserved for VMs.
The XenServer host must be installed on a dedicated 64-bit x86 server. XenServer* is not supported in
a dual-boot configuration with any other operating system. The XenServer host can be installed from
the installation CDs or booted via PXE from a network-accessible TFTP server. For details about
setting up a TFTP server for PXE-booting the installer, see Appendix B: Maintenance Procedures on
page 30.
12
Page 13
Citrix* XenServer* 5.5.0 Installation Guide -
Intel® Server Board S3420GP
Note: Do not install any other operating system in a dual boot configuration with the XenServer*
host: this is an unsupported configuration.
The main installation CD contains the basic packages to set up the XenServer* host on a physical host,
and to create Windows* VMs from Windows installation CDs. The XenServer package also contains a
separate CD that contains support for creating Linux* VMs (including complete built-in distributions of
Debian*, Sarge* and Etch*), and six CDs that contain source code for the included open-source
software. The installer has an upgrade choice if it is run on a server that already has a previous version
of XenServer on it. It parallels the first-time installation process but several setup steps are bypassed,
and the existing settings for networking configuration, system time setting, etc. are retained.
To only create Windows* VMs, install XenServer* using only the first CD. To install Linux* VMs, be sure
to:
1) Download the Linux* Pack ISO.
2) Burn it to a physical CD if installing from a DVD/CD drive or set it up for PXE installation as
described in Appendix B: Maintenance Procedures on page 30.
Note: If XenServer* is installed without Linux* support, but will be added at a later time, mount the
Linux* Pack installation CD or ISO image on the XenServer host and run the “install.sh” script,
located in the CD root.
Install or Upgrade the XenServer* Host
Warning: If performing an upgrade, ensure there are no suspended virtual machines, because they
may not be resumable after the upgrade. Ensure all virtual machine CD/DVD drives are empty.
To install or upgrade the XenServer* host, perform these steps:
1) Boot the computer from the main installation CD or PXE-boot from a TFTP server, if applicable.
See Appendix B: Maintenance Procedures on page 30 for details on how to setup the XenServer
media for PXE installation.
2) After the initial boot messages, the installer detects hardware, initializes, then displays a screen to
select which keyboard keymap to use for the installation. In this screen, and the ones that follow,
use the “Tab” or “Alt”+”Tab” keys to move between elements, the space bar to select items, and
the “F12” key to move to the next screen.
3) Select the desired keymap and select “OK”.
4) The Welcome to XenServer screen appears. Select “Install or Upgrade XenServer host”, then select
“OK”.
5) The next screen displays a message that reports the setup program will install XenServer* on the
computer, and warns it will overwrite data on hard drives selected for the installation. Select “OK”.
6) The XenServer* End User License Agreement (EULA) is displayed. Use the “up” and “down” arrow
keys to scroll through and read the agreement. Select “Accept EULA” to proceed.
7) At this point, if the computer the XenServer* host is being installed on does not have a CPU that
supports hardware virtualization or if the support is disabled in the BIOS, a message warning that
Windows* VMs will not be able to run on it appears. Select “OK”.
13
Page 14
Citrix* XenServer* 5.5.0 Installation Guide Intel® Server Board S3420GP
Note: Some systems have “bugs” in their BIOS software that can result in a correct setting being
incorrect. If a warning about a lack of hardware virtualization appears or if a warning does not
appear when expected, perform a hard power-cycle of the host and restart the installation. Also
refer to the hardware manufacturer's support site for BIOS upgrades.
8) If the installer detects a previously-installed version of XenServer* host, the option to perform a
clean installation or to upgrade the existing version, that preserves any present VMs, is presented.
Select the desired installation type, then select “OK”.
− If upgrading an existing version, a message reports the installer will create a backup of the
existing installation. Select “Continue”.
9) If multiple local hard disks are present, choose a primary disk for the installation, then select “OK”.
10) After selecting a primary disk, a prompt to choose other drives to be formatted for use by
XenServer* for VM storage appears. Make a selection, if applicable, then select “OK”.
−If the computer has a single hard disk, steps 8 and 9 do not apply.
11) In the next screen, specify the source of the installation packages:
−If installing from the CD, select “Local media (CD-ROM)”.
If “Local media” is selected, the next screen prompts to install the Linux* Pack from a
second CD. If installing VMs to run Linux* operating systems, select “Yes”. To install
only Windows* VMs, select “No”.
Important: In a pooled setup the Linux* Pack must be installed either on all of the pool
XenServer hosts or on none of them so they are matched.
If “Local media” is selected, the networking setup appears later in the installation
process.
−If installing via PXE, select the appropriate “HTTP or FTP” or “NFS” option. If “HTTP or FTP” or
“NFS” is selected, a prompt to setup networking so the installation script can connect to the
product repository appears.
− If the computer has multiple network interfaces, a prompt to select one to access the
XenServer* product repository appears. Make a selection, if applicable, then select “OK”.
− If the computer has a single network interface, the interface accesses the XenServer* product
repository, and no prompt is displayed.
− The NIC can be configured one of two ways:
Automatic configuration (DHCP) to configure the NIC using DHCP.
Static configuration, which prompts to configure the NIC's properties manually. A
prompt to provide the URL or NFS server and path where the installation media are
appears.
Note: To be part of a resource pool, XenServer* hosts must have static IP addresses.
12) The next screen prompts to verify the integrity of the installation media:
−If “Verify installation source” is selected , the MD5 checksum of the packages is calculated and
checked against the known value. This may take some time.
− If “Skip verification” is selected, this check is bypassed.
Choose one of the options, then select “OK” to proceed.
14
Page 15
Citrix* XenServer* 5.5.0 Installation Guide -
Intel® Server Board S3420GP
13) A prompt to set a root password appears. The root password is used by the XenCenter*
application to connect to the XenServer* host. Type the root password and type it again to verify
it.
14) If a clean installation is selected in step 7, a prompt to set up networking for the management NIC,
the interface used to connect to the XenCenter*, appears.
− If upgrading an existing installation in step 7, the existing management NIC configuration is
used.
15) If the computer has multiple network interfaces, a prompt to select one to be used as the
management NIC for the XenServer* host software appears. Select one, then select “OK”.
− If the computer has a single network interface, that interface is used as the management NIC
and no prompt is displayed. In the next screen, choose one of the following:
Select “Automatic configuration (DHCP)” to configure the NIC using DHCP.
Select “Static configuration” which prompts to configure the NIC's properties
manually.
Notes: 1) To be part of a resource pool, XenServer* hosts must have static IP addresses.
2) Drivers for some add-on NIC’s are not present in the XenServer 5.5.0 install. If NIC’s are not
recognized, once the installation is complete, apply Update 1 and Update 2, and rescan for the
NIC’s using the following command:
# xe pif-scan host-uuid=<uuid of host>
Once the rescan is complete, run the following command to confirm the new NIC’s are seen:
# xe pif-list
16) If performing a clean installation, a prompt to specify the hostname and the configuration for the
name service appears. In the “Hostname Configuration” section:
− If “Automatically set via DHCP” is selected, the DHCP server will provide the hostname and the
IP address.
− If “Manually specify” is selected, enter the hostname for the server in the corresponding field.
− In the “DNS Configuration” section, enter the IP addresses of the primary (required), secondary
(optional), and tertiary (optional) nameservers in the corresponding fields.
− If upgrading an existing installation, the existing hostname and name service configuration is
used.
17) Select “OK” to proceed.
18) If performing a clean installation, a prompt to select the general geographical area for the time
zone appears. Select the location of the physical computer where the XenServer* host is installed
on, from the list of geographical areas, then select “OK”.
19) A prompt to select the specific time zone appears. In the list, type the first letter of the desired
locale, and the first entry that begins with this letter will appear. Choose the time zone for the
computer, then select “OK”.
−If upgrading an existing installation, the existing time zone and locale is used.
20) If performing a clean installation, a prompt to choose a method of setting the system time
appears. Select “Using NTP” or “Manual time entry”, then select “OK”.
− If upgrading an existing installation, the existing method of setting system time is used.
15
Page 16
Citrix* XenServer* 5.5.0 Installation Guide Intel® Server Board S3420GP
− If “Using NTP” is selected, a prompt to identify the time server or servers to use appears.
Check the “NTP is configured by my DHCP server” checkbox, and the time server will be set by
DHCP. Otherwise, enter at least one NTP server name or IP address in the corresponding
fields, then select “OK”.
−If “Manual time entry” is selected, a prompt to manually-enter the time appears. The time will
be entered near the end of the installation.
Warning: Currently, XenServer* assumes the time setting for the server's BIOS is the current
time in UTC, and that the time for the VMs reflects the local time based on the time zone
offset specified.
21) At this point, the installation is ready to proceed. A message explains the installation will format
the primary disk and any other disks selected for VM storage, destroying any data that is currently
on them. Select “Install XenServer” to proceed.
22) A progress bar displays the installation progress. If setting the system date and time manually, a
dialog box appears when the progress bar reaches about 90%. Enter the information in the
corresponding fields and select “OK”.
− If installing from a CD and including support for Linux* VMs, a prompt to insert the Linux* Pack
into the disk drive appears. Eject the main disk, insert the Linux Pack disk, and close the CD
drawer. Select “OK”.
− A screen identifies the Linux Pack disk. Select “Use media” installing the Linux Pack. Another
progress bar is displays. When it reaches 100%, a completion message appears.
23) If support for Linux* VMs will not be installed, a message indicates the XenServer* host is
installed.
Note: If adding Linux* support at a later time, mount the Linux Pack installation CD or ISO image
on the XenServer host and run the “install.sh” script, located in the CD root.
24) Select “Reboot”. After the splash screen, XenServer displays xsconsole, a system configuration
console.
25) To manage the server with XenCenter* or to connect with an SSH terminal client, use the IP
address displayed in the list of management network parameters. See the Install XenCenter
section below for instructions.
26) To access a local shell from xsconsole, press the “Alt” + “F3” keys.
27) To return to xsconsole, press the “Alt” + “F1” keys.
16
Page 17
Citrix* XenServer* 5.5.0 Installation Guide -
Intel® Server Board S3420GP
Install XenCenter*
XenCenter* is a Windows* client application. XenCenter must be installed on a remote machine that
can connect to the XenServer* host through the network; it cannot run on the same machine as the
XenServer host. It can be installed and run on Windows* Server 2003*, Server 2008, XP* SP2, or
Vista*. The .NET* framework version 2.0 or above must be installed as well.
Note: The XenCenter* installation wizard can be used to install previous versions of XenCenter.
XenCenter can manage previous versions of XenServer*. Running multiple versions of XenCenter
on a single machine is supported.
To install XenCenter, perform these steps:
1) Before installing XenCenter, uninstall the previous version if one exists.
2) Insert the Base Pack CD in the drive or browse to the location where the “XenCenter.msi”
installation file was downloaded.
3) If installing from a CD:
− If Auto-play is enabled for the CD drive, the application installer launches automatically.
− If Auto-play is not enabled for the CD drive, browse to the “/client_install” CD directory and
locate the XenCenter.msi file. Double-click on the file to launch the application installer.
4) If installing from the installation “XenCenter.msi” file, double-click on the file to launch the
application installer.
5) Click “Next” on the first page of the setup wizard.
6) In the Custom Setup window, XenCenter* 4.1 is shown as a sub-feature of XenCenter 5.5.0. To
manage any XenServer 4.0 hosts, select it by clicking either “Will be installed on local hard drive” or
“Entire feature will be installed on local hard drive”. In this case, a separate XenCenter* 4.1 will also
be installed on the computer. If no XenServer 4.x hosts will be managed, leave this subfeature
unselected.
7) Click “Next” to proceed.
8) The next window allows the default “C:\Program Files\Citrix\XenCenter” destination folder to be
modified. Click “Browse” to change the default installation location, if desired. Also select whether
XenCenter* is installed so every user of the computer can access it or only the user logged into
the current profile.
9) Click “Next”.
10) In the next window, click “Install”.
11) When complete, a XenCenter* icon appears on the desktop and a XenCenter item appears in the
“All Programs” list.
Note: The installer will create a single desktop icon for XenCenter* 5.5.0 only. XenCenter 4.1
appears in the “All Programs” list on the “Start” menu installation and deployment scenarios.
12) When the installation process is complete, click “Finish” to close the setup wizard. A XenCenter*
icon will appear on the desktop and a XenCenter item will appear in the “All Programs” list.
Note: By default, XenCenter* allows usernames and passwords to be saved. To disable this:
a) Use the registry editor.
b) Navigate to the key HKEY_CURRENT_USER\Software\Citrix\XenCenter.
c) Add a key named “AllowCredentialSave” with the string value “false”..
17
Page 18
Citrix* XenServer* 5.5.0 Installation Guide Intel® Server Board S3420GP
This will cause XenCenter to no longer save usernames or passwords, and disables the Save and
Restore Connection State dialog box in XenCenter (“Tools” > “Save and Restore").
Uninstall XenCenter*
To uninstall XenCenter*, perform these steps:
Note: If XenCenter* 4.1.0 is installed along with XenCenter 5.5.0, the uninstallation process will
remove both versions.
1) Select “Control Panel” from the “Start” menu.
2) In Windows* XP* or Server 2003*, select “Add or Remove Programs”.
−In Windows* Vista* or Server 2008, select “Programs”, then select “Programs and Features”.
3) A list of programs installed on the computer is displayed. Select “XenCenter”.
4) In Windows XP or Server 2003, click the “Remove button”.
− In Windows Vista or Server 2008, select “Uninstall” from the toolbar above the list of
programs. These actions will remove the Citrix* application. When the uninstallation process is
complete, a message displays. Click “OK” to close the message box.
XenServer* Installation and Deployment Scenarios
This section describes several common installation and deployment scenarios, and details the steps
that differ between the following scenarios:
One or more XenServer* hosts with local storage.
Two or more XenServer* hosts with shared NFS storage.
Two or more XenServer* hosts with shared iSCSI storage.
XenServer* Hosts with Local Storage
The simplest XenServer* deployment is to setup a simple network of VMs running on one or more
XenServer hosts without shared storage. In this case, live relocation of VMs from one XenServer host
to another is not possible because it requires shared storage.
Requirements
One or more 64-bit x86 servers with local storage.
One or more Windows* workstations on the same network as the XenServer* hosts
Basic procedure
1) Install XenServer* host software on server(s).
2) Install XenCenter* on workstation(s).
3) Run XenCenter* and connect to XenServer* hosts.
18
Page 19
Citrix* XenServer* 5.5.0 Installation Guide -
Intel® Server Board S3420GP
XenServer* Hosts with Shared NFS Storage
Adding shared storage to the XenServer* network enables grouping of XenServer hosts into resource
pools, enabling live relocation of VMs and sharing of server resources.
Requirements
Two or more 64-bit x86 servers with local storage.
One or more Windows* workstations on the same network as the XenServer* hosts.
A server exporting a shared directory via NFS.
Note: To be part of a resource pool, the XenServer* hosts and the server(s) providing the shared
NFS storage need to have static IP addresses.
Basic procedure
1) Install XenServer* host software on server(s).
2) Install XenCenter* on workstation(s).
3) Setup the NFS server.
4) Run XenCenter* and connect to XenServer* hosts.
5) Choose one XenServer* host as a pool master and join the other XenServer hosts to its pool.
6) Create a storage repository (SR) on the NFS share at the pool level.
− For this procedure, a server running a typical Linux* distribution is assumed as the NFS server.
Consult Linux distribution documentation for more information.
Setup an NFS Share on an NFS Server
To setup an NFS share on an NFS server, perform these steps:
1) Verify the portmap daemon is installed and running with this command:
In the preceding example, runlevels 3, 4, and 5 are "on". This means at boot, for runlevels 3, 4 and
5, the portmap daemon is started automatically. If 3, 4 or 5 are "off," turn them on with the
following command:
chkconfig portmap on
2) Verify the NFS daemon is installed and running:
5) Because the shared storage is set as the pool-wide default, all future VM disks will have their disks
created on shared storage by default.
XenServer* Hosts with Shared iSCSI Storage
Adding shared storage to the XenServer* network enables XenServer hosts to be grouped into
resource pools, enabling live relocation of VMs and sharing of server resources.
Requirements
1) Two or more 64-bit x86 servers with local storage.
2) One or more Windows* workstations on the same network as the XenServer* hosts
3) A server providing a shared directory via iSCSI.
Note: To be part of a resource pool the XenServer* hosts and the server(s) providing the shared
iSCSI storage need to have static IP addresses.
20
Page 21
Citrix* XenServer* 5.5.0 Installation Guide -
Intel® Server Board S3420GP
Basic Procedure
1) Install XenServer* host software on server(s).
2) Install XenCenter* on workstation(s).
3) Prepare the iSCSI storage.
4) If necessary, enable the iSCSI device for multiple initiators.
5) Run XenCenter* and connect to XenServer* hosts.
6) Choose one XenServer* host as a pool master and join other XenServer* hosts to its pool.
7) Configure the iSCSI IQN for each XenServer* host.
8) Create an SR on the iSCSI share at the pool level.
The details of how to set up iSCSI storage differ between the various iSCSI solutions. In general,
provide an iSCSI target on the SAN for the VM storage, then configure XenServer* hosts to be able to
see and connect to it. This is done by providing a valid iSCSI Qualified Name (IQN) to the iSCSI target
and to the iSCSCI initiator on each XenServer* host.
Prepare the iSCSI Storage
To prepare the iSCSI storage, perform these steps:
1) Assign a virtual storage volume on the iSCSI SAN for VM storage.
2) Create IQNs on the SAN for each XenServer* host using the storage.
Use either XenCenter* or the CLI to configure the IQN for each XenServer* host and to create the SR.
The following describes using the CLI. See the XenServer Help menu for details about how to use
XenCenter* to configure the IQN.
Warning: When using the XenCenter* to create SRs for iSCSI and NetApp* storage, any existing
contents of the volume will destroyed.
Configure the iSCSI IQN for Each XenServer* Host via the CLI
To configure the iSCSI IQN for each XenServer* host via the CLI, perform these steps:
Now that the shared storage is set as the “pool-wide” default, all future VMs will have their disks
created on shared storage by default.
Upgrade, Update, or Reinstall XenServer*
This section explains how to upgrade from an earlier version, update (apply minor update patches), or
freshen (reinstall the same version) XenServer* installation.
Prepare to Upgrade XenServer* Hosts
Before performing maintenance operations on a XenServer* host that is part of a resource pool,
disable it (prevents any VMs from starting on it), then migrate its VMs to another XenServer host in
the pool. This can be accomplished by placing the XenServer host into Maintenance Mode using
XenCenter*. See the XenCenter Help menu for details.
To prepare a pooled XenServer* host for maintenance operations via the CLI, perform these steps:
1) Use this command:
xe host evacuate uuid=<xenserver_host_uuid>
This will disable the XenServer* host and migrate any running VMs to other XenServer hosts in
the pool.
2) Perform the desired maintenance operation.
3) Once the maintenance operation is completed, enable the XenServer* host:
xe host-enable
4) Restart any halted VMs and/or resume any suspended VMs.
22
Page 23
Citrix* XenServer* 5.5.0 Installation Guide -
Intel® Server Board S3420GP
Before performing maintenance operations on a XenServer* host that is not part of a resource pool,
disable it (prevents any VMs from starting on it), then either shutdown or suspend its VMs.
Warning: Any suspended VM with a CD drive attached (with the Tools ISO or a physical CD in the
local physical drive, for example) cannot be resumed after performing an upgrade. To return a
suspended VM to a usable state, perform a "Force Shutdown" on it, then restart it.
To prepare an unpooled XenServer host for upgrade via the CLI, perform these steps:
1) Disable the XenServer* host with this command:
xe host-disable
2) Shut down or suspend any running VMs with the
xe vm-shutdown
or
xe vm-suspend
commands. If suspending any VMs, verify no CDs are attached to them.
3) Perform the desired maintenance operation.
4) Once the maintenance operation is completed, enable the XenServer* host with this command:
xe host-enable
5) Restart any halted VMs and/or resume any suspended VMs.
Apply XenServer* Updates
Between releases of XenServer* software, Citrix* occasionally releases updates to the software.
These updates typically contain accumulated “bug” fixes and feature improvements. When an update
is released, it is made accessible on the Internet, and an email announcement is sent to all XenServer
customers.
Once downloaded, updates can be applied most readily via XenCenter*, but can also be applied using
the CLI. Updates are applied through the Manage Updates dialog box, in the “pool” menu. See the
“XenCenter Help” menu for details.
Updates sometimes involve steps that must be performed after the update is applied, such as
requiring the XenAPI* agent to restart. Whenever possible, updates can be applied without
interruption, but in some cases they may require XenServer* host or VM restarts. In cases where a
XenServer host restart is required, avoid downtime of virtual machines in a pooled environment by
applying the update to each server in turn, migrating VMs away from each server as the update is
applied. XenCenter* can take care of this update sequence automatically via the Manage Updates
feature. If using the CLI, do this manually using the “host-evacuate” command.
If using the CLI to perform the update, prepare XenServer* hosts to be updated with the procedures in
the Prepare to Upgrade XenServer* Hosts section on page 22. If using XenCenter*, this happens
automatically.
23
Page 24
Citrix* XenServer* 5.5.0 Installation Guide Intel® Server Board S3420GP
Apply Updates with the CLI
To apply updates via the CLI, perform these steps:
1) The update must be uploaded to the pool or server it will be applied to. This will assign a UUID
(identifier) to the update, and information about servers it is applied to will be tracked.
2) Once an update is uploaded to a pool or server, use the
patch-list
and
patch-param-list
commands to view information about the update.
3) Apply the update. It is recommended the
patch-pool-apply
command be used to do this. The update will apply to all servers in the pool. Alternatively, the
patchapply
command may be used to apply the update to one server in a pool. This may be useful when
applying the update and then restarting individual servers in the pool. Pools should not be left in
an inconsistent update state (where updates are installed on some servers and not on others).
Using the CLI procedures below require a basic knowledge of the “xe” tool. For information about
this, see the Administrator's Guide.
The update procedure is essentially the same for a single server or a pool scenario:
For a pooled scenario the update must be applied to all servers in the pool. Use the
patch-pool-apply
command.
For a single server, apply the
patchapply
command once for each host. These procedures are described below.
Apply Updates to XenServer* Host or Pool Using the CLI
Follow these steps to apply updates to a XenServer* host or to a XenServer host pool using the CLI:
1) Download the update to a local directory. Note the path to the downloaded update file. It is also
possible to download the update directly to an appropriate location on the server, e.g., “/root”,
using standard Linux* commands, but it is usually best to download it to a remote client.
2) Upload the update to the server or pool. An example CLI command to do this is:
Here, the “-s”, “-u”, and “-pw” options refer to the server, the username (usually root), and the
password. These would be omitted if running the command directly from the XenServer* host
console.
24
Page 25
Citrix* XenServer* 5.5.0 Installation Guide -
Intel® Server Board S3420GP
3) Once the command in step 2 is executed, the UUID of the uploaded update is given. This UUID will
be used to specify the applied update.
4) Follow the instructions for the update before continuing, in particular any information about
whether VMs should be moved away from the server or if the server should be restarted after
applying the update. It is recommended appropriate backup measures be taken before making
modifications to system software. To automatically move VMs to other servers, use the “hostevacuate” CLI command.
5) Apply the update to the pool. The following command may be used to do this:
7) Verify the update is applied with the “patch-list” command again. The “hosts“ field should contain
the host UUID.
After an update is applied to a XenServer* host, a small file containing the same information stored on
the master from the “xe patch-upload” command is written to a sub-directory of the machine's patch
directory. This enables XenServer hosts, later ejected from the pool, to repopulate their databases with
information about applied updates. To save space on the master, large updates can be deleted from
disk with the “xe patch-clean” command. The update information stored in the master's database is
always retained. These updates can be uploaded again with the “xe patch-upload”.
Reinstall the Same XenServer* Version
This section describes how to "freshen" or reinstall the current version of the XenServer* host over an
existing installation of XenServer host 5.5.0,and preserve settings on VMs.
Warning: When reinstalling the host, any custom RPMs installed on the XenServer* host control
domain are not preserved. If any XenServer hotfixes are installed on the server, do not reinstall
the original version; this is not supported
To reinstall XenServer* host from version 5.5.0, perform these steps:
1) Perform an orderly shutdown on the VMs hosted on the XenServer* host. If VMs are in a
suspended state, resume them, then perform an orderly shutdown on them as well. To shut down
all VMs automatically, type “service xapi-domains stop” in the control domain terminal.
2) Reboot the XenServer* host, then boot from the Installation CD.
3) The installation script will identify the version and prompt to choose to reinstall over the existing
installation and preserve VMs. Select “OK” to proceed with the installation.
4) Follow the rest of the installation procedure in the Install the XenServer* Host section on page 12.
5) Run XenCenter* and connect to the upgraded XenServer* host.
25
Page 26
Citrix* XenServer* 5.5.0 Installation Guide Intel® Server Board S3420GP
Backup and Restore XenServer* Hosts and VMs
It is recommended that, whenever possible, the installed state of XenServer* hosts be unaltered. That
is, do not install any additional packages or start additional services on XenServer hosts, treating them
as if they are appliances. The best way to restore is to re-install XenServer host software from the
installation media. If multiple XenServer hosts are in play, the best approach is to configure a PXE boot
server and appropriate answerfiles for this purpose. See Appendix B: Maintenance Procedures on page
30.
For VMs, the best approach is to install backup agents on them, as if they were standard physical
servers. For Windows* VMs, as of this release, CA* BrightStor ARCserve Backup*, and Symantec*
NetBackup* and Backup Exec* were tested. For more information about tested backup tools, best
practices, and backups in general, see the Citrix Knowledge Base.
Backup Virtual Machine Metadata
XenServer* hosts use a “per-host” database to store metadata about VMs and associated resources
such as storage and networking. When combined with storage repositories, this database forms a
complete view of all VMs available across the pool. It is important to understand how to backup this
database in order to recover from physical hardware failure and other undesireable scenarios. This
section describes how to backup metadata for single-host installations, and for more complex pool
setups.
Backup Single Host Installations
The CLI must be used to backup the pool database. To obtain a consistent pool metadata backup file:
1) Run this command:
xe pool-dump-database
against the XenServer* host and archive the resulting file. The backup file will contain sensitive
authentication information about the pool; ensure it is securely stored.
2) To restore the pool database, use this command:
xe pool-restore-database
from a previous dump file. If the XenServer* host is inoperable, perform a fresh install, and then run
the “xe pool-restore-database” command against the newly installed XenServer host.
After a restoration of the pool database, some VMs may be registered as being “suspended”, but if the
storage repository with their suspended memory state (defined in the “[suspend-VDIuuid]” field) was a
local SR, it will no longer be available because the host is reinstalled.
26
Page 27
Citrix* XenServer* 5.5.0 Installation Guide -
Intel® Server Board S3420GP
To reset these VMs back to the halted state so they can be started again, use the
xe vmshutdown vm=vm_name -force
command or use the
xe vm-reset-powerstate vm=vm_name -force
command.
Note: XenServer* hosts restored using this method will have their UUIDs preserved. If a different
physical machine is restored while the original XenServer host is still running, there will be a UUID
clash. The main observable effect of this clash is that XenCenter* will not to connect to the
second XenServer host. Pool database backup is not the recommended mechanism for cloning
physical hosts. Instead, use the automated installation support. See Appendix B: Maintenance
Procedures on page 30.
Backup Pooled Installations
In a pool scenario, the master host provides an authoritative database synchronously mirrored by the
member hosts in the pool. This provides a degree of built-in redundancy to a pool; the master can be
replaced by any member, because each of them has an accurate version of the pool database. Refer to
the XenServer Administrator's Guide for more information on how to transition a member to become a
master host. This level of protection may not be sufficient, for example, if the shared storage
containing the VM data is backed-up in multiple sites, but the local server storage (containing the pool
metadata) is not. To fully recreate a pool given only a set of shared storage, first backup the “xe pooldump-database” against the master host, and archive the file.
Restore the Backup on a New Set of Hosts
To restore a backup on a new set of hosts, follow these steps:
1) Install a new set of XenServer* hosts from the installation media or via PXE.
2) Use the “xe pool-restore-database” on the host designated to be the new master.
3) Run the “xe host-forget “command on the new master to remove the old member machines.
4) Use the “xe pool-join” command on the member hosts to connect them to the new cluster.
Refer to the Coping with Machine Failures section of the XenServer Administrator's Guide for specific
restoration scenarios.
27
Page 28
Citrix* XenServer* 5.5.0 Installation Guide Intel® Server Board S3420GP
XenServer* Hosts Backup Options
This section describes the XenServer* host control domain backup and restore procedures. These
procedures do not backup the storage repositories that house the VMs; only the privileged control
domain that runs Xen* and the XenServer agent.
Because the privileged control domain is best left installed and not customized with other packages, it
is recommended a PXE boot environment be set-up to perform a clean and new installation from the
XenServer media as a recovery strategy. In many cases, it is not necessary to backup the control
domain, but to only save the pool metadata. See the Backup Virtual Machine Metadata section on
page 26. Backing-up the pool metadata is the primary option.
Another approach is to run the XenServer* installation twice, choosing to backup the existing
installation when prompted. This will create a clean copy of the newly-installed control domain that
can later be restored, if necessary, by using the installation CD and choosing the “Restore” option.
Another option is using the “xe” commands:
host-backup
and
host-restore
The “xe host-backup” command archives the active partition to a specified file, and the “xe host-
restore” command extracts an archive created by “xe host-backup” over the host's currently inactive
disk partition. This partition can then be activated by performing these steps:
1) Boot from the installation CD.
2) Choose the “Restore” option.
After completing the above steps and rebooting the host, ensure the VM meta-data is restored to a
consistent state. This can be achived by running “xe pool-restore-database” on “/var/backup/pooldatabase-${DATE}”. This file is created by “xe host-backup”, using “xe pool-dump-database” prior to
archiving the running file system. This creates a snapshot of a consistent state of the VM metadata.
Backup a XenServer* Host
On a remote host with adequate disk space, run this command:
This restores the compressed image back to the hard disk of the XenServer host where the
command is run (not the host where “filename” resides). The complete backed-up state is not
restored. The restore command only unpacks the compressed backup file and restores it to its
normal form. It is written to another partition (“/dev/sda2”) and does not overwrite the current
version of the file system.
2) To use the complete restored version of the root file system, reboot the XenServer host using the
XenServer installation CD and select the “Restore from backup” option.
3) After the restore from backup is completed, reboot the XenServer host and it will start from the
Note: Restoring from a backup described above does not destroy the backup partition.
Restart a Crashed XenServer* Host
If a XenServer* host crashes and is not accessible, use the XenServer installation CD to perform an
upgrade install. See the Upgrade, Update, or Reinstall XenServer* section on page 22. When the
upgrade is complete, reboot the machine and make sure the host is accessible with XenCenter* or
remote CLI. Then proceed with the Restore a Running XenServer* Host procedure in the previous
section.
Backup VMs
Backup VMs using standard backup tools, running individually on them. For Windows* VMs, CA*
BrightStor ARCserve Backup* was validated.
Appendix A: Troubleshooting
If odd behavior crashes, or other issues occur during installation, this section is intended to help solve
these problems. It also describes where logs and other information are located to help a Citrix*
Solution Provider and Citrix* Support track and resolve the issue.
Note: It is recommended the troubleshooting information in this chapter be observed only with the
guidance of a Citrix* Solution Provider or Citrix* Support.
Citrix* provides two forms of support:
Receive free self-help support via the support site, Free Web-based resources include product
documentation, a Knowledge Base, and discussion forums.
Purchase support services and directly submit requests by filing an online Support Case.
The XenServer* host installation CD runs Linux*, so most standard Linux commands can be used to
diagnose installation problems. There are three virtual terminals available during installation, which
display the installation menu, an interactive console and an event log, respectively. Use the “ALT” +
29
Page 30
Citrix* XenServer* 5.5.0 Installation Guide Intel® Server Board S3420GP
“F1”-“F3” keys to toggle between the virtual terminals. Basic items in the interactive terminal can be
reviewed, such as:
Fdisk: Lists all disks that can be seen as a result of the loaded storage device drivers. If a particular
device driver did not load, for example, the driver for a RAID card, the disks attached to that card
will not appear in the output from the “fdisk” command.
Ifconfig: Shows the network configuration of physical NICs, including their IP addresses, netmasks,
and gateway.
Ping: Can be used to verify network connectivity from the XenServer* host to a remote IP address
and vice-versa.
Use the two additional virtual terminals only with the help of a Citrix Solution Provider. Installation logs
are written to “/install/tmp/”
Appendix B: Maintenance Procedures
This appendix explains how to setup a TFTP server to enable PXE booting of XenServer* host
installations. It also explains how to use an XML answerfile, which enables unattended installations.
Setup the PXE Boot Environment
To create a PXE environment, the following items are required:
A TFTP server to enable PXE booting.
A DHCP server to provide IP addresses to the systems that are going to PXE-boot.
An NFS, FTP, or HTTP server to house the installation files.
These can all co-exist on the same server or be distributed on different servers on the network.
Additionally, each system to PXE-boot and to install the XenServer* on needs a PXE boot-enabled
Ethernet card.
Setup a TFTP Server for PXE-Booting
The following steps assume the Linux* server or servers have RPM support. Perform these steps to
setup a TFTP server for PXE-booting:
1) TFTP requires SYSLINUX 3.11 or above boot loaders. SYSLINUX is a collection of boot loaders for
the Linux* operating system which operates on Linux ext2 and ext3 file systems, MS-DOS FA file
systems, network servers using PXE firmware, and CD-ROMs. Verify SYSLINUX version 3.11 or
above is installed on the target system with the command:
#rpm -q syslinux
2) If a pre-SYSLINUX 3.11version is installed, download an updated version from
ftp://ftp.kernel.org/pub/linux/utils/boot/syslinux/RPMS/i386/, then install it with the command:
#rpm -Uvh syslinux.-.rpm
3) Verify the TFTP server package is installed with this command:
#rpm -q tftp-server
30
Page 31
Citrix* XenServer* 5.5.0 Installation Guide -
Intel® Server Board S3420GP
If it is not, use this command:
system-config-packages
and install.
4) Edit the “/etc/xinetd.d/tftp” file to change the line
disable = yes
to
disable = no
5) Restart the xinetd service, which manages tftp:
# service xinetd restart
6) Make a directory inside “/tftpboot” and name it “xenserver”.
7) Copy the “mboot.c32” and “pxelinux.0” files from “/usr/lib/syslinux” to the “/tftboot” directory.
8) Copy the “install.img”, “vmlinuz”, and “xen.gz” files from the Base Pack CD (found in the root of the
Base Pack CD, and in its “/boot” directory, respectively) and place them in “/tftpboot/xenserver”.
9) Make a directory named “pxelinux.cfg”inside “/tftboot”and create a file named “default”. The file
contents depend on how the PXE-boot environment is configured. For example, a configuration
file may have contents similar to the following:
(In the example above, “path/to/boot/directory” is the directory where “install.img”, “vmlinuz”, and
“xen.gz” files were copied in the previous step).
Note: 1. The back-slashes at the ends of lines in the example PXE configuration files shown above
denote continuation of lines; do not include them in the PXE configuration file.
2. Note that the three hyphens in the examples are necessary parts of the “mboot.c32” loader
syntax; not including them will cause PXE-boot attempts to fail.
10) The configuration depicted in step 9 will start an installation on any machine that boots from the
same server. Manually respond to prompts to complete the installation.
11) To launch an unattended installation, using the answerfile at the specified URL, use a
Note: The above examples show how to configure the installer to run on the tty0 physical
console. It is recommended the “console=” entry of the console be used for the installation as the
last entry on the line. In the examples above, to install over serial, the two entries would be
reversed, as console=tty0, console=ttyS0,115200n8
31
Page 32
Citrix* XenServer* 5.5.0 Installation Guide Intel® Server Board S3420GP
For details on creating an answerfile for unattended installation, see the Create an Answerfile for
Unattended PXE Installation section on page 33. For more information on PXE configuration file
syntax, see the SYSLINUX website. Refer to the server operating system manual for details for the
specific operating system. The information here is a guide that can be used for Red Hat*, Fedora*, and
other RPM-based distributions..
Setup a DHCP Server
Perform these steps to setup a DHCP server:
1) On the server used for DHCP, verify DHCP is installed by issuing the command:
# rpm -qa dhcp
If DHCP is not installed, install it using “system-config-packages”.
2) Configure the DHCP server. Refer to article 4221 in the Red Hat* Knowledgebase for details.
#rpm -q tftp-server
3) Add these lines to the end of the existing “dhcpd.conf” file at the TFTP server address line:
allow booting;
allow bootp;
class "pxeclients" {
match if substring(option vendor-class-identifier, 0,
Follow these steps to setup the installation media host:
1) On the server where the installation files are stored, copy the contents of the packages directories
from the Base Pack CD to a location where they are exported by HTTP, FTP, or NFS. For example,
make a directory in the document root of a Web server named “XenServer_5.5.0”, then copy the
“packages.main” directory from the Base Pack disk to “XenServer_5.5.0/packages.main”.
2) If Linux* support is also desired, copy packages.linux from the Linux Pack disk to
“XenServer_5.5.0/packages.linux”. This structure allows both packages to be installed by having
the answerfile's source element contain the enclosing “XenServer_5.5.0”directory or install only
the base pack (no support for Linux* VMs) by inserting the path to
“XenServer_5.5.0/packages.main”.
For example, to install both packages from the Web server “http://pxehost.example.com” where the
packages are in the directories mentioned above relative to the server's document root, the answerfile
would contain this source element:
The name of the storage device where the “Dom0” should be installed,
equivalent to the choice made in the “Select Primary Disk” step of the
interactive installation process. Attributes:
Specify a “gueststorage” attribute with possible values “yes” and “no”. For
example: <primary-disk gueststorage="no">sda</primary-disk>
If this attribute is not specified, the default is “yes”. If “no” is specified, it is
possible to automate an installation scenario where no storage repository is
created, if, in addition, guest-disk keys are not specified.
Y
<guest-disk>
The name of a storage device used for storing guests. Use one of these
elements for each extra disk.
N
<keymap>
The name of the keymap to use during installation.
<keymap>us</keymap>
Y
Intel® Server Board S3420GP
or to install the basic pack only and skip Linux* support, issue this command:
Follow these steps to prepare the destination system:
1) Start the system and enter the Boot Menu (the “F12” key in most BIOSs).
2) Select to boot from the Ethernet card.
The system should then PXE-boot from the installation source setup, and the installation script will
commence. If an answerfile is present, the installation can proceed unattended.
Create an Answerfile for Unattended PXE Installation
To perform unattended installations, create an XML answerfile.
Here is an example answerfile:
All nodes should be within a root node named “installation”.
The following table is a summary of the elements of the above answerfile example. All values should
be PCDATA within the nodes, unless otherwise stated. Required elements are indicated:
33
Page 34
Citrix* XenServer* 5.5.0 Installation Guide -
Element
Description
Required
<root-password>
The desired root password for the XenServer* host.
Y
<source>
Where the packages should be installed from.
Attributes:
type: url, nfs, or local
If local, leave the PCDATA empty. For example,
The single network interface to be used as the host administration interface.
Attributes:
proto: dhcp or static
name: eth0 for example.
Children:
<ip>: The IP address, if proto="static"
<subnet-mask>: The subnet mask, if proto="static"
<gateway>: The gateway, if proto="static"
All three child elements are required if proto="static"
N
<timezone>
In the format used by the TZ variable, e.g., “Europe/London” or
“America/Los_Angeles”.
Y
<nameserver>
The name of a nameserver. Use one of these elements for each nameserver to
nominate.
N
<hostname>
Specify if a hostname is to be set manually.
N
<bootloader>
Specify which bootloader to install for startup time. Only change this if there are
booting problems. Currently either “grub” (the default) or “extlinux”.
N
Intel® Server Board S3420GP
Table 5 – Elements of an Answerfile
Automated upgrades are also possible by varying the answerfile in the following manner:
1) Set the mode attribute of the installation element to “reinstall”.
2) Specify the disk the existing installation is on with the “existing-installation” element.
3) Leave the “primary-disk” and “guest-disk” elements unspecified. For example:
The repository format described here should be used by installation sources and driver disks. Given a
path, the presence of a Citrix* installation media repository is determined by checking for the
existence of valid “XS-REPOSITORY” and “XS-PACKAGES” files. From a given base, the base is checked,
along with the packages, “packages.main”, “packages.linux”, and “packages.site” subdirectories. A typical
In the first example, given a path to “xs-installation”, the XenServer* installer will detect the presence
of three repositories. In the second example, “xs-driver-disk”, a single repository will be detected.
Installation Media Repository Metadata
The “XS-REPOSITORY” file is used to describe a Citrix*-format installation media repository. It has four
fields, separated by newlines:
Repository ID: Repository IDs are alphanumeric strings that provide a machine identifier for the
repository. They are unique within a target product and version. Best practice is to use the form:
vendor:repository
− Citrix* repositories begin with “xs” (for example, “xs:main”).
− Custom repositories begin with “custom” (“custom:my-repo”).
− Third-party add-ons should be identified by using an appropriate vendor string. This will help
avoid name clashes.
Repository name: Repository names are presented to the user, therefore, identify the repository
string with a familiar name so the user can identify it and install from it.
Intended target product: The intended target product is “XenServer”.
35
Page 36
Citrix* XenServer* 5.5.0 Installation Guide Intel® Server Board S3420GP
Intended target version: The intended target version is “5.5.0-build”.
Package Metadata
The “XS-PACKAGES” file describes the packages in a repository, one line per package. Fields are
separated by spaces. There are three types of packages:
tbz2 packages: Bzipped tarballs extracted onto the root file system.
Driver packages: Kernel modules loaded by the installer at runtime, and installed into the file
system.
Firmware packages: Available during the installation so they can be loaded by udev in addition to
being installed into the target file system.
Note: Firmware loading support is currently limited; this will be addressed in a future release.
The first three fields listed above are mandatory. The package type (identified above) dictates the
contents of the subsequent fields. If the type is “tbz2”, the subsequent fields are:
If a driver disk is used, the following actions occur for any “tbz2” packages on it:
The packages are installed to the target.
A copy of the repository is made so the drivers are loaded at runtime.
The copy is placed into memory.
If constructing a driver disk that also includes “user-space” tools, and if these result in a large
repository, it is best to split it into two repositories and require people using the “packages.site”
mechanism to install add-ons. Alternatively, provide a “post-install” script to install them after the fact.
37
Page 38
Citrix* XenServer* 5.5.0 Installation Guide -
Name
Default
Description
memory-actual
209715200
The actual amount of memory current available for use by the VM.
memory-target
209715200
The target amount of memory set by using “xe vm-memory- target-set”.
memory-static-max
790102016
The maximum possible physical memory.
memory-dynamic-max
790102016
The desired maximum memory to be made available.
memory-dynamic-min
209715200
The desired minimum memory to be made available.
memory-static-min
209715200
The Minimum possible physical memory.
Intel® Server Board S3420GP
Appendix C: Xen Memory Usage
When calculating the memory footprint of a Xen* host, there are two aspects to consider:
The memory consumed by the Xen* hypervisor.
The memory consumed by the host's control domain. The control domain is a privileged VM that
provides low-level services to other VMs, such as access to physical devices. It also runs the
management tool stack.
Set Control Domain Memory
If the control domain requires more allocated memory, this can be done with the Xen* CLI.
Use the
xe vm-memory-target-set
command to set the amount of memory available to the host hypervisor.
Use the
xe vm-memory-target-wait
command to verify the control domain has attained the requested memory target specified with
the last use of the “xe vm-memory-target-set”command. The “xe vm-memory-target-wait” will
not return until the memory target is reached.
The following fields on a VM define how much memory will be allocated:
Table 6 – Memory Allocation Using CLI Commands
Dynamic memory values must be within the boundaries set by the static memory values. Additionally
the target memory must fall in the range between the dynamic memory values.
Note: The amount of memory reported in XenCenter* in the General tab in the Xen* field may
exceed the values set using this mechanism. This is because the amount reported includes the
memory used by the control domain, the hypervisor itself, and the crash kernel. The amount of
memory used by the hypervisor will be larger for hosts with more memory.
To determine how much host memory is actually available assign to VMs, obtain the value of the
memory-free field of the host, then use the
vm-compute-maximum-memory
command to determine the actual amount of free memory that can be allocated to the VM, for
example:
Please contact the vendor for any support issues with application software or third party hardware
used in recipe configurations. Intel customer support does not provide support for any or third party
software or hardware-related issues and calls received by the Intel support site will be referred to the
appropriate vendor.
Vendor support information
Intel hardware support information
When you choose a validated server solution available
through the Intel® Enabled Server Acceleration Alliance,
you choose a solution that delivers the highest standards
for quality and interoperability. Through this collaborative
alliance, Intel Corporation has teamed with other industry
leaders to provide you with server solutions that meet a
range of business needs. Intel® ESAA provides a process to
streamline deployment and implementation so you can
focus on growing your business. For more information
about the Intel® ESAA program, visit
www.intel.com/go/esaa.
39
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.