Skip navigation links
Overview Expand Overview
Products Expand Products
Solutions Expand Solutions
Support Services Expand Support Services
Partners Expand Partners
About Us Expand About Us
How to Buy

Chapter 2. XenServer Hosts and Resource Pools

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.

This chapter describes how Resource Pools can be created through a series of examples using the xe command line interface (CLI). A simple NFS-based shared storage configuration is presented and a number of simple VM management examples are discussed. Procedures for dealing with physical node failures are also described.

A pool always has at least one physical node, known as the “master”. Other physical nodes join existing pools and are described as “slaves”. Only the master node exposes an administration interface (used by XenCenter and the CLI); the master will forward commands to individual slaves as necessary.

2.1. Requirements for creating Resource Pools

A Resource Pool is an aggregate of one or more homogeneous XenServer Hosts, up to a maximum of 16. The definition of homogeneous is:

  • each CPU is from the same vendor (in particular AMD-V and Intel VT CPUs cannot be mixed);

  • each CPU is the same model (except for stepping); and

  • each CPU has the same feature flags.

In addition to being homogeneous, an individual XenServer Host can only join a Resource Pool if:

  • it has a static IP address (either manually assigned or via DHCP);

  • it is not a member of an existing Resource Pool;

  • it has a clock synchronized to the pool master server (e.g. via NTP);

  • it has no shared storage configured; and

  • there are no running or suspended VMs on the XenServer Host;

XenServer Hosts in Resource Pools may contain different numbers of physical network interfaces. Local storage repositories may also exist, of varying size. In practice, it is often difficult to obtain multiple hosts 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 may be forced.


The requirement for a XenServer Host to have a static IP address to be part of a Resource Pool also applies to the servers providing the shared NFS or iSCSI storage.

Although not a strict technical requirement for creating a Resource Pool, the advantages of pools (e.g. the ability to dynamically choose on which XenServer Host to run a VM and to dynamically move a VM between XenServer Hosts) are only available if the Pool has one or more shared Storage Repositories. As a rule of thumb, you should postpone creating a pool of XenServer Hosts until shared storage is available. Once shared storage has been added, we recommend you to move existing VMs whose disks are in local storage into shared storage. This can be done using the xe vm-copy command or XenCenter.