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.
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.
In addition to the hardware prerequisites identified above, there are a number of other configuration prerequisites for a server joining a pool:
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.