XenServer Administrator's Guide 4.1.0

Chapter 2. XenServer Hosts and

resource pools

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. Up to 16 hosts are supported per resource pool, although this restriction is not enforced.

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 pool always has at least one physical node, known as the “master”. Other physical nodes join existing

pools and are described as “members”. Only the master node exposes an administration interface (used by

XenCenter and the CLI); the master will forward commands to individual members as necessary.

2.1. Requirements for creating resource pools

A resource pool is an aggregate of one or more homogeneous XenServer Hosts, up to a maximum of 16.

The definition of homogeneous is:

• each CPU is from the same vendor (in particular AMD-V and Intel VT CPUs cannot be mixed)

• each CPU is the same model (except for stepping)

• each CPU has the same feature flags

In addition to being homogeneous, an individual XenServer Host can only join a resource pool if:

• it has a static IP address (either manually assigned or via DHCP);

• it is not a member of an existing resource pool

• it has a clock synchronized to the pool master server (for example, via NTP)

• 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

• the management NIC of the XenServer Host which is joining is not part of a NIC bond

• the Linux Pack is either installed on all hosts in the pool, or not installed at all

XenServer Hosts in resource pools may contain different numbers of physical network interfaces. Local

storage repositories may also exist, 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.