Citrix XenServer ® 5.6 Service Pack 2 Installation Guide

Copyright © 2011 Citrix Systems. Inc. All Rights Reserved.

Version: 5.6 Service Pack 2

Citrix, Inc.

851 West Cypress Creek Road

Fort Lauderdale, FL 33309

United States of America

Disclaimers . This document is furnished "AS IS." Citrix, Inc. disclaims all warranties regarding the contents of this document, including, but not limited to, implied warranties of merchantability and fitness for any particular purpose. This document may contain technical or other inaccuracies or typographical errors. Citrix, Inc. reserves the right to revise the information in this document at any time without notice. This document and the software described in this document constitute confidential information of Citrix, Inc. and its licensors, and are furnished under a license from Citrix, Inc.

Citrix Systems, Inc., the Citrix logo, Citrix XenServer and Citrix XenCenter, are trademarks of Citrix Systems, Inc. and/or one or more of its subsidiaries, and may be registered in the United States Patent and Trademark Office and in other countries. All other trademarks and registered trademarks are property of their respective owners.

Trademarks. Citrix®

XenServer ®

XenCenter ®

Tuesday, 28 June 2011


Contents

1. Welcome
1.1. About This Document
1.2. Introducing XenServer
1.2.1. Benefits of Using XenServer
1.2.2. Administering XenServer
1.2.3. XenServer Editions
1.3. XenServer Documentation
2. System Requirements
2.1. System Requirements
2.1.1. XenServer Host System Requirements
2.1.2. XenCenter System Requirements
2.1.3. Supported Guest Operating Systems
3. Installing XenServer and XenCenter
3.1. Installation Media and Methods
3.2. Installing the XenServer Host
3.3. Installing XenCenter
3.4. Connecting XenCenter to the XenServer Host
4. Installation and Deployment Scenarios
4.1. XenServer Hosts with Local Storage
4.2. Pools of XenServer Hosts with Shared Storage
4.2.1. XenServer Hosts with Shared NFS Storage
4.2.2. XenServer Hosts with Shared iSCSI Storage
5. Upgrading XenServer
5.1. Upgrading a Single XenServer Host
5.1.1. Before You Upgrade a Single XenServer Host
5.1.2. Upgrading a Single XenServer Host
5.2. Upgrading a Pool of XenServer Hosts (Rolling Pool Upgrades)
5.2.1. Before You Upgrade a Pool of XenServer Hosts
5.2.2. Upgrading a Pool of XenServer Hosts
5.3. Upgrading LVM Storage from XenServer 5.0 or Earlier
6. XenServer and IntelliCache
6.1. IntelliCache Deployment
6.1.1. Enabling on Host Installation
6.1.2. Converting an Existing Host to Use Thin Provisioning
6.1.3. VM Boot Behaviour
6.1.4. Implementation Details and Troubleshooting
7. Applying Updates and Hotfixes to XenServer
7.1. Before You Apply an Update or Hotfix
7.2. Updating Individual XenServer Hosts
7.3. Updating a Pool of XenServer Hosts
8. Licensing XenServer
8.1. Activating a Free XenServer Product
8.2. Licensing XenServer Editions
8.3. Additional Licensing Information
8.3.1. Licensing Expiration and Grace Period
8.3.2. Mixed Pools
A. Troubleshooting
B. Boot From SAN Environments
C. PXE Boot Installations
C.1. Configuring your PXE Environment for XenServer Installation
C.2. Creating an answer file for unattended PXE installation

Chapter 1. Welcome

1.1. About This Document

This document is an installation guide for Citrix XenServer®, the complete server virtualization platform from Citrix®. It contains procedures to guide you through the installation, configuration, and initial operation of XenServer. This document also contains information about troubleshooting problems that might occur during installation and points you to additional resources.

This document is primarily aimed at system administrators who wish to set up XenServer hosts on physical servers.

1.2. Introducing XenServer

Citrix XenServer® is the complete server virtualization platform from Citrix®. The XenServer package contains all you need to create and manage a deployment of virtual x86 computers running on Xen®, the open-source paravirtualizing hypervisor with near-native performance. XenServer is optimized for both Windows and Linux virtual servers.

XenServer runs directly on server hardware without requiring an underlying operating system, which results in an efficient and scalable system. XenServer works by abstracting elements from the physical machine (such as hard drives, resources and ports) and allocating them to the virtual machines running on it.

A virtual machine (VM) is a computer composed entirely of software that can run its own operating system and applications as if it were a physical computer. A VM behaves exactly like a physical computer and contains its own virtual (software-based) CPU, RAM, hard disk and network interface card (NIC).

XenServer lets you create VMs, take VM disk snapshots and manage VM workloads. For a comprehensive list of major XenServer features and editions, visit www.citrix.com/xenserver.

1.2.1. Benefits of Using XenServer

Using XenServer reduces costs by:

  • Consolidating multiple VMs onto physical servers

  • Reducing the number of separate disk images that need to be managed

  • Allowing for easy integration with existing networking and storage infrastructures

Using XenServer increases flexibility by:

  • Allowing you to schedule zero downtime maintenance by using XenMotion to live migrate VMs between XenServer hosts

  • Increasing availability of VMs by using High Availability to configure policies that restart VMs on another XenServer host if one fails

  • Increasing portability of VM images, as one VM image will work on a range of deployment infrastructures

1.2.2. Administering XenServer

There are two methods by which to administer XenServer: XenCenter and the XenServer Command-Line Interface (CLI).

XenCenter is a graphical, Windows-based user interface. XenCenter allows you to manage XenServer hosts, pools and shared storage, and to deploy, manage and monitor VMs from your Windows desktop machine.

The XenCenter Help is a great resource for getting started with XenCenter.

The XenServer Command-line Interface (CLI) allows you to administer XenServer using the Linux-based xe commands.

For a comprehensive list of xe commands and descriptions, see the XenServer Administrator's Guide.

1.2.3. XenServer Editions

The features available in XenServer depend on the edition. The four editions of XenServer are:

  • Citrix XenServer (Free): Proven virtualization platform that delivers uncompromised performance, scale, and flexibility at no cost.

  • Citrix XenServer Advanced Edition: Key high availability and advanced management tools that take virtual infrastructure to the next level.

  • Citrix XenServer Enterprise Edition: Essential integration and optimization capabilities for production deployments of virtual machines.

  • Citrix XenServer Platinum Edition: Advanced automation and cloud computing features for enterprise-wide virtual environments.

For more information about how the XenServer edition affects the features available, visit www.citrix.com/xenserver.

1.3. XenServer Documentation

XenServer documentation shipped with this release includes:

  • Release Notes cover known issues that affect this release.

  • XenServer Quick Start Guide provides an introduction for new users to the XenServer environment and components. This guide steps through the installation and configuration essentials to get XenServer and the XenCenter management console up and running quickly. After installation, it demonstrates how to create a Windows VM, VM template and pool of XenServer hosts. It introduces basic administrative tasks and advanced features, such as shared storage, VM snapshots and XenMotion live migration.

  • XenServer Installation Guide steps through the installation, configuration and initial operation of XenServer and the XenCenter management console.

  • XenServer Virtual Machine Installation Guide describes how to install Windows and Linux VMs within a XenServer environment. This guide explains how to create new VMs from installation media, from VM templates included in the XenServer package and from existing physical machines (P2V). It explains how to import disk images and how to import and export appliances.

  • XenServer Administrator's Guide gives an in-depth description of the tasks involved in configuring a XenServer deployment, including setting up storage, networking and pools. It describes how to administer XenServer using the xe Command Line Interface.

  • vSwitch Controller User Guide is a comprehensive user guide to the vSwitch and Controller for XenServer.

  • Supplemental Packs and the DDK introduces the XenServer Driver Development Kit, which can be used to modify and extend the functionality of XenServer.

  • XenServer Software Development Kit Guide presents an overview of the XenServer SDK. It includes code samples that demonstrate how to write applications that interface with XenServer hosts.

  • XenAPI Specification is a reference guide for programmers to the XenServer API.

For additional resources, visit the Citrix Knowledge Center.

Chapter 2. System Requirements

2.1. System Requirements

XenServer requires at least two separate physical x86 computers: one to be the XenServer host and the other to run the XenCenter application. The XenServer host computer is dedicated entirely to the task of running XenServer — hosting VMs — and is not used for other applications. The computer that runs XenCenter can be any general-purpose Windows computer that satisfies the hardware requirements and can be used to run other applications too.

2.1.1. XenServer Host System Requirements

While XenServer will generally be deployed on server-class hardware, XenServer is also compatible with many models of workstations and laptops. For a comprehensive hardware compatibility list, see www.citrix.com/ready/hcl. For any further questions regarding the hardware compatibility list, e-mail xenserver.hcl@citrix.com. The following describes the recommended XenServer hardware specifications.

The XenServer host should be a 64-bit x86 server-class machine devoted to hosting VMs. This machine should run an optimized and hardened Linux partition with a Xen-enabled kernel which controls the interaction between the virtualized devices seen by VMs and the physical hardware.

XenServer can make use of:

  • up to 512 GB of RAM

  • up to 16 NICs

  • up to 64 logical processors

The system requirements for the XenServer host are:

CPUsOne 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 or AMD-V 64-bit x86-based system with one or more CPU(s) is required.

[Note]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 your BIOS might have virtualization support disabled. Consult your BIOS documentation for more details.

To support VMs running supported paravirtualized Linux, a standard 64-bit x86-based system with one or more CPU(s) is required.

RAM 2 GB minimum, 4 GB or more recommended
Disk space

