Filter
Top Products
22
XenServer Hosts and Resource Pools
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.
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.
Note:
If the pool's master fails, master re-election will only take place if High Availability is enabled.
Requirements for Creating Resource Pools
A resource pool is a homogeneous (or heterogeneous with restrictions, see the section called “Creating
Heterogeneous Resource Pools”) 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 primary 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.
Note: