Pool Requirements

A resource pool is a homogeneous or heterogeneous aggregate of one or more servers, up to a maximum of 64. Before you create a pool or join a server to an existing pool, ensure the following requirements are satisfied for all servers in the pool.

Hardware requirements

All servers in XenServer resource pools must have broadly compatible CPUs, that is:

  • The CPU vendor (Intel, AMD) must be the same on all CPUs on all servers.
  • All CPUs must have virtualization enabled.

Other requirements

In addition to the hardware prerequisites, there are several other prerequisites for a server that joins a pool:

  • It must have a consistent IP address (a static IP address on the server or a static DHCP lease). This requirement also applies to the servers providing shared NFS or iSCSI storage.
  • Its system clock must be synchronized to the pool coordinator (for example, via NTP).
  • It cannot be a member of an existing resource pool.
  • It cannot have any running or suspended VMs or any active operations in progress on its VMs. All VMs must be shut down before a server can join a pool.
  • It cannot have any shared storage already configured.
  • It cannot have a bonded management interface. Reconfigure the joining server’s management interface and move it back on to a physical NIC before joining the pool. After the server has successfully joined the pool, you can reconfigure it. For more information, see Configuring IP Addresses.
  • It must be running the same version of XenServer software, at the same patch level, as the servers already in the pool.
  • It must be configured with the same supplemental packs as the servers already in the pool. Supplemental packs are used to install add-on software into dom0 (XenServer control domain). To prevent inconsistencies in the user experience across a pool, ensure you install the same supplemental packs at the same revision on all the servers in the pool.
  • It must have the same XenServer license as the servers already in the pool. For example, you cannot add a server with XenServer Standard Edition license to an existing resource pool that contains servers with XenServer Premium Edition. You can change the license of any pool members after joining the pool. The server with the lowest license determines the features available to all members in the pool. For more information about licensing, see About XenServer Licensing.

Homogeneous pool

A homogeneous resource pool is an aggregate of servers with identical CPUs. In addition to the requirements in the preceding sections, a server that joins a homogeneous pool must have the same CPUs as those servers already in the pool. CPUs are considered the same if they have the same vendor, model, and features.

Heterogeneous pool

XenServer enables expanding deployments over time by allowing disparate host hardware to be joined into a resource pool, known as heterogeneous resource pools. Heterogeneous resource pools are made possible by applying technologies in Intel (FlexMigration) and AMD (Extended Migration) CPUs that provide CPU “masking” or “leveling”. These features allow a CPU to be configured to appear as providing a different make, model, or functionality than it actually does. This capability enables you to create pools of hosts with disparate CPUs but still safely support live migrations. Servers joining heterogeneous pools must meet the following requirements:

  • The CPUs of the server that joins the pool must be of the same vendor (AMD, Intel) as the CPUs on servers already in the pool. However, the specific type of CPU (family, model, and stepping numbers) is note required to be the same.
  • The CPUs of the server joining the pool must support either Intel FlexMigration or AMD Enhanced Migration.

XenServer simplifies the support for heterogeneous pools. You can add servers to existing resource pools, irrespective of the underlying CPU type, as long as the CPU is from the same vendor family. The pool feature set is dynamically calculated every time:

  • a new server joins the pool
  • a pool member leaves the pool
  • a pool member reconnects following a reboot

Any change in the pool feature set does not affect VMs that are currently running in the pool. A running VM continues to use the feature set which was applied when it was started. This feature set is fixed at boot and persists across migrate, suspend, and resume operations. If the pool level drops when a less-capable server joins the pool, a running VM can migrate to any server in the pool, except the newly added server. When you move or migrate a VM to a different server within or across pools, XenServer compares the VM feature set to that of the destination server. If the feature sets are found to be compatible, the VM is allowed to migrate. This capability enables the VM to move freely within and across pools, regardless of the CPU features the VM is using. If you use Workload Balancing to choose an optimal destination server to migrate your VM, a server with an incompatible feature set is not recommended as the destination server.


To update a running VM to use the pool’s new feature set, power off the VM and start it again. Rebooting the VM, for example, by clicking Reboot in XenCenter, does not cause the VM to update its feature set.

Shared pool storage

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

We recommend that you do not attempt to create a pool until shared storage is available. After you add shared storage, 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 coordinator, this SR becomes a shared SR for the pool. If the new pool coordinator does not have any shared storage, you have to create a new shared SR for the pool: see Creating a New SR.

Pool Requirements