Citrix Systems 5.6 Manuel D’Utilisation

19

This  chapter  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.

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.

Note:

If the pool's master fails, master re-election will only take place if High Availability is enabled.

A resource pool is a homogeneous (or heterogeneous with restrictions, see 

) 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.