XenServer Hosts and Resource Pools

XenServer Hosts and Resource Pools

This describes how resource pools can be created through a series of examples using the xe command line interface (CLI). A simple NFS-based shared storage configuration is presented and a number of simple VM management examples are discussed. Procedures for dealing with physical node failures are also described.

Hosts and Resource Pools Overview

A resource pool comprises multiple XenServer host installations, bound together into a single managed entity which can host Virtual Machines. When combined with shared storage, a resource pool enables VMs to be started on any XenServer host which has sufficient memory and then dynamically moved between XenServer hosts while running with minimal downtime (XenMotion). If an individual XenServer host suffers a hardware failure, then the administrator can restart the failed VMs on another XenServer host in the same resource pool. If high availability (HA) is enabled on the resource pool, VMs will automatically be moved if their host fails. Up to 16 hosts are supported per resource pool, although this restriction is not enforced.

A pool always has at least one physical node, known as the master. Only the master node exposes an

administration interface (used by XenCenter and the XenServer Command Line Interface, known as the xe CLI); the master forwards commands to individual members as necessary.

Requirements for Creating Resource Pools

A resource pool is a homogeneous aggregate of one or more XenServer hosts, up to a maximum of 16. The definition of  homogeneous is:

• the CPUs on the server joining the pool are the same (in terms of vendor, model, and features) as the CPUs on servers already in the pool.

• the server joining the pool is running the same version of XenServer software, at the same patch level, as servers already in the pool

The software will enforce additional constraints when joining a server to a pool – in particular:

• it is not a member of an existing resource pool

• it has no shared storage configured

• there are no running or suspended VMs on the XenServer host which is joining

• there are no active operations on the VMs in progress, such as one shutting down

You must also check that the clock of the host joining the pool is synchronized to the same time as the pool master (for example, by using NTP), that its management interface is not bonded (you can configure this once the host has successfully joined the pool), and that its management IP address is static (either configured on the host itself or by using an appropriate configuration on your DHCP server).

XenServer hosts in resource pools may contain different numbers of physical network interfaces and have local storage repositories of varying size. In practice, it is often difficult to obtain multiple servers with the exact same CPUs, and so minor variations are permitted. If you are sure that it is acceptable in your environment for hosts with varying CPUs to be part of the same resource pool, then the pool joining operation can be forced by passing a --force parameter.

Although not a strict technical requirement for creating a resource pool, the advantages of pools (for example, the ability to dynamically choose on which XenServer host to run a VM and to dynamically move a VM between XenServer hosts) are only available if the pool has one or more shared storage repositories. If possible, postpone creating a pool of XenServer hosts until shared storage is available. Once shared storage has been added, Citrix recommends that you move existing VMs whose disks are in local storage into shared storage. This can be done using the xe vm-copy command or XenCenter.

Creating a Resource Pool

Resource pools can be created using either the XenCenter management console or the CLI. When you join a new host to a resource pool, the joining host synchronizes its local database with the pool-wide one, and inherits some settings from the pool:

• VM, local, and remote storage configuration is added to the pool-wide database. All of these will still be tied to the joining host in the pool unless you explicitly take action to make the resources shared after the join has completed.

• The joining host inherits existing shared storage repositories in the pool and appropriate PBD records are created so that the new host can access existing shared storage automatically.

• Networking information is partially inherited to the joining host: the structural details of NICs, VLANs and bonded interfaces are all inherited, but policy information is not. This policy information, which must be reconfigured, includes:

• the IP addresses of management NICs, which are preserved from the original configuration

• the location of the management interface, which remains the same as the original configuration. For example, if the other pool hosts have their management interfaces on a bonded interface, then the joining host must be explicitly migrated to the bond once it has joined.

• Dedicated storage NICs, which must be re-assigned to the joining host from XenCenter or the CLI, and the PBDs re-plugged to route the traffic accordingly.

To join XenServer hosts host1 and host2 into a resource pool using the CLI

1. Open a console on XenServer host host2.

2. Command XenServer host host2 to join the pool on XenServer host host1 by issuing the command:

xe pool-join master-address=<host1> master-username=<administrators_username> \

master-password=<password>

The master-address must be set to the fully-qualified domain name of XenServer host host1 and the

password must be the administrator password set when XenServer host host1 was installed.

Naming a resource pool

• XenServer hosts belong to an unnamed pool by default. To create your first resource pool, rename the existing nameless pool. Use tab-complete to find the pool_uuid:

xe pool-param-set name-label=<"New Pool"> uuid=<pool_uuid>

Creating Heterogeneous Resource Pools

XenServer 6.2.0 simplifies expanding deployments over time by allowing disparate host hardware to be joined into a resource pool, known as heterogeneous resource pools. Heterogeneous resource pools are made possible by leveraging technologies in recent Intel (FlexMigration) and AMD (Extended Migration) CPUs that provide CPU "masking" or "leveling". These features allow a CPU to be configured to appear as providing a different make, model, or functionality than it actually does. This enables you to create pools of hosts with disparate CPUs but still safely support live migrations.

Using XenServer to mask the CPU features of a new server, so that it will match the features of the existing servers in a pool, requires the following:

• the CPUs of the server joining the pool must be of the same vendor (i.e. AMD, Intel) as the CPUs on servers already in the pool, though the specific type, (family, model and stepping numbers) need not be.

• the CPUs of the server joining the pool must support either Intel FlexMigration or AMD Enhanced Migration.

• the features of the older CPUs must be a sub-set of the features of the CPUs of the server joining the pool.

• the server joining the pool is running the same version of XenServer software, with the same hotfixes installed, as servers already in the pool.

Creating heterogeneous resource pools is most easily done with XenCenter which will automatically suggest using CPU masking when possible. Refer to the Pool Requirements section in the XenCenter help for more details. To display the help in XenCenter press F1.

To add a heterogeneous XenServer host to a resource pool using the xe CLI

1. Find the CPU features of the Pool Master by running the xe host-get-cpu-features command.

2. On the new server, run the xe host-set-cpu-features command and copy and paste the Pool Master's

features into the features parameter. For example:

xe host-set-cpu-features features=<pool_master's_cpu_ features>

3. Restart the new server.

4. Run the xe pool-join command on the new server to join the pool.

To return a server with masked CPU features back to its normal capabilities, run the xe host-reset-cpu-features command.

Adding Shared Storage

For a complete list of supported shared storage types, see the Storage chapter. This section demonstrates how shared storage (represented as a storage repository) can be created on an existing NFS server.

Adding NFS shared storage to a resource pool using the CLI

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

2. Create the storage repository on <server:/path> by issuing the command

xe sr-create content-type=user type=nfs name-label=<"Example SR"> shared=true \

device-config:server=<server> \

device-config:serverpath=<path>

The device-config:server refers to the hostname of the NFS server and deviceconfig: serverpath refers to the path on the NFS server. Since shared is set to true, the shared storage will be automatically connected to every XenServer host in the pool and any XenServer hosts that subsequently join will also be connected to the storage. The Universally Unique Identifier (UUID) of the created storage repository will be printed on the screen.

3. Find the UUID of the pool by the command

xe pool-list

4. Set the shared storage as the pool-wide default with the command

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

Since the shared storage has been set as the pool-wide default, all future VMs will have their disks created on shared storage by default. See Chapter 5, Storage for information about creating other types of shared storage.