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
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
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 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
19