Locally attached storage (PATA, SATA, SCSI) with 16 GB of disk space minimum, 60 GB of disk space recommended, or SAN via HBA (not via software) if installing with multipath boot from SAN (see www.citrix.com/ready/hcl for a detailed list of compatible storage solutions).

Product installation creates two 4 GB partitions for the XenServer host control domain.

Network

100 Mbit/s or faster NIC. One or more gigabit NIC(s) is recommended for faster P2V and export/import data transfers and VM live migration.

For redundancy, multiple NICs are recommended. The configuration of NICs will differ depending on the storage type. See vendor documentation for details.

2.1.2. XenCenter System Requirements

The remote XenCenter application for managing the XenServer host can be installed on any Windows Server 2003, Windows Server 2008, Windows 7, Windows XP or Windows Vista machine.

The system requirements for XenCenter are:

Operating systemWindows 7, Windows XP, Windows Server 2003, Windows Server 2008, or Windows Vista SP1 and SP2
.NET frameworkVersion 2.0 service pack 1 or later
CPU Speed750 MHz minimum, 1 GHz or faster recommended
RAM1 GB minimum, 2 GB or more recommended
Disk space100 MB minimum
Network100Mb or faster NIC

2.1.3. Supported Guest Operating Systems

For a list of supported VM operating systems, see the XenServer Virtual Machine Installation Guide.

Chapter 3. Installing XenServer and XenCenter

This chapter steps through installing the XenServer host software on physical servers, installing XenCenter on Windows workstations and connecting them to form the infrastructure for creating and running virtual machines (VMs).

After guiding you through installation, this chapter describes a selection of common installation and deployment scenarios.

3.1. Installation Media and Methods

The XenServer host consists of a Xen-enabled Linux operating system, a management agent, VM templates, and a local storage repository reserved for VMs. The XenServer host must be installed on a dedicated 64-bit x86 server.

[Note]Note

Do not install any other operating system in a dual-boot configuration with the XenServer host; this is an unsupported configuration.

Installation Media

Installers for both the XenServer host and XenCenter are located on the installation media. The installation media also includes the Readme First, which provides descriptions of and links to helpful resources, including product documentation for XenServer and XenServer components.

Installation Methods

There are three methods by which to install the XenServer host:

  • From a CD

    You can download the installer (ISO file format) and burn it to a CD. To download the installer, visit www.citrix.com/xenserver.

    The main XenServer installation file contains the basic packages required to set up XenServer on your host and install XenCenter on your Windows computer, in conjunction with the desired Windows installation media.

  • Set up a network-accessible TFTP server to boot using PXE

    For details about setting up an TFTP server for PXE-booting the installer, see Appendix C, PXE Boot Installations.

  • Install XenServer to a remote disk on a SAN to enable boot from SAN

    For details, see Appendix B, Boot From SAN Environments.

Linux Guest Support and Other Supplemental Packs

If you wish to install Linux VMs, download the Linux Guest Support ISO and burn it to a CD or set it up for PXE installation as described in Appendix C, PXE Boot Installations. To download the Linux Guest Support ISO, visit www.citrix.com/xenserver.

[Note]Note

All XenServer hosts joined in a pool need to have the same supplemental packs installed.

You can install Linux support or another required supplemental pack after installing XenServer. To do so, mount the appropriate installation media on the XenServer host, and then run the script install.sh, located in the root directory of the CD.

Upgrades

The installer presents the option to upgrade if it detects a previously installed version of XenServer. The upgrade process follows the first-time installation process, but several setup steps are bypassed. The existing settings are retained, including networking configuration, system time and so on.

[Important]Important

Upgrading requires careful planning and attention. For detailed information about upgrading individual XenServer hosts and pools, see Chapter 5, Upgrading XenServer.

3.2. Installing the XenServer Host

[Warning]Warning

Installing XenServer will overwrite data on any hard drives that you select to use for the installation. Back up data that you wish to preserve before proceeding.

To install or upgrade the XenServer host:

  1. Boot the computer from the installation CD or PXE-boot from your TFTP server, if applicable.

  2. Following the initial boot messages and the Welcome to XenServer screen, select your keyboard layout for the installation.

    [Tip]Tip

    Throughout the installation, quickly advance to the next screen by pressing F12. Use Tab to move between elements, and Space or Enter to select. For general help, press F1.

  3. The Welcome to XenServer Setup screen is displayed.

    XenServer ships with a broad driver set that supports most modern server hardware configurations. However, if you have been provided with any supplemental packs containing additional essential drivers, press F9. The installer will then step you through installing the necessary drivers.

    Once you have installed all of the required drivers, select Ok to proceed.

  4. The XenServer End User License Agreement (EULA) is displayed. Use the Page Up and Page Down keys to scroll through and read the agreement. Choose Accept EUlA to proceed.

    [Note]Note

    If you now see a System Hardware warning screen and suspect that hardware virtualization assist support is available on your system, check the support site of your hardware manufacturer for BIOS upgrades.

  5. Select an installation action, as appropriate. You may see any of the following options:

    • Perform clean installation

    • Upgrade: if the installer detects a previously-installed version of XenServer, it offers the option to upgrade. For details on upgrading your XenServer host, see Chapter 5, Upgrading XenServer.

    • Restore: if the installer detects a previously-created backup installation, it offers the option to restore XenServer from the backup. For details, see the XenServer Administrator's Guide.

    Make your selection, and choose Ok to proceed.

  6. If you have multiple local hard disks, choose a Primary Disk for the installation. Select Ok.

  7. Choose which disk(s) you would like to use for virtual machine storage. Information about a specific disk can be viewed by pressing F5.

    If you want to use Thin Provisioning to optimize the utilization of available storage, select Enable thin provisioning. XenDesktop users are strongly recommended to select this option in order for local caching to work properly. For details, see Chapter 6, XenServer and IntelliCache.

    Choose Ok.

  8. Select your installation media source.

    If installing from a CD, choose Local media. If installing using PXE, select HTTP or FTP or NFS, as appropriate. Choose Ok to proceed.

    If you select Local media, the next screen asks if you want to install any supplemental packs from a CD. If you plan to install Linux Guest Support or other supplemental packs provided by your hardware supplier, choose Yes.

    If you select HTTP or FTP or NFS:

    1. Set up networking so that the installer can connect to the XenServer installation media files.

      If the computer has multiple NICs, select one of them to be used to access the XenServer installation media files, and then choose Ok to proceed.

    2. Choose Automatic configuration (DHCP) to configure the NIC using DHCP, or Static configuration to configure the NIC manually. If you choose Static configuration, enter details as appropriate.

    3. If you choose HTTP or FTP, you are then prompted to provide the URL for your HTTP or FTP repository, and a username and password, if appropriate.

      If you choose NFS, you are prompted to provide the server and path of your NFS share.

      Select Ok to proceed.

  9. Indicate if you want to verify the integrity of the installation media. If you select Verify installation source, the MD5 checksum of the packages is calculated and checked against the known value. Verification may take some time. Make your selection and choose Ok to proceed.

  10. Set and confirm a root password, which XenCenter will use to connect to the XenServer host. You will also use this password (with username "root") to log into xsconsole, the system configuration console.

  11. Set up the primary management interface that will be used to connect to XenCenter.

    If your computer has multiple NICs, select the NIC which you wish to use for management. Choose Ok to proceed.

  12. Configure the Management NIC IP address by choosing Automatic configuration (DHCP) to configure the NIC using DHCP, or Static configuration to manually configure the NIC.

    [Note]Note

    To be part of a pool, XenServer hosts must have static IP addresses or be DNS addressable. When using DHCP, ensure that a static DHCP reservation policy is in place.

  13. Specify the hostname and the DNS configuration, manually or automatically via DHCP.

    In the Hostname Configuration section, select Automatically set via DHCP to have the DHCP server provide the hostname along with the IP address. If you select Manually specify, enter the desired hostname for the server in the field provided.

    In the DNS Configuration section, choose Automatically set via DHCP to get name service configuration using DHCP. If you select Manually specify, enter the IP address(es) of your primary (required), secondary (optional), and tertiary (optional) DNS servers in the fields provided.

    Select Ok to proceed.

  14. Select your time zone — the geographical area and then city. You can type the first letter of the desired locale to jump to the first entry that begins with this letter. Choose Ok to proceed.

  15. Specify how you would like the server to determine local time: using NTP or manual time entry. Make your selection, and choose Ok to proceed.

  16. If using NTP, either select NTP is configured by my DHCP server to have DHCP set the time server or enter at least one NTP server name or IP address in the fields below. Choose Ok.

    [Note]Note

    XenServer assumes that the time setting in the BIOS of the server is the current time in UTC.

  17. Select Install XenServer.

    If you elected to set the date and time manually, you will be prompted to do so during the installation. Once set, choose Ok to proceed.

  18. If you are installing from a CD and elected to include supplemental packs, you will be prompted to insert them. Eject the XenServer installation CD, and insert the supplemental pack CD. Choose Ok.

    Select Use media to proceed with the installation.

    Repeat for each pack to be installed.

  19. From the Installation Complete screen, eject the installation CD (if installing from CD) and select Ok to reboot the server.

    After the server reboots, XenServer displays xsconsole, a system configuration console. To access a local shell from xsconsole, press Alt+F3; to return to xsconsole, press Alt+F1

    [Note]Note

    Make note of the IP address displayed. You will use this when you connect XenCenter to the XenServer host.

3.3. Installing XenCenter

XenCenter must be installed on a remote Windows machine that can connect to the XenServer host through your network. The .NET framework version 2.0 service pack 1 or later must also be installed on this workstation.

The XenCenter installation media is bundled with the XenServer installation media. You can also download the latest version of XenCenter from www.citrix.com/xenserver.

