Citrix XenServer ® 7.1 Cumulative Update 1 Installation

Citrix XenServer ® 7.1 Cumulative Update 1 Installation
Guide
Published October 2017
1.0 Edition
Citrix XenServer ® 7.1 Cumulative Update 1 Installation Guide
Copyright © 2017 Citrix Systems. Inc. All Rights Reserved.
Version: 7.1.1
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 ®
Contents
1. Welcome ........................................................................................................ 1
1.1. About This Document ................................................................................................... 1
1.2. Using This Document .................................................................................................... 1
1.3. Introducing XenServer .................................................................................................. 1
1.3.1. Benefits of Using XenServer ............................................................................... 1
1.3.2. Administering XenServer .................................................................................... 2
1.4. XenServer Documentation ............................................................................................ 2
2. System Requirements .................................................................................... 3
2.1. System Requirements ................................................................................................... 3
2.1.1. XenServer Host System Requirements ................................................................. 3
2.1.2. XenCenter System Requirements ........................................................................ 4
2.1.3. Supported Guest Operating Systems ................................................................... 4
3. Licensing XenServer ....................................................................................... 5
3.1. Additional Licensing Information ................................................................................... 7
4. Installing XenServer and XenCenter .............................................................. 8
4.1. Installation Media and Methods .................................................................................... 8
4.2. Installing the XenServer host ......................................................................................... 9
4.2.1. XenServer host Partition Layout ........................................................................ 12
4.3. Installing XenCenter .................................................................................................... 14
4.4. Connecting XenCenter to the XenServer host ............................................................... 14
5. Installation and Deployment Scenarios ....................................................... 15
5.1. XenServer hosts with Local Storage ............................................................................. 15
5.2. Pools of XenServer hosts with Shared Storage .............................................................. 16
5.2.1. XenServer hosts with Shared NFS Storage ......................................................... 16
5.2.2. XenServer hosts with Shared iSCSI Storage ........................................................ 17
6. XenServer and IntelliCache .......................................................................... 20
6.1. IntelliCache Deployment ............................................................................................. 20
6.1.1. Enabling on Host Installation ............................................................................ 20
iii
6.1.2. Converting an Existing Host to Use Thin Provisioning ......................................... 21
6.1.3. VM Boot Behavior ........................................................................................... 22
6.1.3.1. VM Caching Behavior Settings ............................................................... 22
6.1.3.1.1. Shared Desktop Mode ................................................................ 22
6.1.3.1.2. Private Desktop Mode ................................................................ 22
6.1.4. Implementation Details and Troubleshooting .................................................... 22
7. Upgrading XenServer ................................................................................... 24
7.1. Rolling Pool Upgrades ................................................................................................. 24
7.1.1. Upgrading XenServer hosts Using the XenCenter Rolling Pool Upgrade
Wizard ...................................................................................................................... 25
7.1.2. Upgrading XenServer hosts Using the xe CLI ...................................................... 26
7.1.2.1. Planning an Upgrade Path ..................................................................... 26
7.1.2.2. Performing Rolling Pool Upgrades Using the xe CLI .................................. 27
7.2. Upgrading a Single XenServer host Using the xe CLI ...................................................... 28
7.2.1. Before You Upgrade a Single XenServer host ..................................................... 28
7.2.2. Upgrading a Single XenServer host Using the xe CLI ........................................... 29
8. Applying Updates to XenServer ................................................................... 30
8.1. Preparing a Pool for an Update ................................................................................... 30
8.2. Applying Updates to a Pool ......................................................................................... 31
8.2.1. Applying Updates Automatically ....................................................................... 31
8.2.2. Applying an Update to a Pool ........................................................................... 31
8.2.3. Updating a Pool of XenServer hosts Using the xe CLI .......................................... 32
8.2.4. Updating Individual Hosts Using the xe CLI ........................................................ 33
8.3. Live Patching in XenServer .......................................................................................... 33
8.3.1. Live Patching Scenarios .................................................................................... 34
8.3.2. Applying Automated Updates and Live Patching ................................................ 34
8.3.3. Enabling Live Patching using XenCenter and the xe CLI ....................................... 34
8.4. Applying Automated Updates ...................................................................................... 35
A. Troubleshooting ........................................................................................... 37
B. Boot From SAN Environments ..................................................................... 38
iv
B.1. Software-boot-from-iSCSI for Cisco UCS ....................................................................... 38
B.1.1. Installing XenServer Using CD Media ................................................................ 39
B.1.2. Installing XenServer Using PXE .......................................................................... 39
C. Network Boot Installations .......................................................................... 41
C.1. Configuring your PXE and UEFI Environment for XenServer Installation .......................... 41
C.2. Creating an answer file for unattended PXE and UEFI installation .................................. 44
D. Installing XenServer on Small Devices ......................................................... 48
v
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. Using This Document
XenServer 7.1 Cumulative Update 1 is provided as both an update to XenServer 7.1 and as a base installation that
can be used to upgrade other versions of XenServer or to create a fresh installation.
If you are updating an existing installation of XenServer 7.1:
•
Use the XenServer 7.1 Cumulative Update 1 Installation file
•
Review the information in Chapter 8, Applying Updates to XenServer before updating your XenServer
installation.
If you are creating a fresh installation of XenServer 7.1 Cumulative Update 1:
•
Use the XenServer 7.1 Base Installation ISO including Cumulative Update 1 file
•
Review the information in Chapter 2, System Requirements, Chapter 3, Licensing XenServer, and Chapter 4,
Installing XenServer and XenCenter before installing XenServer.
If you are upgrading an existing installation of XenServer 6.2.0, 6.5.0, or 7.0:
•
Use the XenServer 7.1 Base Installation ISO including Cumulative Update 1 file
•
Review the information in Chapter 2, System Requirements and Chapter 7, Upgrading XenServer before
upgrading your XenServer installation.
1.3. Introducing XenServer
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, visit www.citrix.com/xenserver.
1.3.1. Benefits of Using XenServer
Using XenServer reduces costs by:
•
Consolidating multiple VMs onto physical servers
1
•
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.3.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 on-line Help is a useful resource for getting started with XenCenter and for context-sensitive
assistance.
The XenServer Command-line Interface (CLI) allows you to administer XenServer using the Linux-based xe
commands.
1.4. XenServer Documentation
XenServer documentation shipped with this release includes:
•
XenServer Release Notes cover new features in XenServer 7.1 and any advisories and 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 User's 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's Guide is a comprehensive user guide to the vSwitch 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 Product Documentation website.
2
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.
Warning:
The installation of any third party software directly on the XenServer host (i.e. into the dom0
control domain) is not supported, except where it is supplied as an update package and is
explicitly endorsed by Citrix.
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.
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 XenServer hardware compatibility list, see http://
www.citrix.com/xenserver/hcl. The following describes the recommended XenServer hardware specifications.
The XenServer host must be a 64-bit x86 server-class machine devoted to hosting VMs. XenServer creates 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 5TB of RAM
•
up to 16 NICs
•
up to 288 logical processors per host.
Note:
The maximum number of logical processors supported differs by CPU. Consult the XenServer
Hardware Compatibility List (HCL) for more details.
The system requirements for the XenServer host are:
CPUs
One or more 64-bit x86 CPU(s), 1.5GHz 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:
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.
3
RAM
2GB minimum, 4GB or more recommended
Disk Space
Locally attached storage (PATA, SATA, SCSI) with 46GB of disk space minimum, 70GB of disk
space recommended, or SAN via HBA (not through software) if installing with multipath boot
from SAN(see http://hcl.vmd.citrix.com for a detailed list of compatible storage solutions).
Network
100Mbit/s or faster NIC. One or more gigabit, or 10 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.
Note:
Ensure that the time setting in the BIOS of your server is set to the current time in UTC.
Note:
In some support cases, serial console access is required for debug purposes. Therefore,
when setting up a XenServer configuration, it is recommended that serial console access is
configured. For hosts that do not have physical serial port (such as a Blade server) or where
suitable physical infrastructure is not available, customers should investigate if an embedded
management device, such as Dell DRAC or HP iLO can be configured. For more information
on setting up serial console access, see CTX228930, How to Configure Serial Console Access
on XenServer 7.0 and later.
2.1.2. XenCenter System Requirements
The system requirements for XenCenter are:
Operating
System
Windows 10, Windows 8.1, Windows 8, Windows 7 SP1, Windows Vista SP2, Windows
Server 2012R2, Windows Server 2012, Windows Server 2008R2 SP1, Windows Server 2008
SP2
.NET
Framework
Version 4.6
CPU Speed
750MHz minimum, 1GHz or faster recommended
RAM
1GB minimum, 2GB or more recommended
Disk Space
100MB minimum
Network
100Mb or faster NIC
Screen
Resolution
1024x768 pixels, minimum
XenCenter is compatible with all versions of XenServer from 6.0 onwards.
2.1.3. Supported Guest Operating Systems
For a list of supported VM operating systems, see the XenServer Virtual Machine User's Guide.
4
Chapter 3. Licensing XenServer
XenServer 7.1 is available in two commercial editions:
•
Standard
•
Enterprise
The Standard edition is our entry-level commercial offering, with a range of features that will suit the needs of
those customers who want a robust and high performing virtualization platform, but do not require the premium
features offered by the Enterprise edition; while still wishing to benefit from the assurance of comprehensive
Citrix support and maintenance.
The Enterprise edition is our premium offering, optimized for desktop, server and cloud workloads. In addition
to the Standard edition, the Enterprise edition offers the following features:
•
Automated Windows VM Driver Updates
•
Automatic updating of the Management Agent
•
Support for SMB storage
•
Direct Inspect APIs
•
Dynamic Workload Balancing
•
GPU Virtualization (vGPU) with NVIDIA GRID and Intel GVT-g
•
VMware vSphere to XenServer Conversion utilities
•
Intel Secure Measured Boot (TXT)
•
Export Pool Resource Data
•
In-memory Read Caching
•
PVS-Accelerator
•
Automated Updates using XenCenter
•
XenServer Live Patching
Customers who have purchased XenApp or XenDesktop continue to have an entitlement to XenServer, which
includes all the features listed above. Note that in XenServer 7.1, all XenApp/XenDesktop customers are able to
use the In-memory Read Caching feature (previously available to Platinum customers only).
Applying a license
XenServer uses the same licensing mechanism, as used by many other Citrix products. XenServer 7.1 licensing
requires Citrix License Server 11.13.1.2 or higher. You can download the License Server from Citrix Licensing. After
purchasing a license, you will be provided with a .LIC license key. This license key should be installed on either:
•
a Windows server running the Citrix License Server software.
•
the Linux-based Citrix License Server virtual appliance.
Customers should allocate product licenses using a Citrix License Server, as with other Citrix components. From
version 6.2.0 onwards, XenServer (other than through the XenDesktop licenses) is licensed on a per-socket basis.
Allocation of licenses is managed centrally and enforced by a standalone Citrix License Server, physical or virtual,
in the environment. After applying a per-socket license, XenServer will display as Citrix XenServer Per-Socket
Edition. All hosts in a pool must be licensed. Mixed pools of licensed and unlicensed hosts will behave as if all
hosts were unlicensed.
Note:
Upgrades to the Enterprise edition are available from the Standard edition. Click here to
purchase a XenServer 7.1 license.
5
For instructions on applying a XenServer license to a Citrix License Server Virtual Appliance, see CTX200159.
To license Citrix XenServer:
1.
Install the Citrix License Server and console.
For detailed installation procedures, see Licensing on the Citrix Product Documentation website.
2.
Obtain your Citrix XenServer license files and load them on the Citrix License Server.
3.
Configure licensing for each Citrix XenServer host using XenCenter or the xe CLI.
How to configure licensing for Citrix XenServer hosts using XenCenter
Fore more information on using XenCenter press F1 to access the context sensitive Online Help.
1.
On the Tools menu, select License Manager.
2.
Select the host(s) or pool/s that you wish to assign a license. Click Assign License.
This displays the Apply License window:
3.
In the Apply License window, choose the Citrix XenServer edition that you wish to license, and then enter
the Citrix License Server details.
Note:
By default, the License Server uses port 27000 for communication with Citrix products. If you
changed the default port on the License Server, enter the appropriate number in the Port
number box. For more information about changing port numbers due to conflicts, refer to
Licensing topics on the Citrix Product Documentation website.
Select OK to proceed.
XenCenter contacts the specified License Server and checks out a license for the specified host(s) or pool/s.
The information shown in the XenCenter License Manager will be updated.
To release a license (to revert a licensed XenServer host to unlicensed XenServer): from the License Manager,
select a host, and then click Release License.
To configure licensing for Citrix XenServer hosts using the xe CLI:
•
Run the host-apply-edition command. For example, enter the following:
6
xe host-apply-edition edition= enterprise-per-socket|desktop-plus|desktop| \
standard-per-socket\ license-server-address=<license_server_address> \
host-uuid=<uuid_of_host> license-server-port=<license_server_port>
You will only need to supply the license server IP address and port number parameters for the first time you
assign a license. The values are stored and used automatically if in future, you do not specify the license server
parameters.
If no host UUID is specified, the license will be applied to the host that you are running the command on.
To configure a pool
•
Run the pool-apply-edition command. For example, enter the following:
xe pool-apply-edition edition= enterprise-per-socket|desktop-plus|desktop| \
standard-per-socket\ license-server-address=<license_server_address> \
pool-uuid=<uuid_of_pool> license-server-port=<license_server_port>
3.1. Additional Licensing Information
This section discusses miscellaneous licensing information, such as, license expiry and grace periods.
Refer to the XenServer 7.1 Licensing FAQ for more information.
License Expiry
XenCenter notifies you when your license is due to expire. You should purchase a license before it expires. When
a XenServer license expires:
•
XenCenter License Manager will display the status as Unlicensed.
•
you will no longer be able to access licensed features or receive Citrix Technical Support for any host within
the pool until you purchase another license.
License Grace Period
Citrix licensing has built-in timeout technology. After a startup license is checked out by a XenServer host,
XenServer and the License Server exchange "heartbeat" messages every five minutes to indicate to each other
that they are still up and running. If a XenServer host cannot contact the License Server, for example, due to
problems with the License Server hardware or software or network failures, the server lapses into a 30-day
licensing grace period. During the grace period, XenServer licenses itself through cached information and the
hosts are allowed to continue operations as if they were still in communication with the License Server. The
grace period is 30 days and when the grace period runs out, XenServer reverts to an unlicensed state. After
communication is re-established between XenServer and the License Server, the grace period is reset.
7
Chapter 4. Installing XenServer and
XenCenter
This chapter steps through installing the XenServer host software on physical servers, installing XenCenter on
Windows workstations and finally 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.
4.1. Installation Media and Methods
XenServer installs directly on bare-metal hardware avoiding the complexity, overhead, and performance
bottlenecks of an underlying operating system. It uses the device drivers available from the Linux kernel. As a
result, XenServer can run on a wide variety of hardware and storage devices. However, Citrix recommends that
you use certified device drivers; refer to the XenServer Hardware Compatibility List (HCL) for details.
The XenServer host consists of:
•
The Xen Hypervisor: The hypervisor is the basic abstraction layer of software. The hypervisor is responsible
for low-level tasks such as CPU scheduling and is responsible for memory isolation for resident VMs. The
hypervisor abstracts from the hardware for the VMs. The hypervisor has no knowledge of networking,
external storage devices, video, etc. The Linux Foundation Xen Project community develops and maintains
the Xen hypervisor as free software licensed under the GNU General Public License. XenServer 7.1 uses v4.7
of the Xen hypervisor.
•
The Control Domain: Also known as 'Domain0', or 'dom0', the Control Domain is a secure, privileged Linux
VM (based on a CentOS 7.2 distribution) that runs the XenServer management toolstack. Besides providing
XenServer management functions, the Control Domain also runs the driver stack that provides user created
Virtual Machines (VMs) access to physical devices.
•
The management toolstack: Also known as xapi, this software toolstack controls VM lifecycle operations, host
and VM networking, VM storage, user authentication, and allows the management of XenServer resource
pools. xapi provides the publicly documented XenAPI Management Interface which is used by all tools that
manage VMs and resource pools.
•
VM templates, for installing popular operating systems as VMs.
•
A local Storage Repository (SR) reserved for VMs.
Important:
The XenServer host must be installed on a dedicated 64-bit x86 server.
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
8
You can download the installer (ISO file format) and burn it to a CD. To download the installer, visit the
XenServer Downloads page.
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.
For details about setting up a TFTP server to boot the installer using network, see Appendix C, Network 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.
Supplemental Packs
You can install any 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:
Upgrading requires careful planning and attention. For detailed information about upgrading
individual XenServer hosts and pools, see Chapter 7, Upgrading XenServer.
4.2. Installing the XenServer host
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.
Warning:
Installing XenServer overwrites 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, if applicable, network-boot from your TFTP server.
2.
Following the initial boot messages and the Welcome to XenServer screen, select your keyboard layout for
the installation.
Note:
If a System Hardware warning screen is displayed and you suspect that hardware
virtualization assist support is available on your system, check the support site of your
hardware manufacturer for BIOS upgrades.
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 additional essential device drivers, press F9. The installer steps
you through installing the necessary drivers.
Warning:
9
Only update packages containing driver disks can be installed at this point in the installation
process. However, you are prompted later in the installation process to install any update
packages containing supplemental packs.
After you have installed all of the required drivers, select Ok to proceed.
XenServer enables customers to configure the XenServer installation to boot from FCoE. Press F10 and follow
the instructions displayed on the screen to set up FCoE.
Note:
Before enabling XenServer to boot from FCoE, the configuration required to expose a LUN to
the host must be completed manually, including configuring the storage fabric and allocating
LUNs to your SAN's public world wide name (PWWN). After completing this configuration,
available LUN should be mounted to the host's CNA as a SCSI device. The SCSI device can then
be used to access the LUN as if it were a locally attached SCSI device. For information about
configuring the physical switch and the array to support FCoE, refer to the documentation
provided by the vendor.
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.
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 7, 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 network, select HTTP or FTP or NFS, as
appropriate. Choose Ok to proceed.
If you select HTTP or FTP or NFS:
a.
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.
b.
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.
c.
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.
10
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:
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.
Note:
If manually specifying the hostname, enter a short hostname and not the fully qualified
domain name (FQDN). Entering an FQDN may cause external authentication to fail, or the
XenServer host may be added to AD with a different name.
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:
XenServer assumes that the time setting in the BIOS of the server is the current time in UTC.
17. Select Install XenServer.
If you choose 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 CD, the next screen asks if you want to install any supplemental packs from a CD.
If you plan to install any supplemental packs provided by your hardware supplier, choose Yes.
If you choose to install supplemental packs, you are 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.
11
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:
Make note of the IP address displayed. You will use this when you connect XenCenter to the
XenServer host.
4.2.1. XenServer host Partition Layout
XenServer 7.0 introduced a new host disk partition layout. By moving log files to a larger, separate partition,
XenServer enables more detailed logs to be held over a longer period of time, improving the ability to diagnose
issues. Simultaneously, this alleviates demands on Dom0’s root disk, and avoids potential space issues due to log
file disk space consumption. The new layout contains the following partitions:
•
18GB XenServer host control domain (dom0) partition
•
18GB backup partition
•
4GB logs partition
•
1GB swap partition
•
0.5GB UEFI boot partition
In XenServer 6.5.0 and earlier releases, the 4 GB control domain (dom0) partition was used for all dom0 functions,
including swap and logging. Customers who do not use remote syslog and those with third-party monitoring tools
and supplemental packs found the size of the partition to be limited. XenServer eliminates this issue and provides
a dedicated 18GB partition to dom0. In addition, a larger partition dedicated to dom0 reduces demand on the
dom0 root disk which can offer significant performance improvements.
The introduction of the 4GB dedicated log partition eliminates scenarios where excessive logging filled up the
dom0 partition and affected the behavior of the host. This also enables customers to retain a detailed list of logs
for a longer period of time, improving the ability to diagnose issues.
With the introduction of support for UEFI boot in XenServer, the partition layout also contains a dedicated 500MB
required for UEFI boot.
Note:
Customers installing XenServer with the new partition layout described above should ensure
they have a disk that is at least 46GB in size.
Customers who would like to install XenServer on smaller devices, that is devices with more than 12GB but less
than 46GB disk space, can perform a clean installation of XenServer using the legacy DOS partition layout. For
more information, see Appendix D, Installing XenServer on Small Devices.
Important:
Citrix recommends that you allocate a minimum of 46GB disk space and install XenServer
using the new GPT partition layout.
Upgrading to the New Partition Layout
When upgrading to XenServer 7.1 from XenServer 6.5.0 or earlier version using XenCenter, the host partition
layout will be upgraded to the new layout, provided:
12
•
There is at least 46GB of disk space on the local SR
•
There are no VDIs present on the local SR
•
You use XenCenter issued with XenServer 7.1 to perform a Rolling Pool Upgrade (RPU) to XenServer 7.1
Warning:
Customers cannot upgrade to the new host partition layout using xe CLI.
During the upgrade process, the RPU wizard checks for VDIs on the local SR. If there are any virtual disks (VDIs)
present during the upgrade process, the wizard prompts you to move the VDI. You should move VDIs on the
local SR to a shared SR and then restart the upgrade process in order to continue with the new layout. If, for any
reason, the VDIs cannot be moved, or if there is insufficient space (less than 46GB) on the local SR, the upgrade
will proceed with the old partition layout and allocates 0.5GB of disk space from the dom0 partition to UEFI boot.
Restoring the Old Partition Layout
If you plan to restore XenServer from version 7.1 to version 6.x, the host partition layout reverts to the 6.x layout.
Refer to the corresponding XenServer Administrator's Guide for details.
Legacy Partition Layouts
•
XenServer 5.6 Service Pack 2 and earlier used DOS partition tables to separate the root file system and backups
from the local storage.
•
XenServer 6.0 introduced GUID partition tables to separate root file system, backup and local storage.
•
Installing XenServer 7.1 with disable-gpt on machines with mandatory initial partition that must be
preserved, for example, the Dell Utility Partition, will continue to use the DOS partitioning scheme. Upgrades
from a XenServer 5.x release to 6.0 and then to 7.1 will continue to use the existing DOS partitioning so as
not to destroy any existing local storage.
The following table lists the installation and upgrade scenarios and the partition layout that will be applied after
these operations:
Operation
Number of partitions
before upgrade
Number of partitions
after
installation/
upgrade
Partition table type
Clean installation with at least 46GB
of primary disk space
NA
6*
New GPT
Clean installation with disablegpt with a minimum of 12GB of
primary disk space
NA
3† (4 ‡ if there is a
Utility partition)
DOS
Upgrading from XenServer 6.x to 7.1
with VMs on local SR or with less
than 46GB of primary disk space
3
4
Old GPT
Upgrading from XenServer 6.x to 7.1
without any VMs on local storage or
with more than 46GB of primary disk
space
3
6
New GPT
Upgrading from XenServer 6.x DOS
partition (and Utility partition, if any)
to XenServer 7.1
3 (4 if there is a Utility
partition)
3 (4 if there is a Utility
partition)
DOS
*
includes root, backup, local SR (if any), boot, log, and SWAP
13
†
includes root, backup, and local SR (if any)
includes root, backup, local SR (if any), and boot
‡
4.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 4.6 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 the Citrix XenServer Download page.
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:
3.
a.
Insert the CD into the DVD drive of the computer which you want to run XenCenter.
b.
Open the client_install folder on the CD. Double-click XenCenter.msi to begin the
installation.
Follow the Setup wizard, which allows you to modify the default destination folder and then to install
XenCenter.
4.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 New Server icon.
3.
Enter the IP address of the XenServer host in the Server field. Type the root username and password that
you set during XenServer installation. Click 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 main menu, select Tools and then Options. The Options dialog box opens.
Select the Save and Restore tab and set your preferences. Click OK to save your changes.
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.
14
Chapter 5. 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
5.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:
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.
15
5.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 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, ondisk 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.
5.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.
16
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:
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 deviceconfig-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.
5.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
17
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:
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:
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:
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:
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
18
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.
19
Chapter 6. XenServer and IntelliCache
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:
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:
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.
20
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:
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>
21
6.1.3. VM Boot Behavior
There are two options for the behavior 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 Behavior Settings
The VDI flag allow-caching dictates the caching behavior:
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
Q:
Is IntelliCache compatible with XenMotion and High Availability?
A:
You can use XenMotion and High Availability with IntelliCache when virtual desktops are in Private mode,
that is when on-boot=persist
Warning:
A VM cannot be migrated if any of its VDIs have caching behavior flags set to onboot=reset and allow-caching=true. Migration attempts for VMs with these
properties will fail.
Q:
Where does the local cache live on the local disk?
A:
The cache lives in a Storage Repository (SR). Each host has a configuration parameter (called local-cachesr) 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>
22
Q:
How do I specify a particular SR for use as the cache?
A:
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>
sruuid=<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:
These steps are only necessary for users who have configured more than one local SR.
Q:
When is the local cache deleted?
A:
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:
The cache file is not deleted from the host when a VM is migrated to a different host or shut
down.
23
Chapter 7. Upgrading XenServer
This chapter documents how to upgrade your XenServer deployment using XenCenter and the xe CLI. It guides you
through upgrading your XenServer hosts — both pooled and standalone — automatically (using the XenCenter
Rolling Pool Upgrade wizard) and manually.
XenServer hosts must be running at least version 6.2.0 in order to upgrade directly to version 7.1 or version 7.1
Cumulative Update 1. Customers wishing to upgrade from earlier versions of XenServer should first upgrade to
version 6.2.0, before upgrading to version 7.1 or version 7.1 Cumulative Update 1.
Note:
We recommend that you upgrade directly to the latest Cumulative Update of XenServer 7.1.
A Cumulative Update contains fixes that are not included in the initial XenServer 7.1 release.
The following table lists the upgrade path from previous versions of XenServer:
Version
Direct upgrade to XenServer 7.1?
Direct upgrade to XenServer 7.1 Cumulative
Update 1?
XenServer 7.1
Not applicable
No. Use the update mechanism instead. For
more information, see Chapter 8, Applying
Updates to XenServer.
XenServer 7.0
Yes
Yes (Recommended)
XenServer 6.5.0
Yes
Yes (Recommended)
XenServer 6.2.0
Yes
Yes (Recommended)
Note:
System administrators may prefer to perform a clean installation of the most recent version
of XenServer rather than performing one or more upgrades. VMs can be exported from all
versions of XenServer from 6.0 and directly imported into 7.1. For more information, please
refer to the Importing and Exporting VMs chapter in the Virtual Machine User's Guide.
Important:
Upgrading a XenServer host — and particularly a pool of XenServer hosts — requires careful
planning and attention. Be sure to map your upgrade path carefully, or to use the XenCenter
Rolling Pool Upgrade wizard, 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.
Important:
Boot from SAN settings are not inherited during the manual upgrade process. When
upgrading using the ISO or PXE process, customers should follow the same instructions as
used in the installation process below to ensure that multipathd is correctly configured.
For more information see Appendix B, Boot From SAN Environments.
7.1. Rolling Pool Upgrades
With XenServer, you can perform rolling pool upgrades. A rolling upgrade allows you to upgrade all of the hosts
in a pool in such a way that services and resources offered by the pool are available throughout the upgrade
process. This upgrade method keeps critical VMs running by enabling you to live migrate them to other hosts in
the pool and then to upgrade one host at a time. This process takes only one XenServer host offline at a time.
24
You can perform a rolling pool upgrade using XenCenter or the xe CLI. If you are using XenCenter, Citrix
recommends using the Rolling Pool Upgrade wizard. This wizard organizes the upgrade path automatically and
guides you through the upgrade procedure. If you are using the xe CLI, you need to perform the rolling upgrade
manually by first planning your upgrade path and then live migrating running VMs between XenServer hosts
accordingly.
Important:
Rolling Pool Upgrade should not be used with Boot from SAN environments. For more
information on upgrading boot from SAN environments see Appendix B, Boot From SAN
Environments.
7.1.1. Upgrading XenServer hosts Using the XenCenter Rolling Pool Upgrade Wizard
You can use the Rolling Pool Upgrade wizard to upgrade XenServer hosts — hosts in a pool or standalone — to
the current version of XenServer
The wizard guides you through the upgrade procedure and organizes the upgrade path automatically. For pools,
each of the hosts in the pool is upgraded in turn, starting with the pool master. Before starting an upgrade, the
wizard conducts a series of prechecks to ensure that certain pool-wide features, such as HA, are temporarily
disabled and that each host in the pool is prepared for upgrade (for example, that the CD/DVD drive of each host
is empty). Only one host is offline at a time, and any running VMs are automatically migrated off each host before
the upgrade is installed on that host.
The wizard can operate in Manual or Automatic mode:
•
In Manual Mode, you must manually run the XenServer installer on each XenServer host in turn and follow
the on-screen instructions on the serial console of the host. Once the upgrade begins, XenCenter prompts you
to insert the XenCenter installation media or specify a network boot server for each host that you upgrade.
•
In Automatic Mode, the wizard uses network installation files located on an HTTP, NFS or FTP server to
upgrade each host in turn, without requiring you to insert installation media, manually reboot, or step through
the installer on each host. If you choose to perform a rolling pool upgrade in this manner, then you must
unpack the XenServer installation media onto your HTTP, NFS or FTP server before starting the upgrade.
Before You Upgrade
Before you begin your upgrade, be sure to make the following preparations:
•
Download and install XenCenter issued with XenServer 7.1 from the XenServer Product Download page. Using
earlier versions of XenCenter to upgrade to a newer version of XenServer is not supported.
•
Citrix strongly recommends that you take a backup of the state of your existing pool using the pool-dumpdatabase xe CLI command (see the XenServer Administrator's Guide). Taking a backup state ensures that you
can revert a partially complete rolling upgrade to its original state without losing VM data.
•
Ensure that your hosts are not over-provisioned: check that hosts have sufficient memory to carry out the
upgrade. As a general guideline, if N equals the total number of hosts in a pool, then there needs to be
sufficient memory across N-1 hosts to run all of the live VMs in the pool, as the Rolling Pool Upgrade wizard
migrates VMs from and shuts down one host in a pool at a time. It is best to suspend any non-critical VMs
during the upgrade process.
While the Rolling Pool Upgrade wizard checks that the following actions have been taken, you may choose to
perform them before you begin:
•
Empty the CD/DVD drives of the VMs in the pool(s).
•
Disable HA.
To upgrade XenServer hosts using the XenCenter Rolling Pool Upgrade wizard:
1.
Open the Rolling Pool Upgrade wizard: on the Tools menu, select Rolling Pool Upgrade.
25
2.
Read the Before You Start information, and then click Next to continue.
3.
Select the pool(s) and/or individual hosts that you wish to upgrade, and then click Next.
4.
Choose Automatic Mode or Manual Mode, depending on whether you are planning an automated upgrade
from network installation files located on an HTTP, NFS or FTP server, or a manual upgrade from either a CD/
DVD or using network boot (using already existing infrastructure).
Note:
If you choose Manual Mode, you must run the XenServer installer on each XenServer host
in turn and follow the on-screen instructions on the serial console of the host. Once the
upgrade begins, XenCenter prompts you to insert the XenServer installation media or specify
a network boot server for each host that you upgrade.
Once you have selected your Upgrade Mode, click Run Prechecks.
5.
Follow the recommendations to resolve any upgrade prechecks that have failed. If you would like XenCenter
to automatically resolve all failed prechecks, click Resolve All.
Once all prechecks have been resolved, click Next to continue.
6.
Prepare the XenServer installation media.
If you chose Automatic Mode, enter the installation media details. Choose HTTP, NFS or FTP and then specify
the path, username and password, as appropriate.
Note:
Enter the username and password associated with your HTTP, NFS or FTP server, if you have
configured security credentials. Do not enter the username and password associated with
your XenServer pool.
If you chose Manual Mode, note the upgrade plan and instructions.
Click Start Upgrade.
7.
Once the upgrade begins, the Rolling Pool Upgrade wizard guides you through any actions you need to take
to upgrade each host. Follow the instructions until you have upgraded all hosts in the pool(s).
Once the upgrade completes, the wizard prints a summary. Click Finish to close the wizard.
7.1.2. Upgrading XenServer hosts Using the xe CLI
Important:
Performing a rolling pool upgrade using the xe CLI requires extremely careful planning. Be
sure to read the following section with care before you begin.
7.1.2.1. Planning an Upgrade Path
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 7.0 to version 7.0 or from version 7.0 to version 7.1). You
cannot migrate VMs from an upgraded host to one running an older version of XenServer (for example, from
version 7.1 to version 7.0). 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 coexisting) 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.
26
•
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-dumpdatabase 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 7.2.1, “Before You
Upgrade a Single XenServer host”.
•
Disable HA.
7.1.2.2. Performing Rolling Pool Upgrades Using the xe CLI
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 hostevacuate command, you leave the distribution of migrated VMs to XenServer.
3.
Shut down the pool master.
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 4, Installing XenServer and
XenCenter) until the installer offers you the option to upgrade. Choose to upgrade.
Warning:
Be absolutely sure to select the upgrade option so as to avoid losing any existing data.
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.
27
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:
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 User's Guide for details.
Note:
Running older versions of the XenServer Tools on newer XenServer installations is not
supported, except during the upgrade process.
7.2. Upgrading a Single XenServer host Using the xe CLI
7.2.1. Before You Upgrade a Single XenServer host
Before upgrading a standalone 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, you may not be able to resume the suspended VMs 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 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.
28
2.
To empty the CD/DVD drives of the VMs listed, enter the following:
xe vbd-eject uuid=<uuid>
7.2.2. Upgrading a Single XenServer host Using the xe CLI
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 4, Installing XenServer and XenCenter) until the
installer offers you the option to upgrade. Choose to upgrade.
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.
29
Chapter 8. Applying Updates to XenServer
Between releases of XenServer, Citrix occasionally releases updates as Hotfixes and Cumulative Updates. Hotfixes
generally supply bug fixes to one or more specific issues. Cumulative Updates contain accumulated bug fixes.
This chapter describes the general procedures for applying updates to your XenServer environment through
XenCenter and the xe CLI. For more information about applying updates using XenCenter, refer to the XenCenter
Help.
Note:
Both Hotfixes and Cumulative Updates can be applied using the procedures in this chapter.
For example, use these procedures to apply XenServer 7.1 Cumulative Update 1 to XenServer
7.1.
Updates are made available from the Citrix Knowledge Center. Citrix recommends that customers regularly check
the Knowledge Center for new updates. Alternatively, you can subscribe to email alerts for updates to XenServer
by registering for an account at http://www.citrix.com/support/. In addition, you can configure XenCenter to
periodically check for available XenServer and XenCenter updates and new versions; any Alerts will be displayed
in the Notifications pane.
Updates can often be applied with minimal service interruption. Citrix recommends that customers use
XenCenter to apply all updates. If you are updating a pool of XenServer hosts, you can avoid downtime of VMs by
using XenCenter's Install Update wizard to apply updates, updating one host at a time, automatically migrating
VMs away from each host as the hotfix or update is applied.
8.1. Preparing a Pool for an Update
Updates to XenServer can be delivered as a Hotfix or a Cumulative Update. Pay careful attention to the Release
Note that is published with each update. Each update may have unique installation instructions, particularly with
regard to preparatory and post-update operations. The following sections offer general guidance and instructions
for applying updates to your XenServer deployment.
Important:
Before you apply an update to a XenServer pool, customers should pay careful attention to
the following:
1. You must upgrade each host in a pool to XenServer 7.1 before applying any 7.1 hotfixes.
2. Back up your data before applying an update, just as you would with any other
maintenance operations. For backup procedures, see the XenServer Administrator's
Guide.
3. Update all hosts in a pool within a short period: running a mixed-mode pool (a pool that
includes updated and non-updated hosts) is not a supported configuration. This should
be scheduled to minimise the amount of time that a pool runs in a mixed state.
4. Update all hosts within a pool sequentially, always starting with the pool master.
XenCenter's Install Update wizard manages this process automatically.
5. After applying a hotfix to all hosts in a pool, customers should update any required driver
disks before restarting XenServer hosts.
Before you begin updating:
•
Log into a user account with full access permissions (for example, as a Pool Administrator or using a local
root account).
•
Empty the CD/DVD drives of any VMs you plan to suspend. For details and instructions, see Section 7.2.1,
“Before You Upgrade a Single XenServer host”.
•
If applicable, disable High Availability (HA).
30
8.2. Applying Updates to a Pool
The update installation mechanism in XenCenter allows you to download and extract the selected update from
the Citrix Support website, and enables you to apply an update to multiple hosts and pools simultaneously using
the Install Update wizard. During the process, the Install Update wizard automatically migrates VMs off each
server, places the server in Maintenance mode, applies the update, reboots the host if required, and then, migrate
the VMs back to the updated host. Any actions that were taken at the precheck stage to enable the updates to
be applied, such as turning off HA, will be reverted.
The Install Update wizard carries out a series of checks known as Prechecks before starting the update process
- these checks ensure that the pool is in a valid configuration state. It then manages the update path and VM
migration automatically. If you prefer to control the update path and VM migration manually, you can update
each host individually.
8.2.1. Applying Updates Automatically
XenCenter allows you to apply automated updates that are needed to bring your servers up-to-date. You can
apply these updates to one or more pools. When you choose to apply automated updates, XenCenter applies
the minimum set of updates that are required to bring the selected pool or the standalone server up-to-date.
XenCenter minimizes the number of reboots required to bring the pool or the standalone server pool up-todate, and where possible, limits it to a single reboot at the end. For more information, see Section 8.4, “Applying
Automated Updates”.
8.2.2. Applying an Update to a Pool
To apply an update to a Pool using XenCenter:
1.
From the XenCenter navigation pane, click Notifications and then Updates. This provides a list of available
updates.
Alternatively:
a. From the XenCenter menu, select Tools and then Install Update.
b. Read the information displayed on the Before You Start page and then click Next.
c. The Install Update wizard lists available updates on the Select Update page. Select the required update
from the list and then click Next.
d. Select the pool and servers that you would like to update and click Next.
e. Proceed to Step 4 to continue with the update installation process.
Note:
XenCenter periodically checks for XenServer and XenCenter updates by default. Click Refresh
to manually check for available updates. If the Updates tab cannot find any updates because
you have disabled automatic check for updates, a message appears on the Updates tab. Click
Check for Updates Now to manually check for updates.
2.
From the Updates list, select the required update and then click Download and Install from the Actions
drop-down list. This extracts the update and opens the Install Update wizard on the Select Servers page with
the relevant hosts selected. If you would like to make any changes to the pool or the hosts being updated,
clear the check boxes. Any hosts or pools that cannot be updated will be greyed out.
Note:
Citrix strongly recommends that customers read the release notes published with each
update. To open the release note in your browser, click the Actions drop-down list and then
select Go to Web Page.
3.
Review the server selection and click Next to continue. This downloads the update and uploads it to the
default SR of the pool.
31
4.
The Upload page displays the status of the upload.
Note:
If the default SR in a pool is not shared, or does not have enough space, XenCenter tries to
upload the update to another shared SR with sufficient space. If none of the shared SRs have
sufficient space, the update will be uploaded to local storage on each host.
5.
The Install Update wizard performs a number of update prechecks, including the space available on the
hosts, to ensure that the pool is in a valid configuration state. The wizard also checks whether the hosts
need to be rebooted after the update is applied and displays the result. In addition, the Install Update wizard
checks whether a live patch is available for the hotfix and if the live patch can be successfully applied to the
hosts. For information about Live Patching, see Section 8.3, “Live Patching in XenServer”.
Follow the on-screen recommendations to resolve any update prechecks that have failed. If you want
XenCenter to automatically resolve all failed prechecks, click Resolve All. When the prechecks have been
resolved, click Next.
6.
Choose an Update Mode. Review the information displayed on the screen and select an appropriate mode.
If the hotfix contains a live patch that can be successfully applied to the hosts, it displays No action
required on the Tasks to be performed screen.
Note:
If you click Cancel at this stage, the Install Update wizard reverts the changes and removes
the update file from the server.
7.
Click Install update to proceed with the installation. The Install Update wizard shows the progress of the
update, displaying the major operations that XenCenter performs while updating each server in the pool.
8.
When the update is applied, click Finish to close Install Update wizard.
9.
If you chose to manually perform post-update tasks, do so now.
8.2.3. Updating a Pool of XenServer hosts Using the xe CLI
To Update a Pool of XenServer hosts Using the xe CLI:
1.
Download the update file 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> update-upload file-name=<filename>
[sr-uuid=<storage_repository_uuid>]
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:
Once an update file has been uploaded to a XenServer host, you can use the update-list and
update-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.
32
4.
Update the pool, specifying the UUID of the update file, by running the following:
xe update-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 upload-apply host-uuid=<UUID_of_host> uuid=<UUID_of_file>
5.
Verify that the update was applied by using the update-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, restarting the XAPI toolstack, or rebooting the
hosts.
8.2.4. Updating Individual Hosts Using the xe CLI
To Update Individual Hosts Using the xe CLI:
1.
Download the update file 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 vmsuspend commands.
3.
Upload the update file to the host you wish to update by running the following:
xe -s <server> -u <username> -pw <password> update-upload file-name=<filename>
[sr-uuid=<storage_repository_uuid>]
Here, -s refers to the hostname. XenServer assigns the update file a UUID, which this command prints. Note
the UUID.
Tip:
Once an update file has been uploaded to a XenServer host, you can use the update-list and
update-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 update-apply host-uuid=<UUID_of_host> uuid=<UUID_of_file>
6.
Verify that the update has been successfully applied by using the update-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, restarting the XAPI toolstack, or rebooting the
host).
8.3. Live Patching in XenServer
XenServer customers who deploy XenServer hosts may often need to reboot their hosts after applying hotfixes.
This rebooting results in unwanted downtime for the hosts while customers have to wait until the system is
restarted. This also reduces the uptime of the hosts and impacts business. Live patching enables customers to
install some Linux kernel and Xen hypervisor hotfixes without having to reboot the hosts. Such hotfixes will consist
of both a live patch, which will be applied to the memory of the host, as well as a hotfix that updates the files
on disk. This reduces maintenance costs and downtime.
When applying an update using XenCenter, the Install Update wizard checks whether the hosts need to be
rebooted after the update is applied and displays the result on the Prechecks page. This enables customers to
know the post-update tasks well in advance and schedule the application of hotfixes accordingly.
33
Note:
XenServer Live Patching is available for XenServer Enterprise Edition customers, or those
who have access to XenServer through their XenApp/XenDesktop entitlement. To learn more
about XenServer editions, and to find out how to upgrade, visit the Citrix website here. For
detailed information on Licensing, see XenServer 7.1 Licensing FAQ.
8.3.1. Live Patching Scenarios
Hotfixes can be live patched across pools, hosts, or on a standalone server. Some may need reboot, some need
the xapi toolstack to be restarted, and some hotfixes do not have any post-update tasks. The following scenarios
describe the behavior when a Live Patch is and is not available for an update.
•
Updates with live patch— Some hotfixes that update Linux kernel and the Xen hypervisor usually do not
need a reboot after applying the hotfix. However, in some rare cases, when the live patch cannot be applied,
a reboot may be required.
•
Updates without live patch—No change in the behavior here. It works as usual.
Note:
If a host does not require a reboot, or if the hotfix contains live patches, XenCenter displays
No action required on the Update Mode page.
8.3.2. Applying Automated Updates and Live Patching
The Automated Updates mode in XenCenter allows you to automatically download and apply the minimum set
of hotfixes required to bring your pool or standalone host up-to-date.
You can benefit from the Live Patching feature when you apply hotfixes using the Automated Updates mode in
XenCenter. You can avoid rebooting hosts if live patches are available and are successfully applied to the hosts
that are updated using the Automated Updates mode. For more information about the Automated Updates, see
Section 8.4, “Applying Automated Updates”
8.3.3. Enabling Live Patching using XenCenter and the xe CLI
Live Patching feature is enabled by default. Customers can enable or disable Live Patching using XenCenter or
xe CLI command.
Using XenCenter
1. Select the pool or the standalone host on the Resource pane
2. From the Pool menu (Server in case on standalone hosts) menu, select Properties and then click Live Patching.
3. On the Live Patching page:
•
Select Use live Patching when possible to enable Live Patching.
•
Select Don’t use Live Patching to disable Live Patching.
Using the xe CLI
•
To enable Live Patching, run the following command:
xe pool-param-set live-patching-disabled=false uuid=<"pool_uuid">
•
To disable Live Patching, run the following command:
xe pool-param-set live-patching-disabled=true uuid=<"pool_uuid">
34
8.4. Applying Automated Updates
As a prerequisite, XenCenter requires Internet access to fetch the required updates. When you choose to apply
automated updates, all the required updates get applied.
To view the list of required updates, perform the following steps:
1.
Select the host on the Resources pane in XenCenter.
2.
Navigate to the General tab.
3.
Expand the Updates section.
You can see:
•
Applied – lists already-applied updates.
•
Required Updates – lists the set of updates required to bring the server up-to-date.
Note:
If there are no updates required, the Required Updates section will not be displayed.
•
Installed supplemental packs – lists supplemental pack that are installed on the server (if installed).
Note:
If you select a pool instead of a server, the Updates section lists updates that are already
applied as Fully Applied.
If you wish to choose and install a particular update(s), see Section 8.2.2, “Applying an Update to a Pool” section.
Note:
The Automated Updates feature is available for XenServer Enterprise Edition customers, or
those who have access to XenServer through their XenApp/XenDesktop entitlement. To learn
more about XenServer editions, and to find out how to upgrade, visit the Citrix website here.
For detailed information on Licensing, refer to XenServer 7.1 Licensing FAQ.
Applying automated updates using the Install Update wizard.
The following section provides step-by-step instructions on how to apply the set of required updates
automatically to bring your pool or standalone host up-to-date.
1.
From the XenCenter menu, select Tools and then select Install Update.
2.
Read the information displayed on the Before You Start page and then click Next.
3.
On the Select Update page, select the mechanism by which you would like to install the updates. You can
see the following options:
•
Automated Updates – (default) this option is visible only if XenCenter is connected to at least one
licensed pool or a licensed standalone server. Select this option to automatically download and install
all the current updates from Citrix to bring the pool or a standalone server up-to-date.
•
Download update from Citrix – the Install Update wizard lists available updates from the Citrix Support
site. To apply the updates, see Section 8.2.2, “Applying an Update to a Pool” section.
•
Select update or Supplemental pack from disk – to install an update you have already downloaded,
see Section 8.2.2, “Applying an Update to a Pool” section. To install supplemental pack updates, refer
Installing Supplemental Packs section in XenCenter Help.
4.
To continue with the automatic application of hotfixes, select Automated Updates and then click Next.
5.
Select one or more pools or standalone servers that you would like to update and click Next. Any server or
pool that cannot be updated appears greyed out.
35
6.
The Install Update wizard performs a number of update prechecks, including the space available on the
hosts, to ensure that the pool is in a valid configuration state.
Follow the on-screen recommendations to resolve any update prechecks that have failed. If you want
XenCenter to automatically resolve all failed prechecks, click Resolve All. When the prechecks have been
resolved, click Next.
7.
The Install Update wizard automatically downloads and installs the recommended updates. The wizard also
shows the overall progress of the update, displaying the major operations that XenCenter performs while
updating each server in the pool.
Note:
8.
•
The updates will be uploaded to the default SR of the pool. If the default SR is not shared,
or does not have enough space, XenCenter tries to upload the update to another shared
SR with sufficient space. If none of the shared SRs have sufficient space, the update will
be uploaded to local storage on each host.
•
The update progress of a pool stops on the first error regardless of any possible further
actions that could still be run.
When all the updates have been applied, click Finish to close Install Update wizard.
36
Appendix A. Troubleshooting
Citrix provides two forms of support: free, self-help support from www.citrix.com/support 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.
For information on the different types of support and maintenance programmes offered by Citrix, see
www.citrix.com/support/programs.html
The Citrix support site, www.citrix.com/support, hosts a number of resources that may be helpful to you if you
experience odd behavior, crashes, or other problems during installation. Resources include: forums, knowledge
base articles, software updates, security bulletins, tools, 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.
37
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 HBA's BIOS 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 will 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.
Warning:
Boot from SAN settings are not inherited during the upgrade process. When upgrading using
the ISO or network-boot, customers should follow the same instructions as used in the
installation process below to ensure that multipath is correctly configured.
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
The XenServer installation process configures a XenServer host which boots from a remote SAN with multipathing
enabled.
To enable file system multipathing using PXE or UEFI installation, customers should add
device_mapper_multipath=yes to their configuration file. The following is an example configuration:
default xenserver
label xenserver
kernel mboot.c32
append /tftpboot/xenserver/xen.gz dom0_max_vcpus=1-2 \
dom0_mem=1024M,max:1024M com1=115200,8n1 \
console=com1,vga --- /tftpboot/xenserver/vmlinuz \
xencons=hvc console=hvc0 console=tty0 \
device_mapper_multipath=yes \
install --- /tftpboot/xenserver /install.img
For additional information on storage multipathing in your XenServer environment, please see the XenServer
Administrator's Guide.
B.1. Software-boot-from-iSCSI for Cisco UCS
The Software-boot-from-iSCSI feature enables customers to install and boot XenServer from SAN using iSCSI.
Using this feature, XenServer can be installed to, booted from, and run from a LUN provided by an iSCSI target
specified in the iSCSI Boot Firmware Table (iBFT). This allows the root disk to be attached through iSCSI.
XenServer supports the following features for Software-boot-from-iSCSI:
•
Host installation through PXE-boot
•
Cisco UCS vNIC *
•
Jumbo Frames (MTU=9000) configured with the Cisco UCS manager
*
Software-boot-from-iSCSI has been tested in Legacy BIOS and UEFI boot mode using Cisco UCS vNICs and Power Vault, NetApp and
EqualLogic arrays. Other configurations may work, however, they have not been validated.
38
•
Cisco UCS line-rate limiting
•
Untagged VLANs
•
Networks using the vSwitch backend
•
LVHDoISCSI SRs and NFS SRs on the same or different SAN/NAS
•
Multipathing of the iSCSI root disk
•
Compatibility with common XenServer (Network, Maintenance) operations
Requirements
•
The primary management interface (IP addressable) and the network for VM traffic, must use separate
interfaces.
•
Storage (iSCSI targets) must be on a separate Layer 3 (IP) network to all other network interfaces with IP
addresses on the host.
•
Storage must be on the same subnet as the storage interface of the XenServer host.
B.1.1. Installing XenServer Using CD Media
Perform the following steps to install XenServer using a CD:
1. Access the boot menu; at the boot: prompt enter menu.c32
2. Use the cursor keys to select an installation option:
•
For a single path LUN select install
•
For a multipathed LUN select multipath
3. Press the tab key.
Edit the line ending with the following:
--- /install.img
4. Using the cursor keys, edit this line to read:
use_ibft --- /install.img
5. Press Enter.
XenServer host installation proceeds as normal.
B.1.2. Installing XenServer Using PXE
Perform the following steps to install XenServer using PXE:
Note:
You must ensure to add the keyword use_ibft in the kernel parameters. If multipathing is
required, you must add device_mapper_multipath=enabled.
The following example shows PXE configuration for a single LUN:
label xenserver
kernel mboot.c32
append XS/xen.gz dom0_max_vcpus=2 dom0_mem=1024M,max:1024M
com1=115200,8n1 console=com1,vga --- XS/vmlinuz xencons=hvc console=tty0
console=hvc0 use_ibft --- XS/install.img
The following example shows PXE configuration for a multipathed LUN:
39
label xenserver
kernel mboot.c32
append XS/xen.gz dom0_max_vcpus=2 dom0_mem=1024M,max:1024M
com1=115200,8n1 console=com1,vga --- XS/vmlinuz xencons=hvc console=tty0
console=hvc0 use_ibft device_mapper_multipath=enabled --- XS/install.img
40
Appendix C. Network Boot Installations
This appendix describes how to configure your PXE and UEFI environment for XenServer installation.
XenServer supports booting hosts using the UEFI mode. UEFI mode provides a rich set of standardized facilities
to the bootloader and operating systems. This allows XenServer to be more easily installed on hosts where UEFI
is the default boot mode.
The following section contains information about setting up your TFTP and NFS, FTP or HTTP servers to enable
PXE and UEFI 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 and UEFI Environment for XenServer
Installation
Before you set up the XenServer installation media, you need to configure your TFTP and DHCP servers. The
following sections contain information on how to configure your TFTP server for PXE and UEFI booting. Consult
your vendor documentation for general setup procedures.
Note:
XenServer 6.0 moved from MBR disk partitioning to GUID Partition Table (GPT). Some thirdparty PXE deployment systems may attempt to read the partition table on a machine's hard
disk before deploying the image to the host.
If the deployment system has not been updated to be compatible with GPT partitioning
scheme, and the hard disk has previously been used for a version of XenServer (or any other
Operating System) that uses GPT, the PXE deployment system may fail. If this happens, a
workaround is to delete the partition table on the disk.
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.
Configuring your TFTP Server for PXE boot
To configure your TFTP server for PXE boot:
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.
Note:
Citrix strongly recommends using mboot.c32 and pxelinux.0 files from the same
source (for example, from the same XenServer ISO).
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
41
boots from the TFTP server and leaves you to manually respond to the installation prompts. The second
performs an unattended installation.
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=1024M,max:1024M 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:
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=1024M,max:1024M 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.
Configuring your TFTP Server for UEFI boot
To configure your TFTP server for UEFI boot:
1.
In the /tftpboot directory, create a new directory called EFI/xenserver.
2.
Configure your DHCP server to provide /EFI/xenserver/grubx64.efi as the boot file.
3.
Create grub.cfg file. For example:
menuentry "XenServer Install (serial)" {
multiboot2 /EFI/xenserver/xen.gz dom0_mem=1024M,max:1024M watchdog \
dom0_max_vcpus=4 com1=115200,8n1 console=com1,vga
module2 /EFI/xenserver/vmlinuz console=hvc0
module2 /EFI/xenserver/install.img
}
4.
Copy grub.cfg file to /tftpboot/EFI/xenserver directory on the TFTP server.
5.
From the XenServer installation media, copy the files grubx64.efi, install.img (from the
root directory), vmlinuz and xen.gz (from the /boot directory) to the new /tftpboot/EFI/
xenserver directory on the TFTP server.
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 leftmost.
42
default xenserver
label xenserver
kernel mboot.c32
append /tftpboot/EFI/xenserver/xen.gz dom0_mem=1024M,max:1024M watchdog \
dom0_max_vcpus=4 com1=115200,8n1 \
console=com1,vga --- /tftpboot/EFI/xenserver/vmlinuz \
console=hvc0 console=tty0 \
--- /tftpboot/EFI/xenserver/install.img
A sample configuration that performs an unattended installation using the answer file at the URL specified:
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/EFI/xenserver/xen.gz dom0_mem=1024M,max:1024M watchdog \
dom0_max_vcpus=4 com1=115200,8n1 \
console=com1,vga --- /tftpboot/EFI/xenserver/vmlinuz \
console=hvc0 console=tty0 \
answerfile=http://pxehost.example.com/answerfile \
install --- /tftpboot/EFI/xenserver/install.img
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.
2.
Copy the entire contents of the XenServer installation media to the newly created directory on the HTTP,
FTP or NFS server. This is your installation repository.
Note:
When copying the XenServer installation media, customers should make sure to copy the file
.treeinfo to the newly created directory.
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.
Installing Supplemental Packs during XenServer installation
Supplemental Packs are used to modify and extend the functionality of XenServer, by installing software into the
control domain (Dom0). For example, an OEM partner may wish to ship XenServer with a suite of management
tools that require SNMP agents to be installed, or provide a driver that supports the latest hardware. Users can
add supplemental packs either during initial XenServer installation, or at any time afterwards.
When installing supplemental packs during XenServer installation, each supplemental pack should also be
unpacked into a separate directory.
43
Facilities also exist for OEM partners to add their supplemental packs to the XenServer installation repositories
to allow automated factory installations.
C.2. Creating an answer file for unattended PXE and UEFI
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:
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.
Element
Description
Required?
<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.
Y
Attributes:
You can specify a guest-storage attribute with possible values yes and no.
For example:
<primary-disk guest-storage="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.
<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.
Y
<keymap>us</keymap>
The default value, us will be considered if you do not specify a value for
this attribute.
44
Element
Description
Required?
<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
Attributes:
Type: hash or plaintext
For example:
<root-password type="hash">hashedpassword \
</root-password>
<source>
The location of the uploaded XenServer installation media or a
Supplemental Pack. Element may occur multiple times.
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>
45
Y
Element
Description
Required?
<script>
Where the post-install-script is.
N
Attributes:
stage: filesystem-populated, installation-start, 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-start"
type="local">
file:///scripts/run.sh
</script>
<script stage="installation-complete"
type="nfs">
server:/scripts/installation-pass-fail-script
</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.
<admininterface>
The single network interface to be used as the host administration
interface.
Attributes:
proto: dhcp or static
name: eth0 for example.
Children:
•
<ipaddr>: The IP address, if proto="static"
•
<subnet>: The subnet mask, if proto="static"
•
<gateway>: The gateway, if proto="static"
All three child elements are required if proto="static"
46
N
Element
Description
Required?
<timezone>
In the format used by the TZ variable, for example Europe/London, or
America/Los_Angeles.
Y
<name-server>
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
<ntp-server>
Specify one or more NTP servers.
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 existinginstallation 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>
47
Appendix D. Installing XenServer on Small
Devices
XenServer enables customers with smaller devices, that is, devices with more than 12GB but less than 46GB of
disk space, to install XenServer 7.1 using the legacy DOS partition layout. The legacy DOS partition layout includes:
•
4GB Boot partition
•
4GB Backup partition
•
SR partition (if present on the local disk)
To install XenServer 7.1 on small devices, you must add disable-gpt to the dom0 parameters. You can use
menu.c32 to add the parameter to dom0.
Note:
Any utility partition presented by the host to the installer before the installation process will
be preserved.
Important:
Citrix recommends that you allocate a minimum of 46GB disk space and install XenServer 7.1
using the new GPT partition layout. For more information, see Section 4.2.1, “XenServer host
Partition Layout”.
48