Manage your pools

This article describes some of the actions you can take to manage your pool.

To manage individual hosts, see Manage your hosts.

Create a resource pool

Resource pools can be created using XenCenter or the CLI. When a new host joins a resource pool, the joining host synchronizes its local database with the pool-wide one, and inherits some settings from the pool:

• VM, local, and remote storage configuration are added to the pool-wide database. This configuration is applied to the joining host in the pool unless you explicitly make the resources shared after the host joins the pool.

• The joining host inherits existing shared storage repositories in the pool. Appropriate PBD records are created so that the new host can access existing shared storage automatically.

• Networking information is partially inherited to the joining host: the structural details of NICs, VLANs, and bonded interfaces are all inherited, but policy information is not. This policy information, which must be reconfigured, includes:

  • The IP addresses of the management NICs, which are preserved from the original configuration.

  • The location of the management interface, which remains the same as the original configuration. For example, if the other pool hosts have management interfaces on a bonded interface, the joining host must be migrated to the bond after joining.

  • Dedicated storage NICs, which must be reassigned to the joining host from XenCenter or the CLI, and the PBDs replugged to route the traffic accordingly. This is because IP addresses are not assigned as part of the pool join operation, and the storage NIC works only when this is correctly configured. For more information on how to dedicate a storage NIC from the CLI, see Manage networking.

  • Reconfigure the management interface and move it on to a physical NIC before adding the host to the pool. After the host has joined the pool, you can reconfigure the management interface again.

Before creating a resource pool, review the requirements for the pool and the joining host. For more information, see Resource pools.

Add a host to a pool by using the xe CLI

Note:

We recommend updating your pool and the joining host to the same level before attempting the join.

1. Open a console on the XenServer host that you want to join to a pool.

2. Join the XenServer host to the pool by issuing the command:

   xe pool-join master-address=<address of pool coordinator> master-username=<administrator username> master-password=<password>
   <!--NeedCopy-->
   

   The master-address must be set to the fully qualified domain name of the pool coordinator. The password must be the administrator password set when the pool coordinator was installed.

Note:

When you join a host to a pool, the administrator password for the joining host is automatically changed to match the administrator password of the pool coordinator.

XenServer hosts belong to an unnamed pool by default. To create your first resource pool, rename the existing nameless pool. Use tab-complete to find the pool_uuid:

xe pool-param-set name-label="New Pool" uuid=pool_uuid
<!--NeedCopy-->

Create heterogeneous resource pools

XenServer simplifies expanding deployments over time by allowing disparate host hardware to be joined in to a resource pool, known as heterogeneous resource pools. Heterogeneous resource pools are made possible by using technologies in Intel (FlexMigration) and AMD (Extended Migration) CPUs that provide CPU “masking” or “leveling”. The CPU masking and leveling features allow a CPU to be configured to appear as providing a different make, model, or functionality than it actually does. This feature enables you to create pools of hosts with disparate CPUs but still safely support live migration.

Note:

The CPUs of XenServer hosts joining heterogeneous pools must be of the same vendor (that is, AMD, Intel) as the CPUs of the hosts already in the pool. However, the hosts are not required to be the same type at the level of family, model, or stepping numbers.

XenServer simplifies the support of heterogeneous pools. Hosts can now 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 host 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 host joins the pool, a running VM can be migrated to any host in the pool, except the newly added host. When you move or migrate a VM to a different host within or across pools, XenServer compares the VM’s feature set against the feature set of the destination host. If the feature sets are found to be compatible, the VM is 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 to select an optimal destination host to migrate your VM, a host with an incompatible feature set will not be recommended as the destination host.

Add shared storage

For a complete list of supported shared storage types, see Storage repository formats. This section shows how shared storage (represented as a storage repository) can be created on an existing NFS server.

To add NFS shared storage to a resource pool by using the CLI

1. Open a console on any XenServer host in the pool.

2. Create the storage repository on server:/path by issuing the following command:

   xe sr-create content-type=user type=nfs name-label="Example SR" shared=true \
       device-config:server=server \
       device-config:serverpath=path
   <!--NeedCopy-->
   

   device-config:server is the host name of the NFS server and device-config:serverpath is the path on the NFS server. As shared is set to true, shared storage is automatically connected to every XenServer host in the pool. Any XenServer hosts that join later are also connected to the storage. The Universally Unique Identifier (UUID) of the storage repository is printed on the screen.