To install XenCenter:

  1. Before installing XenCenter, be sure to uninstall any previous version.

  2. Launch the installer.

    If installing from a XenServer installation CD:

    1. Insert the CD into the DVD drive of the computer which you want to run XenCenter.

    2. Open the client_install folder on the CD. Double-click XenCenter.msi to begin the installation.

  3. Follow the Setup wizard, which allows you to modify the default destination folder and then to install XenCenter.

3.4. Connecting XenCenter to the XenServer Host

To connect XenCenter to the XenServer host:

  1. Launch XenCenter. The program opens to the Home tab.

  2. Click the ADD a server icon.

  3. Enter the IP address of the XenServer host in the Server box. Type the root username and password that you set during XenServer installation. Choose Add.

  4. The first time you add a new host, the Save and Restore Connection State dialog box appears. This enables you to set your preferences for storing your host connection information and automatically restoring host connections.

    If you later need to change your preferences, you can do so using XenCenter or the Windows Registry Editor.

    To do so in XenCenter: from the Tools menu, select Save and Restore. The Save and Restore Connection State dialog box opens.

    To do so using the Windows Registry Editor, navigate to the key HKEY_LOCAL_MACHINE\Software\Citrix\XenCenter (if you installed XenServer for use by all users) and add a key named AllowCredentialSave with the string value true or false.

Chapter 4. Installation and Deployment Scenarios

This chapter steps through the following common installation and deployment scenarios:

  • One or more XenServer host(s) with local storage

  • Pools of XenServer hosts with shared storage:

    • Multiple XenServer hosts with shared NFS storage

    • Multiple XenServer hosts with shared iSCSI storage

4.1. XenServer Hosts with Local Storage

The simplest deployment of XenServer is to run VMs on one or more XenServer host(s) with local storage.

[Note]Note

Without shared storage, XenMotion live migration of VMs between XenServer hosts is not available.

Basic hardware requirements:

  • One or more 64-bit x86 server(s) with local storage

  • One or more Windows workstation(s), on the same network as the XenServer host(s)

High-level procedure:

  1. Install the XenServer host software on the server(s).

  2. Install XenCenter on the workstation(s).

  3. Connect XenCenter to the XenServer host(s).

    Once you have connected XenCenter to a XenServer host, storage is automatically configured on the local disk of the host.

4.2. Pools of XenServer Hosts with Shared Storage

A pool is comprised of multiple XenServer host installations, bound together as a single managed entity. When combined with shared storage, a pool enables VMs to be started on any XenServer host in the pool that has sufficient memory, and then dynamically moved between hosts while running (XenMotion), and with minimal downtime. If an individual XenServer host suffers a hardware failure, you can restart the failed VM(s) on another host in the same pool.

If the High Availability (HA) feature (only available to XenServer Advanced Edition or higher) is enabled, protected VMs are automatically moved in the event of a host failure.

To set up shared storage between hosts in a pool, you need to create a storage repository. A XenServer storage repository (SR) is a storage container in which virtual disks are stored. SRs, like virtual disks, are persistent, on-disk objects that exist independently of XenServer. SRs can exist on different types of physical storage devices, both internal and external, including local disk devices and shared network storage. A number of different types of storage are available when you create a new SR, including:

  • NFS VHD storage

  • Software iSCSI storage

  • Hardware HBA storage

This following sections step through setting up two common shared storage solutions — NFS and iSCSI — for a pool of XenServer hosts. Before you create a new SR, you need to configure your NFS or iSCSI storage. Setup differs depending on the type of storage solution that you use, so it is best to refer to your vendor documentation for details. In all cases, to be part of a pool, the servers providing shared storage must have static IP addresses or be DNS addressable. For further information on setting up shared storage, see the XenServer Administrator's Guide.

It is recommended that you create a pool before you add shared storage. For pool requirements and setup procedures, see the XenCenter Help or the XenServer Administrator's Guide.

4.2.1. XenServer Hosts with Shared NFS Storage

Basic hardware requirements:

  • Two or more 64-bit x86 servers with local storage

  • One or more Windows workstation(s), on the same network as the XenServer hosts

  • A server exporting a shared directory over NFS

High-level procedure:

  1. Install the XenServer host software on the servers.

  2. Install XenCenter on the workstation(s).

  3. Connect XenCenter to the XenServer hosts.

  4. Create your pool of XenServer hosts.

  5. Configure the NFS server.

  6. Create an SR on the NFS share at the pool level.

Configuring you NFS storage. Before you create an SR, you need to configure the NFS storage. To be part of a pool, the NFS share must have a static IP address or be DNS addressable. You must also configure the NFS server to have one or more target(s) that can be mounted by NFS clients (for example, XenServer hosts in a pool). Setup differs depending on your storage solution, so it is best to see your vendor documentation for details.

To create an SR on the NFS share at the pool level in XenCenter:

  1. On the Resources pane, select the pool. On the toolbar, click the New Storage button. The New Storage Repository wizard opens.

  2. Under Virtual disk storage, choose NFS VHD as the storage type. Choose Next to continue.

  3. Enter a name for the new SR and the name of the share where it is located. Click Scan to have the wizard scan for existing NFS SRs in the specified location.

    [Note]Note

    The NFS server must be configured to export the specified path to all XenServer hosts in the pool.

  4. Click Finish.

    The new SR appears in the Resources pane, at the pool level.

Creating an SR on the NFS share at the pool level using the xe CLI:

  1. Open a console on any XenServer host in the pool.

  2. Create the storage repository on server:/path by entering the following:

    xe sr-create content-type=user type=nfs name-label=<sr_name=> \
    					shared=true device-config:server=<server> \
    					device-config:serverpath=<path>

    The device-config-server argument refers to the name of the NFS server and the device-config-serverpath argument refers to the path on the server. Since shared is set to true, the shared storage is automatically connected to every host in the pool and any hosts that subsequently join are also connected to the storage. The UUID of the created storage repository is printed to the console.

  3. Find the UUID of the pool by using the pool-list command.

  4. Set the new SR as the pool-wide default by entering the following:

    xe pool-param-set uuid=<pool_uuid> \
    					default-SR=<storage_repository_uuid>

    As shared storage has been set as the pool-wide default, all future VMs will have their disks created on this SR.

4.2.2. XenServer Hosts with Shared iSCSI Storage

Basic hardware requirements:

  • Two or more 64-bit x86 servers with local storage

  • One or more Windows workstation(s), on the same network as the XenServer hosts

  • A server providing a shared directory over iSCSI

High-level procedure:

  1. Install the XenServer host software on the servers.

  2. Install XenCenter on the workstation(s).

  3. Connect XenCenter to the XenServer hosts.

  4. Create your pool of XenServer hosts.

  5. Configure the iSCSI storage.

  6. If necessary, enable multiple initiators on your iSCSI device.

  7. If necessary, configure the iSCSI IQN for each XenServer host.

  8. Create an SR on the iSCSI share at the pool level.

Configuring your iSCSI storage. Before you create an SR, you need to configure the iSCSI storage. To be part of a pool, the iSCSI storage must have a static IP address or be DNS addressable. You will also need to provide an iSCSI target LUN on the SAN for the VM storage, and then configure XenServer hosts to be able to see and access it. Both the iSCSI target and each iSCSI initiator on each XenServer host must have a valid and unique iSCSI Qualified Name (IQN). For configuration details, it is best to see your vendor documentation.

Configuring an iSCSI IQN for each XenServer host. Upon installation, XenServer automatically attributes a unique IQN to each host. If you need to adhere to a local administrative naming policy, you can change the IQN by entering the following on the host console:

xe-set-iscsi-iqn <iscsi_iqn>

Or, you can use the xe CLI by entering the following:

xe host-param-set uuid=<host_uuid> other-config-iscsi_iqn=<iscsi_iqn>

To create an SR on the iSCSI share at the pool level using XenCenter:

[Warning]Warning

When using XenCenter to create SRs for iSCSI and NetApp storage, any existing contents of the volume are destroyed.

  1. On the Resources pane, select the pool. On the toolbar, click the New Storage button. The New Storage Repository wizard opens.

  2. Under Virtual disk storage, choose Software iSCSI as the storage type. Choose Next to continue.

  3. Enter a name for the new SR and then the IP address or DNS name of the iSCSI target.

    [Note]Note

    The iSCSI storage target must be configured to enable every XenServer host in the pool to have access to one or more LUN(s).

  4. If you have configured the iSCSI target to use CHAP authentication, enter the User and Password.

  5. Click the Discover IQNs button, and then choose the iSCSI target IQN from the Target IQN list.

    [Warning]Warning

    The iSCSI target and all servers in the pool must have unique IQNs.

  6. Click the Discover LUNs button, and then choose the LUN on which to create the SR from the Target LUN list.

    [Warning]Warning

    Each individual iSCSI storage repository must be contained entirely on a single LUN, and may not span more than one LUN. Any data present on the chosen LUN will be destroyed.

  7. Click Finish.

    The new SR appears in the Resources pane, at the pool level.

To create an SR on the iSCSI share at the pool level using the xe CLI:

  1. On the console of any server in the pool, run the command:

    xe sr-create name-label=<name_for_sr> \
    content-type=user device-config-target=<iscsi_server_ip_address> \ 
    device-config-targetIQN=<iscsi_target_iqn> \
    device-config-localIQN=<iscsi_local_iqn> \
    type=lvmoiscsi shared=true device-config-LUNid=<lun_id>

    The device-config-target argument refers to the name or IP address of the iSCSI server. The device-config-LUNid argument can be a list of LUN IDs (separated by commas). Since the shared argument is set to true, the shared storage is automatically connected to every host in the pool and any hosts that subsequently join are also connected to the storage.

    The command returns the UUID of the created storage repository.

  2. Find the UUID of the pool by running the pool-list command.

  3. Set the new SR as the pool-wide default by entering the following:

    xe pool-param-set uuid=<pool_uuid> default-SR=<iscsi_shared_sr_uuid>

    As shared storage has been set as the pool-wide default, all future VMs will have their disks created on this SR.

