Pool Requirements

A resource pool is a homogeneous or heterogeneous aggregate of one or more servers, up to a maximum of 16. 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.
  • To run HVM virtual machines, all CPUs must have virtualization enabled.

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 consistent IP address (a static IP address on the server or a static DHCP lease). 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 license as the servers already in the pool. For example, you cannot add a server with XenServer Standard license to an existing resource pool containing servers with XenServer Enterprise or other licenses. 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 pool requirements stated above, CPUs on a server joining a homogeneous resource pool must be the same (in terms of vendor, model, and features) as the CPUs on servers already in the pool.

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 leveraging 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 enables you to create pools of hosts with disparate CPUs but still safely support live migrations. Servers joining heterogeneous pools should meet the following requirements:

  • the CPUs of the server joining the pool must be of the same vendor (that is, AMD, Intel) as the CPUs on servers already in the pool, though the specific type, (family, model and stepping numbers) need not be.
  • the CPUs of the server joining the pool must support either Intel FlexMigration or AMD Enhanced Migration.

XenServer simplifies the support for heterogeneous pools. In XenServer 6.5 and earlier versions, a new pool member with a feature set different to that of the pool had to be CPU masked by users before it was allowed to join the pool. Starting with XenServer 7.0, servers can be added 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 will continue 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. In scenarios where a pool level drops when a less-capable server joins the pool, a running VM can be migrated to any server in the pool, except the newly added server. When you attempt to move or migrate a VM to a different server within or across pools, XenServer performs migration checks to compare the VM’s feature set against the feature set of the destination server. If the feature sets are found to be compatible, the VM will be allowed to migrate. This enables the VM to move freely within and across pools, regardless of the CPU features the VM is using. If you use Workload Balancing (WLB) to choose an optimal destination server to migrate your VM, a server with incompatible feature set will not be recommended as the destination server.


To update a running VM to use the pool’s new feature set, the VM must be powered off and then started. 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 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.

Pool Requirements