3. Find the UUID of the pool by running the following command:

   xe pool-list
   <!--NeedCopy-->
   

4. Set the shared storage as the pool-wide default with the following command:

   xe pool-param-set uuid=pool_uuid default-SR=sr_uuid
   <!--NeedCopy-->
   

   As the shared storage has been set as the pool-wide default, all future VMs have their disks created on shared storage by default. For information about creating other types of shared storage, see Storage repository formats.

Remove XenServer hosts from a resource pool

Note:

Before removing any XenServer host from a pool, ensure that you shut down all the VMs running on that host. Otherwise, you can see a warning stating that the host cannot be removed.

When you remove (eject) a host from a pool, the machine is rebooted, reinitialized, and left in a state similar to a fresh installation. Do not eject XenServer hosts from a pool if there is important data on the local disks.

To remove a host from a resource pool by using the CLI

1. Open a console on any host in the pool.

2. Find the UUID of the host by running the following command:

   xe host-list
   <!--NeedCopy-->
   

3. Eject the required host from the pool:

   xe pool-eject host-uuid=host_uuid
   <!--NeedCopy-->
   

   The XenServer host is ejected and left in a freshly installed state.

   Warning:

   Do not eject a host from a resource pool if it contains important data stored on its local disks. All of the data is erased when a host is ejected from the pool. If you want to preserve this data, copy the VM to shared storage on the pool using XenCenter, or the xe vm-copy CLI command.

When XenServer hosts containing locally stored VMs are ejected from a pool, the VMs will be present in the pool database. The locally stored VMs are also visible to the other XenServer hosts. The VMs do not start until the virtual disks associated with them have been changed to point at shared storage seen by other XenServer hosts in the pool, or removed. Therefore, we recommend that you move any local storage to shared storage when joining a pool. Moving to shared storage allows individual XenServer hosts to be ejected (or physically fail) without loss of data.

Note:

When a host is removed from a pool that has its management interface on a tagged VLAN network, the machine is rebooted and its management interface will be available on the same network.

Rotate the pool secret

The pool secret is a secret shared among the hosts in a pool that enables the host to prove its membership to a pool.

Because users with the Pool Admin role can discover this secret, it is good practice to rotate the pool secret if one of these users leaves your organization or loses their Pool Admin role.

You can rotate the pool secret by using XenCenter or the xe CLI.

XenCenter

To rotate the pool secret for a pool by using XenCenter, complete the following steps:

1. In the Resources pane, select the pool or any host in the pool.
2. On the Pool menu, select Rotate Pool Secret.

When you rotate the pool secret, you are also prompted to change the root password. If you rotated the pool secret because you think that your environment has been compromised, ensure that you also change the root password of the pool coordinator. For more information, see Change the password.

xe CLI

To rotate the pool secret by using the xe CLI, run the following command on a host in the pool:

xe pool-secret-rotate
<!--NeedCopy-->

If you rotated the pool secret because you think that your environment has been compromised, ensure that you also change the root password. For more information, see Change the password.

Enable IGMP snooping on your XenServer pool

XenServer sends multicast traffic to all guest VMs leading to unnecessary load on host devices by requiring them to process packets they have not solicited. Enabling IGMP snooping prevents hosts on a local network from receiving traffic for a multicast group they have not explicitly joined, and improves the performance of multicast. IGMP snooping is especially useful for bandwidth-intensive IP multicast applications such as IPTV.

Notes:

• IGMP snooping is available only when the network back-end uses Open vSwitch.

• When enabling this feature on a pool, it may also be necessary to enable IGMP querier on one of the physical switches. Or else, multicast in the sub network falls back to broadcast and may decrease XenServer performance.

• When enabling this feature on a pool running IGMP v3, VM migration or network bond failover results in IGMP version switching to v2.

• To enable this feature with a GRE network, users must set up an IGMP Querier in the GRE network. Alternatively, you can forward the IGMP query message from the physical network into the GRE network. Or else, multicast traffic in the GRE network can be blocked.

You can enable IGMP snooping on a pool by using XenCenter or the xe CLI.

XenCenter

1. Navigate to Pool Properties.
2. Select Network Options. Here you can enable or disable IGMP snooping.

xe CLI

1. Get the pool UUID:

   xe pool-list

