XenServer resource pool requirements

A pool always has at least one physical host, known as the "pool master", that provides a single point of contact for all of the servers in the pool, known as "slaves", managing communication to other members of the pool as necessary.

If the pool master is shut down or unavailable, you will not able to connect to the pool until the master is online again or until you nominate one of the other members as the new pool master for the pool. Virtual machines that are started at the time the pool master became unavailable continue running. Note that every member of a resource pool contains all the information necessary to take on the role of master, if you need to replace a pool master.

Note

If the pool's master fails, automatic master reselection will only take place if High Availability is enabled. You can learn about High Availability in Chapter 8, Managing High Availability and Snapshots.

A resource pool is a homogeneous aggregate of one or more XenServer hosts, up to a maximum of 16. What is the definition of homogeneous?

A XenServer pool is homogeneous when:

• The CPUs on the server joining the pool are the same (in terms of vendor, model, and features) as the CPUs on servers already in the pool

• The server joining the pool is running the same version of XenServer software, at the same patch level, as servers already in the pool

• When you join a host to a pool, remember also that XenServer will enforce additional constraints, in particular:

  • It is not a member of an existing resource pool

  • It has no shared storage configured

  • There are no running or suspended Virtual Machines on the XenServer host you are joining to the pool

  • There are no active operations on the VMs in progress such as restart or shutdown

• When you want to join a new host remember to check the following:

  • Clock of the host joining the pool is synchronized to the same time as the pool master (for example, by using NTP)

  • Its primary management interface is not bonded (you can configure this once the host has successfully joined the pool)

  • Its management IP address is static (either configured on the host itself or by using an appropriate configuration on your DHCP server)

    Note

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

Why have we introduced the concept homogeneous? Because In XenServer 6.0, you can also create a heterogeneous pool. A pool is heterogeneous when you join disparate hosts together.

XenServer 6.0 makes it possible to create a heterogeneous pool by leveraging technologies in recent 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. CPU masking enables you to create pools of hosts with disparate CPUs and permits you to use the XenMotion feature safely.

Using XenServer to mask the CPU features of a new server, so that it will match the features of the existing servers in a pool, requires the following:

• 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

• The CPUs of the server joining the pool must support either Intel FlexMigration or AMD Enhanced Migration

• The features of the older CPUs must be a subset of the features of the CPUs of the server joining the pool

• The server joining the pool is running the same version of the XenServer software, with the same hotfixes installed, as servers already in the pool

  Note

  Heterogeneous resource pool creation is only available to XenServer Advanced editions and above.