Resource Pool: Combining one or more xenservers as a single unit is resource pool

Resource pool member host types

master pool member

• single control point for all XS in the pool
• maintains pool configuration data
• manages distributed locking for shared storage
• configures seconday xs in the pool

Secondary pool member

• controlled through the master
• maintains pool configuration backup
• can be promoted to pool master

Citrix XenServer pools allow you to view multiple servers and their connected shared storage as a single unified resource, enabling flexible deployment of virtual machines based on their resource needs and business priorities. A pool may contain up to 16 servers running the same version of XenServer software, at the same patch level, and with broadly compatible hardware – see Pool Requirements for details of hardware and configuration prerequisites.

One server in the pool is designated as the pool master, and provides a single point of contact for all of the servers in the pool, routing communication to other members of the pool as necessary.

If the pool master is shut down, the pool will be unavailable until the master is rebooted and back on line or until you nominate one of the other members as the new pool master. Every member of a resource pool contains all the information necessary to take over the role of master if required. On an HA-enabled pool, a new pool master is automatically nominated if the master is shut down.

Pool Requirements

Before you create a pool or join a server to an existing pool, you should make sure that the requirements identified below are satisfied for all the servers in the pool.

Hardware requirements

All of the servers in a XenServer resource pool must have broadly compatible CPUs, that is:

• The CPU vendor (Intel, AMD) must be the same on all CPUs on all servers. In particular AMD-V and Intel VT CPUs cannot be mixed.
• All of the CPUs must have the same feature set. To allow servers with non-identical CPUs to be members of the same pool, CPU masking can be used to hide incompatible features.
• To run HVM (Windows) virtual machines, all CPUs must have virtualization enabled.

Using CPU masking (heterogeneous pools)

VM live migration between servers with different underlying CPU features is not possible. However, newer generation CPUs have the capability to hide (“mask”) differences in software-visible processor features, making it possible for CPUs with different underlying hardware capabilities to appear identical. Using CPU masking, only those features which are supported on all processors in a resource pool are exposed, allowing VMs to safely live migrate between servers with potentially different processor features.

This capability is provided by Intel® Virtualization Technology FlexMigration (Intel® VT FlexMigration) and AMD-V TM Extended Migration technologies.

When placing a new server in a XenServer resource pool, the feature sets on the existing and joining CPUs are compared and, if found to be compatible, the new server is allowed to join the pool. Only those CPU features that are exposed are considered when determining CPU compatibility. With CPU masking enabled, only those features present on the CPUs on the older servers are exposed on the newer CPUs, and other/newer features are masked. This allows newer servers with CPUs that have live migration support to be placed in resource pools with older, “less capable” servers. (This type of pool is termed a heterogeneous pool.)

Without CPU masking, all of the servers in a pool must have identical CPUs, that is, CPUs with exactly the same feature set (this is referred to as a homogeneous pool). XenCenter will not allow you to place a server with a different underlying processor features into a resource pool, and will automatically attempt to use CPU masking if different CPU feature sets are detected on the servers already in the pool and the new server.

Heterogeneous pools are only supported in Citrix XenServer Enterprise Edition or higher. To learn more about the features available in different XenServer Editions, click here.

Other requirements

In addition to the hardware prerequisites identified above, there are a number of other configuration prerequisites for a server joining a pool:

• It must have a static IP address (either configured on the server itself or by using an appropriate configuration on your DHCP server). This also applies to the servers providing shared NFS or iSCSI storage.
• Its system clock must be synchronized to the pool master (for example, via NTP).
• It may not be a member of an existing resource pool.
• It may not have any running or suspended VMs or any active operations in progress on its VMs, such as shutting down or exporting; all VMs must be shut down before a server can join a pool.
• It may not have any shared storage already configured.
• It may not have a bonded management interface. You will need to reconfigure the joining server’s management interface and move it back on to a physical NIC before joining the pool, then reconfigure it again once the server has successfully joined the pool; seeConfiguring IP Addresses.
• It must be running the same version of XenServer software, at the same patch level, as servers already in the pool.
• It must be configured with the same supplemental pack(s) as the servers already in the pool. Supplemental packs are used to install add-on software into the XenServer control domain, dom0. To prevent inconsistencies in the user experience across a pool, it is necessary to have the same supplemental packs at the same revision installed on all the servers in the pool.
• It must have the same XenServer product license edition as the servers already in the pool. For example, you cannot add a free XenServer system to an existing resource pool containing servers with XenServer Advanced Edition or higher licenses. If you attempt to add a server running the free XenServer edition to a pool that has licensed servers, you will be offered the chance to assign a license from your Citrix license server to the joining server, if one is available. See Managing licenses for details.

Shared pool storage

Although not a strict technical requirement for creating a resource pool, the advantages of pools (for example, running a VM on the most appropriate server and VM migration between servers) are only available if the pool has one or more shared storage repositories (SRs).

We recommend that you do not attempt to create a pool until shared storage is available. Once shared storage has been added, you can quickly move any existing VMs whose disks are in local storage into shared storage by copying them.

When a server with a shared SR becomes a pool master, this SR becomes a shared SR for the pool. If the new pool master does not have any shared storage, you will have to create a new shared SR for the pool: see Creating a New SR.