2. Enable/disable IGMP snooping for the pool:

   xe pool-param-set [uuid=pool-uuid] [igmp-snooping-enabled=true|false]

After enabling IGMP snooping, you can view the IGMP snooping table using the xe CLI.

View the IGMP snooping table

Use the following command to view the IGMP snooping table:

ovs-appctl mdb/show [bridge name]

Note:

You can get the bridge name by using xe network-list. These bridge names can be xenbr0, xenbr1, xenapi, or xapi0.

This outputs a table with four columns:

• port: The port of the switch (OVS).
• VLAN: The VLAN ID of the traffic.
• GROUP: The multicast group that the port solicited.
• Age: The age of this record in seconds.

If the GROUP is a multicast group address, this means an IGMP Report message is received on the associated switch port. This means that a receiver (member) of the multicast group is listening on this port.

Take the following example which contains two records:

The first record shows that there is a receiver listening on port 14 for the multicast group 227.0.0.1. The Open vSwitch forwards traffic destined for the 227.0.0.1 multicast group to listening ports for this group only (in this example, port 14), rather than broadcasting to all ports. The record linking port 14 and group 227.0.0.1 was created 15 seconds ago. By default, the timeout interval is 300 seconds. This means that if the switch does not receive any further IGMP Report messages on port 14 for 300 seconds after adding the record, the record expires and is removed from the table.

In the second record, the GROUP is querier, meaning that IGMP Query messages have been received on the associated port. A querier periodically sends IGMP Query messages, which are broadcasted to all switch ports, to determine which network nodes are listening on a multicast group. Upon receiving an IGMP Query message, the receiver responds with an IGMP Report message, which causes the receiver’s multicast record to refresh and avoid expiration.

The VLAN column indicates to the VLAN that a receiver/querier lives. ‘0’ means native VLAN. If you want to run multicast on some tagged VLAN, ensure that there are records on the VLAN.

Note:

For the VLAN scenario, you must have a querier record with a VLAN column value equal to the VLAN ID of the network, otherwise multicast won’t work in the VLAN network.

Enable migration stream compression on your XenServer pool

During the live migration of a VM, its memory is transferred as a data stream between two hosts using the network. The migration stream compression feature compresses this data stream, speeding up the memory transfer on slow networks. This feature is disabled by default, but this can be changed by using XenCenter or the xe CLI. For more information, see Pool Properties - Advanced and Pool parameters. Alternatively, you can enable compression when migrating a VM by using the command line. For more information, see the vm-migrate command in VM Commands.

Change the NTP configuration on a server

You can update the NTP configuration for your server from xsconsole.

1. In the host console, type xsconsole.
2. In xsconsole, go to Network and Management Interfaces > Network Time (NTP).
3. Enter your password to proceed.
4. From the Configure Network Time menu, choose the option you want to configure.

Export resource pool data

The Export Resource Data option allows you to generate a resource data report for your pool and export the report into an .xls or .csv file. This report provides detailed information about various resources in the pool such as hosts, networks, storage, virtual machines, VDIs, and GPUs. This feature enables administrators to track, plan, and assign resources based on various workloads such as CPU, storage, and network.

Note:

Export Resource Pool Data is available for XenServer Premium Edition customers.

The list of resources and various types of resource data that are included in the report:

Server:

• Name
• Pool Coordinator
• UUID
• Address
• CPU Usage
• Network (avg/max KBs)
• Used Memory
• Storage
• Uptime
• Description

Networks:

• Name
• Link Status
• MAC
• MTU
• VLAN
• Type
• Location

VDI:

• Name
• Type
• UUID
• Size
• Storage
• Description

Storage:

• Name
• Type
• UUID
• Size
• Location
• Description

VMs:

• Name
• Power State
• Running on
• Address
• MAC
• NIC
• Operating System
• Storage
• Used Memory
• CPU Usage
• UUID
• Uptime
• Template
• Description

GPU:

• Name
• Servers
• PCI Bus Path
• UUID
• Power Usage
• Temperature
• Used Memory
• Computer Utilization

Note:

Information about GPUs is available only if there are GPUs attached to your XenServer host.

To export resource data

1. In the XenCenter Navigation pane, select Infrastructure and then select the pool.

2. Select the Pool menu and then Export Resource Data.

3. Browse to a location where you would like to save the report and then click Save.