Chapter 5. Upgrading XenServer

This chapter documents how to upgrade to XenServer.

XenServer only permits upgrades from the last minor release. For example, in order to upgrade from version 5.0.0 to version 5.6, you must first upgrade version 5.0.0 to version 5.5, and then upgrade version 5.5 to version 5.6, and so on.

If you are upgrading to a feature pack, XenServer permits a direct upgrade from the preceding release. For example, you can upgrade directly from version 5.5 to version 5.6 Service Pack 2.

[Important]Important

Upgrading a XenServer host — and particularly a pool of XenServer hosts — requires extremely careful planning and attention. Be sure to map your upgrade path carefully and to be absolutely sure that you choose the option to upgrade when you are stepping through the installer so as to avoid losing any existing data.

5.1. Upgrading a Single XenServer Host

5.1.1. Before You Upgrade a Single XenServer Host

Before upgrading an unpooled XenServer host, you will be required to either shut down or suspend any VMs running on that host. It is important to eject and empty CD/DVD drives of any VMs that you plan to suspend. If you do not empty the CD/DVD drives, the suspended VMs may not be resumeable after upgrade.

An empty VM CD/DVD drive means that the VM is attached to neither an ISO image nor a physical CD/DVD mounted via the XenServer host. Further, it requires that the VM not be attached to any physical CD/DVD drive on the XenServer host at all.

To empty the CD/DVD drive of a VM in XenCenter:

  1. On the Resources pane, select the VM, and then click the Console tab.

  2. Click the Eject button to empty the DVD drive.

    The DVD Drive drop-down menu will be set to <empty>.

To empty the CD/DVD drive of a VM using the xe CLI:

  1. Identify which VMs do not have empty CD/DVD drives by entering the following:

    xe vbd-list type=CD empty=false

    This returns a list of all the VM CD/DVD drives that are not empty, for example:

    uuid ( RO) : abae3997-39af-2764-04a1-ffc501d132d9 
    vm-uuid ( RO): 340a8b49-866e-b27c-99d1-fb41457344d9 
    vm-name-label ( RO): VM02_DemoLinux 
    vdi-uuid ( RO): a14b0345-b20a-4027-a233-7cbd1e005ede 
    empty ( RO): false 
    device ( RO): xvdd 
                                
    uuid ( RO) : ec174a21-452f-7fd8-c02b-86370fa0f654 
    vm-uuid ( RO): db80f319-016d-0e5f-d8db-3a6565256c71 
    vm-name-label ( RO): VM01_DemoLinux 
    vdi-uuid ( RO): a14b0345-b20a-4027-a233-7cbd1e005ede 
    empty ( RO): false 
    device ( RO): xvdd

    Note the uuid, which is the first item in the list.

  2. To empty the CD/DVD drives of the VMs listed, enter the following:

    xe vbd-eject uuid=<uuid>

5.1.2. Upgrading a Single XenServer Host

To upgrade a single XenServer host using XenCenter:

  1. Shut down or suspend any VMs running on the host that you wish to upgrade.

  2. Shut down the host.

  3. Follow the XenServer installation procedure (see Chapter 3, Installing XenServer and XenCenter) until the installer offers you the option to upgrade. Choose to upgrade.

    [Warning]Warning

    Be absolutely sure to select the upgrade option so as to avoid losing any existing data.

    You will not be required to re-enter any settings during the setup procedure. The upgrade process follows the first-time installation process but several setup steps are bypassed, and the existing settings for networking configuration, system time, and so on are retained.

  4. Once the upgrade is complete, restart any shutdown VMs, and/or resume any suspended VMs.

To upgrade a single XenServer host using the xe CLI:

  1. Disable the XenServer host that you wish to upgrade by entering the following:

    xe host-disable <host-selector>=<host_selector_value>

    When a XenServer host is disabled, VMs can neither be created nor started on that host. VMs also cannot be migrated to a disabled host.

  2. Shut down or suspend any VMs running on the host that you wish to upgrade by using the xe vm-shutdown or xe vm-suspend commands.

  3. Shut down the host by using the xe host-shutdown command.

  4. Follow the XenServer installation procedure (see Chapter 3, Installing XenServer and XenCenter) until the installer offers you the option to upgrade. Choose to upgrade.

    [Warning]Warning

    Be absolutely sure to select the upgrade option so as to avoid losing any existing data.

    You will not be required to re-enter any settings during the setup procedure. The upgrade process follows the first-time installation process but several setup steps are bypassed, and the existing settings for networking configuration, system time, and so on are retained.

    Once your host restarts, normal service is restored after a few minutes.

  5. Restart any shutdown VMs, and/or resume any suspended VMs.

5.2. Upgrading a Pool of XenServer Hosts (Rolling Pool Upgrades)

XenServer allows you to upgrade a pool of XenServer hosts while keeping VMs in that pool running. By using XenMotion live migration, you can move running VMs to other hosts in the pool and then upgrade one host at a time. This method takes only one XenServer host offline at a time.

You can use XenCenter or the xe CLI to migrate running VMs between XenServer hosts in a pool. For details on VM live migration, see the XenServer Administrator's Guide.

[Important]Important

Planning your upgrade path carefully is key. Be sure to read the following section carefully before you begin your upgrade.

5.2.1. Before You Upgrade a Pool of XenServer Hosts

