Product Documentation

Pool Requirements

Oct 10, 2013

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

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; see Configuring 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.