Upgrading a pool of XenServer hosts requires careful planning. As you plan your upgrade, it is very important to be aware of the following:

  • You can only migrate VMs from a XenServer host running an older version of XenServer to one running the same version or higher (for example, from version 5.5 to version 5.5 or from version 5.5 to version 5.6). You cannot migrate VMs from an upgraded host to one running an older version of XenServer (for example, from version 5.6 to version 5.5). Be sure to allow for space on your XenServer hosts accordingly.

  • Citrix strongly advises against running a mixed-mode pool (one with multiple versions of XenServer co-existing) for longer than necessary, as the pool operates in a degraded state during upgrade.

  • Key control operations are not available during upgrade and should not be attempted. Though VMs continue to function as normal, VM actions other than migrate may not be available (for example, shut down, copy and export). In particular, it is not safe to perform storage-related operations such as adding, removing or resizing virtual disks.

  • Always upgrade the master host first. Do not place the host into maintenance mode using XenCenter before performing the upgrade as this will cause a new master to be designated.

  • Citrix strongly recommends that you take a backup of the state of your existing pool using the pool-dump-database xe CLI command (see the XenServer Administrator's Guide). This allows you to revert a partially complete rolling upgrade back to its original state without losing any VM data. Because it is not possible to migrate a VM from an upgraded XenServer host to a XenServer host running an older version of XenServer, it may be necessary to shut down VMs if you need to revert the rolling upgrade for any reason.

Before you begin your rolling pool upgrade:

  • If you are using XenCenter, upgrade XenCenter to the latest version. The newer version of XenCenter will correctly control older versions of XenServer hosts.

  • Empty the CD/DVD drives of the VMs in the pool. For details and instructions, see Section 5.1.1, “Before You Upgrade a Single XenServer Host”.

  • Disable HA.

  • Disable WLB.

5.2.2. Upgrading a Pool of XenServer Hosts

To upgrade a pool of XenServer hosts using XenCenter:

  1. Start with the pool master. Ensure that no VMs are running on the master. Shut down, suspend or migrate VMs to other hosts in the pool.

  2. Shut down the pool master.

    [Important]Important

    XenCenter will be unable to contact the pool master until the upgrade of the master is complete.

  3. Boot the pool master using the XenServer installation media and method of your choice (such as, installation CD or network). Follow the XenServer installation procedure (see Chapter 3, Installing XenServer and XenCenter) until the installer offers you the option to upgrade. Choose to upgrade.

    [Warning]Warning

    Be absolutely sure to select the upgrade option so as to avoid losing any existing data.

    [Warning]Warning

    If anything interrupts the upgrade of the pool master or if the upgrade fails for any reason, do not attempt to proceed with the upgrade. Reboot the pool master and restore to a working version of the master. For details on restoring a XenServer host, see the XenServer Administrator's Guide.

    You will not be required to re-enter any settings during the setup procedure. The upgrade process follows the first-time installation process but several setup steps are bypassed, and the existing settings for networking configuration, system time, and so on are retained.

    Once your pool master restarts, normal service is restored after a few minutes. XenCenter is then able to contact the pool master.

  4. On the pool master, start or resume any shut down or suspended VMs. Migrate any VMs that you wish back to the pool master.

  5. Select the next XenServer host in your upgrade path. Ensure that no VMs are running on the host. Shut down, suspend or migrate VMs to other hosts in the pool, as planned.

  6. Shut down the host.

  7. Follow the upgrade procedure for the host, as described for the master in Step 3.

    [Note]Note

    If the upgrade of a host that is not the master fails or is interrupted, you do not need to revert. Reboot the host, and restart the upgrade.

  8. On the host, start or resume any shutdown or suspended VMs. Migrate any VMs that you wish back to the host.

  9. Repeat Steps 5 – 8 for the rest of the hosts in the pool.

  10. Once each host in the pool has been upgraded, it is important to upgrade the XenServer Tools on all VMs. Please refer to the XenCenter Help or the XenServer Virtual Machine Installation Guide for details.

    [Note]Note

    Running older versions of the XenServer Tools on newer XenServer installations is not supported, except during the upgrade process.

To upgrade a pool of XenServer hosts using the xe CLI:

  1. Start with the pool master. Disable the master by using the host-disable command. This prevents any new VMs from starting on the specified host.

  2. Ensure that no VMs are running on the master. Shut down, suspend or migrate VMs to other hosts in the pool.

    To migrate specified VMs to specified hosts, use the vm-migrate command. By using the vm-migrate command, you will have full control over the distribution of migrated VMs to other hosts in the pool.

    To live migrate all VMs to other hosts in the pool, use the host-evacuate command. By using the host-evacuate command, you leave the distribution of migrated VMs to XenServer.

  3. Shut down the pool master.

    [Important]Important

    You will be unable to contact the pool master until the upgrade of the master is complete. Shutting down the pool master causes the other hosts in the pool to enter emergency mode. In general, a XenServer host enters emergency mode when it is a member of a pool whose master has disappeared from the network and cannot be contacted after a number of attempts. VMs continue to run on hosts in emergency mode, but control operations are not available.

  4. Boot the pool master using the XenServer installation media and method of your choice (such as, installation CD or network). Follow the XenServer installation procedure (see Chapter 3, Installing XenServer and XenCenter) until the installer offers you the option to upgrade. Choose to upgrade.

    [Warning]Warning

    Be absolutely sure to select the upgrade option so as to avoid losing any existing data.

    [Warning]Warning

    If anything interrupts the upgrade of the pool master or if the upgrade fails for any reason, do not attempt to proceed with the upgrade. Reboot the pool master and restore to a working version of the master. For details on restoring a XenServer host, see the XenServer Administrator's Guide.

    Once your pool master restarts, the other hosts in the pool will leave emergency mode and normal service is restored after a few minutes.

  5. On the pool master, start or resume any shut down or suspended VMs. Migrate any VMs that you wish back to the pool master.

  6. Select the next XenServer host in your upgrade path. Disable the host.

  7. Ensure that no VMs are running on the host. Shut down, suspend or migrate VMs to other hosts in the pool.

  8. Shut down the host.

  9. Follow the upgrade procedure for the host, as described for the master in Step 4.

    [Note]Note

    If the upgrade of a host that is not the master fails or is interrupted, you do not need to revert. Use the host-forget command to forget the host. Re-install XenServer on the host, and then join it, as a new host, to the pool using the pool-join command.

  10. On the host, start or resume any shutdown or suspended VMs. Migrate any VMs that you wish back to the host.

  11. Repeat Steps 6 – 10 for the rest of the hosts in the pool.

  12. Once each host in the pool has been upgraded, it is important to upgrade the XenServer Tools on all VMs. Please refer to the XenServer Virtual Machine Installation Guide for details.

    [Note]Note

    Running older versions of the XenServer Tools on newer XenServer installations is not supported, except during the upgrade process.

5.3. Upgrading LVM Storage from XenServer 5.0 or Earlier

The LVM, LVM on HBA (LVMoHBA), and LVM on iSCSI (LVMoISCSI) storage types have new functionality in XenServer including fast clone and snapshot support. You will need to upgrade your storage to the new format to take advantage of these new features — this is done using the xe CLI.

[Warning]Warning

This upgrade is a one-way operation and upgraded storage cannot be used with older versions of XenServer.

Upgrading LVM-based SRs using the xe CLI:

  1. Check that your storage repository is attached correctly on all hosts before starting the upgrade procedure. To do so, use the pbd-list command, and check that all PBDs have currently-attached set to true.

  2. Log into the control domain, and then call the /opt/xensource/bin/xe-lvm-upgrade tool to upgrade your SRs by passing in the SR UUID of the SR you would like to upgrade:

    /opt/xensource/bin/xe-lvm-upgrade <SR UUID>

    This tool will indicate when your SRs have been successfully upgraded.

Chapter 6. XenServer and IntelliCache

[Note]Note

This feature is only supported when using XenServer with XenDesktop

Using XenServer with IntelliCache makes hosted Virtual Desktop Infrastructure deployments more cost-effective by enabling you to use a combination of shared storage and local storage. It is of particular benefit when many Virtual Machines (VMs) all share a common OS image. The load on the storage array is reduced and performance is enhanced. In addition, network traffic to and from shared storage is reduced as the local storage caches the master image from shared storage.

IntelliCache works by caching data from a VMs parent VDI in local storage on the VM host. This local cache is then populated as data is read from the parent VDI. When many VMs share a common parent VDI (for example by all being based on a particular master image), the data pulled into the cache by a read from one VM can be used by another VM. This means that further access to the master image on shared storage is not required.

A thin provisioned, local SR is an IntelliCache prerequisite. Thin Provisioning is a way of optimizing the utilization of available storage. This approach allows you to make more use of local storage instead of shared storage. It relies on on-demand allocation of blocks of data instead of the traditional method of pre-allocating all of the blocks.

[Important]Important

Thin Provisioning changes the default local storage type of the host from LVM to EXT3. Thin Provisioning must be enabled in order for XenDesktop local caching to work properly.

Thin Provisioning allows the administrator to present more storage space to the VMs connecting to the Storage Repository (SR) than is actually available on the SR. There are no space guarantees, and allocation of a LUN does not claim any data blocks until the VM writes data.

[Warning]Warning

Thin provisioned SRs may run out of physical space, as the VMs within can grow to consume disk capacity on demand.  IntelliCache VMs handle this condition by automatically falling back to shared storage if the local SR cache is full.  It is not recommended to mix traditional virtual machines and IntelliCache VMs on the same SR, as intellicache VMs may grow quickly in size.

6.1. IntelliCache Deployment

IntelliCache must be enabled either during host installation or be enabled manually on a running host using the CLI.

Citrix recommends that you use a high performance local storage device to ensure the fastest possible data transfer such as a Solid State Disk or a high performance RAID array. Both data throughput and storage capacity should be considered when sizing local disks. The shared storage type, used to host the source Virtual Disk Image (VDI), must be NFS or EXT based.

6.1.1. Enabling on Host Installation

To enable IntelliCache during host installation, on the Virtual Machine Storage screen, select Enable thin provisioning (Optimized storage for XenDesktop). This selects the host's local SR to be the one to be used for the local caching of VM VDIs.

6.1.2. Converting an Existing Host to Use Thin Provisioning

To destroy an existing LVM based local SR, and replace it with a thin provisioned EXT3 based SR, enter the following commands.

[Warning]Warning

These commands will destroy your existing local SR, and VMs on the SR will be permanently deleted.

localsr=`xe sr-list type=lvm host=<hostname> params=uuid --minimal`
    echo localsr=$localsr
    pbd=`xe pbd-list sr-uuid=$localsr params=uuid --minimal`
    echo pbd=$pbd
    xe pbd-unplug uuid=$pbd
    xe pbd-destroy uuid=$pbd
    xe sr-forget uuid=$localsr
    sed -i "s/'lvm'/'ext'/" /etc/firstboot.d/data/default-storage.conf
    rm -f /etc/firstboot.d/state/10-prepare-storage
    rm -f /etc/firstboot.d/state/15-set-default-storage
    service firstboot start
    xe sr-list type=ext
            

To enable local caching, enter the following commands:

xe host-disable host=<hostname>
    localsr=`xe sr-list type=ext host=<hostname> params=uuid --minimal`
    xe host-enable-local-storage-caching host=<hostname> sr-uuid=$localsr
    xe host-enable host=<hostname>
                

6.1.3. VM Boot Behaviour

There are two options for the behaviour of a VM VDI when the VM is booted:

  1. Shared Desktop Mode

    On VM boot, the VDI is reverted to the state it was in at the previous boot. All changes while the VM is running will be lost when the VM is next booted.

    Select this option if you plan to deliver standardized desktops to which users cannot make permanent changes.

  2. Private Desktop Mode

    On VM boot, the VDI is in the state it was left in at the last shutdown.

    Select this option if you plan to allow users to make permanent changes to their desktops.

6.1.3.1. VM Caching Behaviour Settings

The VDI flag allow-caching dictates the caching behaviour:

6.1.3.1.1. Shared Desktop Mode

For shared desktops, the on-boot option is set to reset and the allow-caching flag is set to true, new VM data is written only to local storage – there will be no writes to shared storage. This means that the load on shared storage is significantly reduced. However the VM cannot be migrated between hosts.

6.1.3.1.2. Private Desktop Mode

For private desktops, the on-boot option is set to persist and the allow-caching flag is set to true, new VM data is written to both local and shared storage. Reads of cached data do not require I/O traffic to shared storage so the load on shared storage is somewhat reduced. VM Migration to another host is permitted and the local cache on the new host is populated as data is read.

6.1.4. Implementation Details and Troubleshooting

6.1.4.1. Is IntelliCache compatible with XenMotion and High Availability?
6.1.4.2. Where does the local cache live on the local disk?

6.1.4.1.

Is IntelliCache compatible with XenMotion and High Availability?

You can use XenMotion and High Availability with IntelliCache when virtual desktops are in Private mode, that is when on-boot=persist

[Warning]Warning

A VM cannot be migrated if any of its VDIs have caching behaviour flags set to on-boot=reset and allow-caching=true. Migration attempts for VMs with these properties will fail.

6.1.4.2.

Where does the local cache live on the local disk?

The cache lives in a Storage Repository (SR). Each host has a configuration parameter (called local-cache-sr) indicating which (local) SR is to be used for the cache files. Typically this will be a EXT type SR. When you run VMs with IntelliCache, you will see files inside the SR with names <uuid>.vhdcache. This is the cache file for the VDI with the given UUID. These files are not displayed in XenCenter – the only way of seeing them is by logging into dom0 and listing the contents of /var/run/sr-mount/<sr-uuid>

6.1.4.1. How do I specify a particular SR for use as the cache?
6.1.4.2. When is the local cache deleted?

6.1.4.1.

How do I specify a particular SR for use as the cache?

The host object field local-cache-sr refers to a local SR. You can view its value by running the following command:

xe sr-list params=local-cache-sr,uuid,name-label
                

This field is set either:

  • after host installation, if the "Enable thin provisioning" option was selected in the host installer

  • by executing xe host-enable-local-storage-caching host=<host> sr-uuid=<sr>. This command requires the specified host to be disabled, VMs must be shut down if this command is used.

The first option uses the EXT type local SR and is created during host installation. The second option, uses the SR that is specified on the command-line.

[Warning]Warning

These steps are only necessary for users who have configured more than one local SR.

6.1.4.2.

When is the local cache deleted?

A VDI cache file is only deleted when the VDI itself is deleted. The cache is reset when a VDI is attached to a VM (for example on VM start). If the host is offline when the VDI is deleted, the SR synchronisation that runs on startup will garbage collect the cache file.

[Note]Note

The cache file is not deleted from the host when a VM is migrated to a different host or shut down.

Chapter 7. Applying Updates and Hotfixes to XenServer

Between releases of XenServer, Citrix occasionally releases updates and hotfixes. Hotfixes fix one or more specific issues; updates contain accumulated bug fixes and, occasionally, small feature improvements. This chapter describes the general procedures for applying updates and hotfixes to your XenServer deployment through XenCenter and the xe CLI.

Public hotfixes and updates are made available for download from the Citrix Knowledge Center. Specific information and instructions regarding each download are published alongside. It is best to check the Knowledge Center for new updates and hotfixes. You may also receive an e-mail or an alert in XenCenter when a particularly important hotfix or update is released for the version of XenServer that you are running.

Hotfixes and updates can often be applied with minimal service interruption. If you are updating a pool of XenServer hosts, you can avoid downtime of VMs by updating one host at a time, migrating VMs away from each host as the hotfix or update is applied. XenCenter can take care of this update sequence automatically. If you are using the xe CLI, you will have to do this manually.

7.1. Before You Apply an Update or Hotfix

[Important]Important

It is important to follow the Readme that comes with each update file. Each update file has unique instructions for installation, particularly with regard to preparatory and post-update operations. The following sections offer general guidance and instructions for applying hotfixes and updates to your XenServer deployment.

Before you update XenServer hosts, it is important to be aware of the following:

  • It is best to update all hosts in a pool within a short period, as running a mixed-mode pool (a pool that includes updated and non-updated hosts) for general operation is not supported.

  • Citrix recommends that you reboot any hosts that you plan to update to ensure that the hosts are healthy and configurations correct (for example, to ensure that VMs start and that storage is accessible). Rebooting is particularly important if you have made any critical, low-level changes and have not restarted your XenServer host(s) for some time. If there are any pre-existing configuration issues, the update will fail.

    [Note]Note

    XenCenter will reboot each host automatically (as part of the Install Update wizard), before applying the update file. If you are using the xe CLI, you will have to reboot hosts manually.

  • Citrix also strongly recommends that you take a backup of the state of the pool (or individual hosts) that you wish to update, just as you would with any other maintenance operations. For backup procedures, see the XenServer Administrator's Guide.

Before you begin updating:

If you are applying an update or hotfix using XenCenter, XenCenter runs a series of prechecks to ensure that the selected hosts are prepared to be updated and compatible with the required update file. These prechecks are run as part of the procedure that the Install Update wizard guides you through. Prechecks alert you if any preparatory o have been missed.

7.2. Updating Individual XenServer Hosts

To update individual hosts using XenCenter:

  1. Download the update file (.xsupdate file extension) to a known location on the computer running XenCenter.

  2. Shut down or suspend any VMs on the host(s) that you wish to update.

  3. On the Tools menu, select Install New Update. The Install Update wizard opens.

  4. Read the Before you start information, and then click Next to proceed.

  5. Select Add, and then browse to and select the update file that you have downloaded. Click Open.

    Once the update file has been added, click Next to continue.

  6. Select one or more host(s) to update. Select Next.

  7. Follow the recommendations to resolve any update prechecks that have failed.

    If you would like XenCenter to automatically resolve all failed prechecks, click Resolve All.

    Once all prechecks have been resolved, select Next to continue.

  8. Choose between automatic or manual update mode.

    If you choose automatic, XenCenter will perform any post-update actions that may be required (such as rebooting the host). If you choose manual, you will need to perform the actions manually. The post-update actions required are listed in the text box below. If you wish to save the listed actions to a text file for your reference, click Save to File.

    Select Install update to proceed with the installation.

    The Install Update wizard shows the progress of the update, printing the major operations that XenCenter performs while updating each host.

  9. Once the update is finished, select Finish to close the Install Update wizard.

  10. If you chose to manually perform post-update actions, do so now.

To update individual hosts using the xe CLI:

  1. Download the update file (.xsupdate file extension) to a known location on the computer running the xe CLI. Note the path to the file.

  2. Shut down or suspend any VMs on the host(s) that you wish to update by using the vm-shutdown or vm-suspend commands.

  3. Upload the update file to the host you wish to update by running the following:

    xe -s <server> -u <username> -pw <password> patch-upload file-name=<filename>

    Here, -s refers to the hostname. XenServer assigns the update file a UUID, which this command prints. Note the UUID.

    [Tip]Tip

    Once an update file has been uploaded to a XenServer host, you can use the patch-list and patch-param-list commands to view information about the update file.

  4. If XenServer detects any errors or preparatory steps that have not been taken (for example, VMs are running on the host), it alerts you. Be sure to follow any guidance before continuing with the update.

  5. Update the host, specifying the UUIDs of the host and the update file, by running the following:

    xe patch-apply host-uuid=<UUID_of_host> uuid=<UUID_of_file>
  6. Verify that the update has been successfully applied by using the patch-list command. If the update has been successful, the hosts field contains the host UUID.

  7. Perform any post-update operations, as necessary (such as, rebooting the host).

7.3. Updating a Pool of XenServer Hosts

When updating a pool of XenServer hosts in XenCenter, the Install Update wizard takes care of the update path and VM migration automatically. If you need to control the update path and VM migration manually, you can update each host individually. To do so, follow the general procedures in Section 7.2, “Updating Individual XenServer Hosts”. Be sure to start by updating the pool master first.

To update a pool of hosts using XenCenter:

  1. Download the update file to a known location (.xsupdate file extension) on the computer running XenCenter.

  2. If there are any VMs in the pool that you wish to shut down or suspend, rather than allow XenCenter to automatically migrate, do so now.

  3. On the Tools menu, select Install New Update. The Install Update wizard opens.

  4. Read the Before you start information, and then click Next to proceed.

  5. Select Add, and then browse to and select the update file that you have downloaded. Click Open.

    Once the update file has been added, click Next to continue.

  6. Select the pool that you wish to update. Select Next.

  7. Follow the recommendations to resolve any update prechecks that have failed.

    If you would like XenCenter to automatically resolve all failed prechecks, click Resolve All.

    Once all prechecks have been resolved, select Next to continue.

  8. Choose between automatic or manual update mode.

    If you choose automatic, XenCenter will perform any post-update actions that may be required (such as rebooting hosts). If you choose manual, you will need to perform the actions manually. The post-update actions required are listed in the text box below. If you wish to save the listed actions to a text file for your reference, click Save to File.

    Select Install update to proceed with the installation.

    The Install Update wizard shows the progress of the update, printing the major operations that XenCenter performs while updating each host in the pool.

    While the pool master is being updated, XenCenter will usually lose contact with the pool, temporarily.

  9. Once the update is finished, select Finish to close the Install Update wizard.

  10. If you chose to manually perform post-update actions, do so now.

To update a pool of XenServer hosts using the xe CLI:

  1. Download the update file (.xsupdate file extension) to a known location on the computer running the xe CLI. Note the path to the file.

  2. Upload the update file to the pool you wish to update by running the following:

    xe -s <server> -u <username> -pw <password> patch-upload file-name=<filename>

    Here, -s refers to the name of the pool master. XenServer assigns the update file a UUID, which this command prints. Note the UUID.

    [Tip]Tip

    Once an update file has been uploaded to a XenServer host, you can use the patch-list and patch-param-list commands to view information about the file.

  3. If XenServer detects any errors or preparatory steps that have not been taken (for example, VMs are running in the pool), it alerts you. Be sure to follow any guidance before continuing with the update.

    If necessary, you can shut down or suspend any VMs on the host(s) that you wish to update by using the vm-shutdown or vm-suspend commands.

    To migrate specified VMs to specified hosts, use the vm-migrate command. By using the vm-migrate command, you will have full control over the distribution of migrated VMs to other hosts in the pool.

    To automatically live migrate all VMs to other hosts in the pool, use the host-evacuate command. By using the host-evacuate command, you leave the distribution of migrated VMs to XenServer.

  4. Update the pool, specifying the UUID of the update file, by running the following:

    xe patch-pool-apply uuid=<UUID_of_file>

    This applies the update or hotfix to all hosts in the pool.

    Alternatively, if you need to update and restart hosts in a rolling manner, you can apply the update file to an individual host by running the following:

    xe patch-apply host-uuid=<UUID_of_host> uuid=<UUID_of_file>
  5. Verify that the update was applied by using the patch-list command. If the update has been successful, the hosts field contains the host UUID.

  6. Perform any post-update operations, as necessary (such as, rebooting the hosts).

[Note]Note

If you need to reclaim space on the pool master, large update files can be deleted from the disk by using the patch-clean command. The update information stored in the database of the master is always retained. If required, these files can be uploaded again using the patch-upload command.

Chapter 8. Licensing XenServer

[Important]Important

Licensing XenServer has changed in this release. XenServer 5.6 Service Pack 2 Advanced Edition or higher requires a Citrix License Server (11.6 or higher) to run. To license these editions, you must configure Citrix Licensing and the licensing settings inside each XenServer host.

After you install a XenServer host, it runs as XenServer (Free) for 30 days. After this period, you cannot start any new, suspended, or powered-off VMs until you activate it (to continue using the free XenServer product) or configure Citrix Licensing for it (to use XenServer Advanced editions and higher).

If you are upgrading from XenServer Essentials 5.5, regardless of whether or not you have a valid Subscription Advantage agreement, you must follow the steps in Section 8.2, “Licensing XenServer Editions”.

For information on the features included in each XenServer edition, visit www.citrix.com/xenserver.

8.1. Activating a Free XenServer Product

XenServer is available for free production use with no restrictions or time limits — all you need to do is activate the product within 30 days of first installing it, and then on an annual basis, to register your intent to use it with Citrix. Activation only takes a few minutes.

To activate a free XenServer product:

  1. Request an activation key from Citrix using XenCenter.

    1. On the Tools menu, select License Manager.

    2. Select one or more host(s) that you wish to activate. Click Activate Free XenServer and then select Request Activation Key.

      XenCenter opens a web browser and takes you to the Citrix XenServer Activation page.

      [Note]Note

      If XenCenter is unable to connect to the activation page (because the internet connection is down, for example), then XenCenter gives you the option to save a .txt file locally with the activation request information. You can then upload this .txt file to https://activate.vmd.citrix.com at a later date.

    3. Enter your details in the activation form, and then click Submit.

      An e-mail with the activation key (.xslic file extension) will be sent to you shortly.

      Generally, activation keys are generated and e-mailed within 10 minutes. However, it may take up to 30 minutes in some cases.

    4. Save the attached activation key to a known location on the computer running XenCenter or the xe CLI.

  2. Apply the activation key to your XenServer host using XenCenter or the xe CLI.

    To apply an activation key using XenCenter:

    1. On the Tools menu, select License Manager.

      You can also launch the XenCenter License Manager by double-clicking the activation key file in Windows Explorer.

    2. Select the host you wish activate (you can only activate one host at a time). Click Activate Free XenServer, and then select Apply Activation Key.

    3. Browse to and select the activation key file, and select Open.

    To install an activation key using the xe CLI, open a console on the host (or connect to the host via SSH) and run the following command:

    xe host-license-add [license-file=<<path/license_filename>>]

8.2. Licensing XenServer Editions

XenServer Advanced, Enterprise, and Platinum editions use the same licensing model as other Citrix products.

XenServer Advanced editions and higher require a license for each XenServer host you use. From this XenServer release forward, licenses will no longer be stored on the host server. Instead, all XenServer editions licenses must be added to and administered from a Citrix Licensing Server and maintained and controlled using the Citrix License Management Console. You can share the license server across all Citrix products.

Each XenServer host requires a license, but this does not limit the number of users that may connect to VMs on that host. While licensing must be configured for each XenServer host, the XenCenter License Manager allows you to apply the same settings to multiple hosts at once.

To license XenServer Advanced editions and higher:

  1. Install the Citrix License Server and console.

    For installation procedures, see the licensing topics in Citrix eDocs. This XenServer release requires Citrix Licensing 11.6.1 or higher.

  2. Obtain your XenServer license files and load them on the Citrix License Server. For these procedures, see the licensing topics in Citrix eDocs.

  3. Configure licensing for each XenServer host using XenCenter or the xe CLI.

To configure licensing for XenServer hosts using XenCenter:

  1. On the Tools menu, select License Manager.

  2. Select one or more host(s) that you wish to assign a license. Click Assign License. The Apply License dialog box opens.

  3. In the Apply License dialog box, choose the XenServer license edition and then enter the Citrix Licensing Server details.

    [Note]Note

    27000 is the port that the licensing server uses by default for communication with Citrix products. If you changed the default port on the licensing server, enter the new number in the Port number box. For more information about changing port numbers due to conflicts, see the licensing topics in Citrix eDocs.

    Select OK to proceed.

    XenCenter contacts the specified license server and checks out a license for the specified host(s). The information shown in the XenCenter License Manager will be updated.

To release a license (to set a licensed host to the free XenServer edition): from the License Manager, select a host, and then click Release License.

To configure licensing for XenServer hosts using the xe CLI:

  • Run the host-apply-edition command. For example, enter the following:

    xe host-apply-edition edition=advanced|enterprise|platinum|enterprise-xd  \  
      license-server-address=<license_server_address> host-uuid=<uuid_of_host> \
      license-server-port=<license_server_port>

    You only need to supply the license server IP address and port number parameters the first time you assign a license. The values are stored and used automatically if you do not specify the license server parameters in the future.

    If no host UUID is specified, the license will be applied to the host that you are running the command on.

8.3. Additional Licensing Information

This section discusses miscellaneous licensing information, such as license expiration and grace periods.

A few additional points about XenServer licensing:

  • After upgrading a XenServer host (paid-for edition), the host enters a 30-day grace period during which it is licensed as an Enterprise edition product. As soon as you assign the host a new license (or you activate the free XenServer product), the grace period ends and XenServer will run with the features associated with the edition you have specified.

  • If you purchased XenServer Essentials 5.5 and are running LabManager, these components do not have a start-up licensing grace period. Before upgrading these components, you must download their XenServer Platinum license key from My Citrix.com.

8.3.1. Licensing Expiration and Grace Period

Expiration

If the license for a XenServer host expires, you cannot start any new, suspended, or powered off VMs on that host until you re-assign it a valid license.

If you are running the free XenServer product, you need to re-activate it on an annual basis. If it expires, you cannot start any new, suspended, or powered off VMs on that host until you re-activate it.

Grace Period

After a license is checked out by a XenServer host, the host and the license server exchange "heartbeat" messages every five minutes to indicate to each other that they are still up and running. If XenServer and the license server fail to send or receive heartbeats (for example, due to problems with the license server hardware or software, or network failures), XenServer lapses into the licensing grace period of 30 days and licenses itself through cached information.

If the grace period expires, the VMs running on that host do not stop. However, you cannot start new VMs on that host until you restore its connection with the license server.

8.3.2. Mixed Pools

Citrix strongly discourages running mixed pools — pools with members that have different licenses — for any longer than necessary. Temporarily running a mixed pool for transitional purposes (for example, while upgrading your licenses) is supported, but functionality may be limited. It is important to keep the following in mind:

  • While you can change the license of any host in a pool, the host with the lowest license determines the features available to all members in the pool. For example, a pool with a mixture of Advanced and Platinum Edition hosts only has Advanced features enabled. Therefore, if you change a host to use a lower level of license, you can effectively disable features in the pool.

  • Any host joining a pool must have the same license as the host with the lowest edition license in the pool. For example, in a pool that contains hosts with Advanced and Platinum licenses, a joining host must have an Advanced license.

  • In XenCenter, if you add a free XenServer to a pool whose master is licensed (with Advanced, Enterprise, or Platinum), you are prompted to upgrade the license of the joining host to match that of the pool master. You have to do this to add the host to the pool, otherwise you cannot add the host to the pool.

Appendix A. Troubleshooting

Citrix provides two forms of support: free, self-help support on the Citrix Support Site and paid-for Support Services, which you can purchase from the Support Site. With Citrix Technical Support, you can open a Support Case online or contact the support center by phone if you experience technical difficulties during installation.

The Citrix Knowledge Center hosts a number of resources that may be helpful to you if you experience odd behavior, crashes, or other problems during installation. Resources include: Support Forums, Knowledge Base articles and product documentation.

In most cases, if you experience an unknown error during installation, Citrix Technical Support will request that you capture the log file from your host and then send it along for the Support team to inspect. If requested, follow the procedure below.

Using a keyboard connected directly to the host machine (not connected over a serial port), you can access three virtual terminals during installation:

  • Press Alt+F1 to access the main XenServer Installer

  • Press Alt+F2 to access a local shell

  • Press Alt+F3 to access the event log

To capture and save the log file:

  1. Press Alt+F2 to access the local shell.

  2. Enter the following:

    /opt/xensource/installer/report.py
  3. You are prompted to choose where you would like to save the log file: NFS, FTP or Local media.

    Select NFS or FTP to copy the log file to another machine on your network. To do so, networking must be working properly, and you must have write access to a remote machine.

    Select Local media to save the file to a removable storage device, such as a USB flash drive, on the local machine.

    Once you have made your selections, the program writes the log file to your chosen location. The filename is support.tar.bz2.

Appendix B. Boot From SAN Environments

Boot from SAN environments offer a number of advantages, including high performance, redundancy and space consolidation. In these environments, the boot disk resides on a remote SAN, and not on the local host. The diskless host communicates with the SAN through a host bus adapter (HBA), and the BIOS of the HBA contains the instructions that enable the host to find the boot disk.

Boot from SAN depends on SAN-based disk arrays with either hardware Fibre Channel or HBA iSCSI adapter support on the host. For a fully redundant boot from SAN environment, you need to configure multiple paths for I/O access. To do so, the root device should have multipath support enabled. For information on multipath availability for your SAN environment, consult your storage vendor or administrator. If you have multiple paths available, then you can enable multipathing in your XenServer deployment upon installation.

To install XenServer to a remote disk on a SAN with multipathing enabled:

  1. On the Welcome to XenServer screen, press F2.

  2. At the boot prompt, enter multipath

XenServer boots to a remote disk on a SAN with multipathing enabled.

To enable filesystem multipathing using PXE installation, you need to add device_mapper_multipath=yes to the PXE Linux configuration file. An example configuration is as follows:

default xenserver
label xenserver
  kernel mboot.c32
  append /tftpboot/xenserver/xen.gz dom0_mem=752M com1=115200,8n1 \
  console=com1,vga --- /tftpboot/xenserver/vmlinuz \
  xencons=hvc console=hvc0 console=tty0 \ 
  device_mapper_multipath=yes \
  --- /tftpboot/xenserver/install.img

For additional information on storage multipathing in your XenServer environment, please see the XenServer Administrator's Guide.

Appendix C. PXE Boot Installations

This appendix describes how to configure your PXE environment for XenServer installation. It steps through setting up your TFTP and NFS, FTP or HTTP servers to enable PXE booting of XenServer host installations. It then describes how to create an XML answer file, which allows you to perform unattended installations.

C.1. Configuring your PXE Environment for XenServer Installation

Before you set up the XenServer installation media, you need to configure your TFTP and DHCP servers. For general setup procedures, see the Citrix Knowledge Base article PXE Boot Environment: Generic TFTP and DHCP Configuration.

In addition to the TFTP and DHCP servers, you need an NFS, FTP, or HTTP server to house the XenServer installation files. These servers can co-exist on one, or be distributed across different servers on the network.

Additionally, each XenServer host that you want to PXE boot needs a PXE boot-enabled Ethernet card.

The following steps assume that the Linux server you are using has RPM support.

To configure your TFTP server:

  1. In the /tftpboot directory, create a new directory called xenserver.

  2. Copy the mboot.c32 and pxelinux.0 files from the /usr/lib/syslinux directory to the /tftboot directory.

  3. From the XenServer installation media, copy the files install.img (from the root directory), vmlinuz and xen.gz (from the /boot directory) to the new /tftpboot/xenserver directory on the TFTP server.

  4. In the /tftboot directory, create a new directory called pxelinux.cfg.

  5. In the pxelinux.cfg directory, create your new configuration file called default.

    The content of this file depends on how you want to configure your PXE boot environment. Two sample configurations are listed below. The first example configuration starts an installation on any machine that boots from the TFTP server and leaves you to manually respond to the installation prompts. The second performs an unattended installation.

    [Note]Note

    The following examples show how to configure the installer to run on the physical console, tty0. To use a different default, ensure that the console you want to use is the rightmost.

    default xenserver
    label xenserver
    	kernel mboot.c32
    	append /tftpboot/xenserver/xen.gz dom0_max_vcpus=2 dom0_mem=752M com1=115200,8n1 \
    	console=com1,vga --- /tftpboot/xenserver/vmlinuz \
    	xencons=hvc console=hvc0 console=tty0 \
    	--- /tftpboot/xenserver/install.img

    A sample configuration that performs an unattended installation using the answer file at the URL specified:

    [Note]Note

    To specify which network adapter should be used for retrieving the answer file, include the answerfile_device=ethX or answerfile_device=MAC parameter and specify either the ethernet device number or the MAC address of the device.

    default xenserver-auto
    label xenserver-auto
       kernel mboot.c32
       append /tftpboot/xenserver/xen.gz dom0_max_vcpus=2 dom0_mem=752M com1=115200,8n1 \
          console=com1,vga --- /tftpboot/xenserver/vmlinuz \
          xencons=hvc console=hvc0 console=tty0 \
          answerfile=http://pxehost.example.com/-answerfile \
          install --- /tftpboot/xenserver/install.img

    For more information on PXE configuration file syntax, see the SYSLINUX website.

Please refer to your server operating system manual for details for your specific operating system. The information here is a guide that can be used for Red Hat, Fedora, and some other RPM-based distributions.

To set up the XenServer installation media on a HTTP, FTP, or NFS server:

  1. On the server, create a new directory from which the XenServer installation media can be exported via HTTP, FTP or NFS.

    For example, in the document root of a webserver, create a directory called XS56SP2.

  2. From the XenServer installation media, copy the content of the packages.main directory to the newly-created directory on the HTTP, FTP or NFS server (for example, copy to XS56SP2/packages.main).

  3. To add Linux support, copy the content of the packages.linux directory from the Linux Support installation media to the newly-created directory on the HTTP, FTP or NFS server (for example, copy to XS56SP2/packages.linux).

By copying the XenServer and Linux Support installation media to the same directory on the server, you have the flexibility to configure your answer file (for an unattended PXE installations) to install either both packages or only the XenServer installation package depending on how you write the source element.

For example, to install both packages from a webserver called http://pxehost.example.com, you might write the source element of the answer file as follows:

<source type="url">http://pxehost.example.com/XS56SP2</source>

To install only the XenServer installation media, you might write the source element of the answer file as follows:

<source type="url">http://pxehost.example.com/XS56SP2/packages.main</source>

In either case, you can also specify a username and password if required. For example:

<source type="url">
http://<username>:<password>@pxehost.example.com/XS56SP2/packages.main
<source>

To make Supplemental Packs available during installation copy the contents of each Pack ISO into a separate directory in the main installation repository. For example, copy the files in helloworld.iso to Xenserver-/driver.helloworld. For unattended install of a Supplemental Pack, create an answer file as described in Section C.2, “Creating an answer file for unattended PXE installation”.

Preparing the destination system

  1. Start the system and enter the Boot Menu (F12 in most BIOS programs) and select to boot from your Ethernet card.

  2. The system should then PXE boot from the installation source you set up, and the installation script will commence. If you have set up an answer file, the installation can proceed unattended.

C.2. Creating an answer file for unattended PXE installation

To perform installations in an unattended fashion, you need to create an XML answer file. Here is an example answer file:

<?xml version="1.0"?>
   <installation srtype="ext">
      <primary-disk>sda</primary-disk>
      <guest-disk>sdb</guest-disk>
      <guest-disk>sdc</guest-disk>
      <keymap>us</keymap>
      <root-password>mypassword</root-password>
      <source type="url">http://pxehost.example.com/XenServer_/</source>
	  <post-install-script type="url">
	  http://pxehost.example.com/myscripts/post-install-script
	  </post-install-script>
      <admin-interface name="eth0" proto="dhcp" />
      <timezone>Europe/London</timezone>
   </installation>

All nodes should be within a root node named installation.

[Note]Note

If you wish to enable Thin Provisioning, you can specify an srtype attribute as ext. If this attribute is not specified, the default local storage type is LVM. Thin Provisioning sets the local storage type to EXT3 and enables local caching for XenDesktop to work properly. For details, see Chapter 6, XenServer and IntelliCache.

The following is a summary of the elements. All values should be text in the nodes, unless otherwise stated. Required elements are indicated.

ElementDescriptionRequired?
<primary-disk>The name of the storage device where the control domain should be installed, equivalent to the choice made on the Select Primary Disk step of the interactive installation process.

Attributes:

You can 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 you specify no, it is possible to automate an installation scenario where no storage repository is created, if, in addition, no guest-disk keys are specified.

Y
<guest-disk>The name of a storage device to be used for storing guests. You should use one of these elements for each extra disk.N
<keymap>The name of the keymap to use during installation.

<keymap>us</keymap>

Y
<root-password>The desired root password for the XenServer host. If a password is not provided a prompt will be displayed when the host is first booted.N
<source>Where the packages should be installed from.

Attributes:

type: url, nfs, or local

If local, leave the element empty. For example,

<source type="url">
http://server/packages
</source>
<source type="local" />
<source type="nfs">
server:packages
</source>
Y
<driver-source>Where the Supplemental Packs containing device drivers should be installed from. Optional. Element may occur multiple times.

Attributes:

type: url, nfs, or local

If local, leave the element empty. For example,

<driver-source type="url">
http://server/drivers
</driver-source>
<driver-source type="local" />
<driver-source type="nfs">
server:drivers
</driver-source>
N
<script>Where the post-install-script is.

Attributes:

stage: filesystem-populated, or installation-complete

When filesystem-populated is used, the script is invoked just before root file system is unmounted (for example, after installation/upgrade, initrds already built, etc.). The script will receive an argument that is the mount point of the root file system.

When installation-complete is used, the script will be run once the installer has finished all operations (and hence the root file system will be unmounted). The script will receive an argument that will have a value of zero if the installation completed successfully, and will be non-zero if the installation failed for any reason.

type: url, nfs, or local

If url or nfs, put the URL or NFS path in the PCDATA; if local, leave the PCDATA empty. For example,

<script stage="filesystem-populated"
   type="url">
http://prehost.example.com/post-install-script
</script>
<script stage="installation-complete"
   type="nfs">
server:/scripts/installation-pass-fail-script
</script>
<script stage="installation-complete"
    type="local">
file:///scripts/run.sh
</script>
Note that if a local file is used, ensure that the path is absolute. This will generally mean that the file:// prefix will be followed by a further forward slash, and the complete path to the script.
N
<admin-interface>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, for example Europe/London, or America/Los_Angeles.Y
<nameserver>The IP address of a nameserver. You should use one of these elements for each nameserver you want to use.N
<hostname>Specify if you want to manually set a hostname.N
<bootloader>Specify which bootloader to install for startup time. Only change this if you have problems booting. Currently either extlinux (the default) or grub.N

You can also perform automated upgrades by changing the answer file appropriately. Set the mode attribute of the installation element to upgrade, specify the disk on which the existing installation lives with the existing-installation element, and leave the primary-disk and guest-disk elements unspecified. For example:

<?xml version="1.0"?>
   <installation mode="upgrade">
      <existing-installation>sda</existing-installation>
      <source type="url">http://pxehost.example.com/XenServer_/</source>
	  <post-install-script type="url">
	  http://pxehost.example.com/myscripts/post-install-script
	  </post-install-script>
   </installation>