XenServer

Hosts and resource pools

November 5, 2024

Contributed by:

X X

This section 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 several simple VM management examples are discussed. It also contains procedures for dealing with physical node failures.

XenServer hosts and resource pools overview

A resource pool comprises multiple XenServer host installations, bound together to a single managed entity which can host Virtual Machines. If combined with shared storage, a resource pool enables VMs to be started on any XenServer host which has sufficient memory. The VMs can then be dynamically moved among XenServer hosts while running with a minimal downtime (live migration). If an individual XenServer host suffers a hardware failure, the administrator can restart failed VMs on another XenServer host in the same resource pool. When high availability is enabled on the resource pool, VMs automatically move to another host when their host fails. Up to 64 hosts are supported per resource pool, although this restriction is not enforced.

A pool always has at least one physical node, known as the pool coordinator (formerly “pool master”). The coordinator node exposes an administration interface (used by XenCenter and the XenServer command line interface, known as the xe CLI). The coordinator forwards commands to individual members as necessary.

Note:

When the pool coordinator fails, coordinator re-election takes place only if high availability is enabled.

Requirements for creating resource pools

A resource pool is a homogeneous (or heterogeneous with restrictions) aggregate of one or more XenServer hosts, up to a maximum of 64. The definition of homogeneous is:

CPUs on the host joining the pool are the same (in terms of the vendor, model, and features) as the CPUs on hosts already in the pool.
The host joining the pool is running the same version of XenServer software, at the same patch level, as the hosts already in the pool.

The software enforces extra constraints when joining a host to a pool. In particular, XenServer checks that the following conditions are true for the host joining the pool:

The host is not a member of an existing resource pool.
The host has no shared storage configured.
The host is not hosting any running or suspended VMs.
No active operations are in progress on the VMs on the host, such as a VM shutting down.
The clock on the host is synchronized to the same time as the pool coordinator (for example, by using NTP).
The management interface of the host is not bonded. You can configure the management interface when the host successfully joins the pool.
The management IP address is static, either configured on the host itself or by using an appropriate configuration on your DHCP server.

XenServer hosts in resource pools can contain different numbers of physical network interfaces and have local storage repositories 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 it is acceptable to have hosts with varying CPUs as part of the same pool, you can force the pool-joining operation by passing the --force parameter.

All hosts in the pool must be in the same site and connected by a low latency network.

Note:

Servers providing shared NFS or iSCSI storage for the pool must have a static IP address.

A pool must contain shared storage repositories to select on which XenServer host to run a VM and to move a VM between XenServer hosts dynamically. If possible create a pool after shared storage is available. We recommend that you move existing VMs with disks located in local storage to shared storage after adding shared storage. You can use the xe vm-copy command or use XenCenter to move VMs.

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 is 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.

Note:

You can only join a new host to a resource pool when the host’s management interface is on the same tagged VLAN as that of the resource pool.

Add a host to a pool by using the xe CLI

Note:

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

Open a console on the XenServer host that you want to join to a pool.
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>

```
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

Open a console on any XenServer host in the pool.
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

```
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.
Find the UUID of the pool by running the following command:
```
xe pool-list

```
Set the shared storage as the pool-wide default with the following command:
```
xe pool-param-set uuid=pool_uuid default-SR=sr_uuid

```
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

Open a console on any host in the pool.
Find the UUID of the host by running the following command:
```
xe host-list

```
Eject the required host from the pool:
```
xe pool-eject host-uuid=host_uuid

```
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.

Prepare a pool of XenServer hosts for maintenance

Before performing maintenance operations on a host that is part of a resource pool, you must disable it. Disabling the host prevents any VMs from being started on it. You must then migrate its VMs to another XenServer host in the pool. You can do this by placing the XenServer host in to Maintenance mode using XenCenter. For more information, see Run in maintenance mode in the XenCenter documentation.

Backup synchronization occurs every 24 hrs. Placing the pool coordinator in to maintenance mode results in the loss of the last 24 hrs of RRD updates for offline VMs.

Warning:

We highly recommend rebooting all XenServer hosts before installing an update and then verifying their configuration. Some configuration changes only take effect when the XenServer host is rebooted, so the reboot may uncover configuration problems that can cause the update to fail.

To prepare a host in a pool for maintenance operations by using the CLI

Run the following command:
```
xe host-disable uuid=XenServer_host_uuid
xe host-evacuate uuid=XenServer_host_uuid

```
This command disables the XenServer host and then migrates any running VMs to other XenServer hosts in the pool.
Perform the desired maintenance operation.
Enable the XenServer host when the maintenance operation is complete:
```
xe host-enable

```
Restart any halted VMs and resume any suspended VMs.

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

In the XenCenter Navigation pane, select Infrastructure and then select the pool.
Select the Pool menu and then Export Resource Data.
Browse to a location where you would like to save the report and then click Save.

Host power-on

Powering on hosts remotely

You can use the XenServer host Power On feature to turn a host on and off remotely, either from XenCenter or by using the CLI.

To enable host power, the host must have one of the following power-control solutions:

Wake on LAN enabled network card.
Intelligent Platform Management Interface (IPMI).
A custom script based on the management API that enables you to turn the power on and off through XenServer. For more information, see Configuring a custom script for the Host Power On feature in the following section.

Using the Host Power On feature requires two tasks:

Ensure the hosts in the pool support controlling the power remotely. For example, they have Wake on LAN functionality or support IPMI, or you have created a custom script.
Enable the Host Power On functionality using the CLI or XenCenter.

Use the CLI to manage host power-on

You can manage the Host Power On feature using either the CLI or XenCenter. This section provides information about managing it with the CLI.

Host Power On is enabled at the host level (that is, on each XenServer).

After you enable Host Power On, you can turn on hosts using either the CLI or XenCenter.

To enable host power-on by using the CLI

Run the command:

xe host-set-power-on-mode host=<host uuid> \
    power-on-mode=("" , "wake-on-lan", "IPMI","custom") \
    power-on-config=key:value
<!--NeedCopy-->

To turn on hosts remotely by using the CLI

Run the command:

xe host-power-on host=<host uuid>
<!--NeedCopy-->

Configure a custom script for the Host Power On feature

If your host’s remote-power solution uses a protocol that is not supported by default (such as Wake-On-Ring or Intel Active Management Technology), you can create a custom Linux Python 3 script to turn on your XenServer computers remotely. However, you can also create custom scripts for IPMI and Wake on LAN remote-power solutions.

This section provides information about configuring a custom script for Host Power On using the key/value pairs associated with the XenServer API call host.power_on.

When you create a custom script, run it from the command line each time you want to control power remotely on a XenServer host. Alternatively, you can specify it in XenCenter and use the XenCenter UI features to interact with it.

The XenServer API is documented in the XenServer Management API.

Warning:

Do not change the scripts provided by default in the /etc/xapi.d/plugins/ directory. You can include new scripts in this directory, but you must never change the scripts contained in that directory after installation.

Key/Value Pairs

To use Host Power On, configure the host.power_on_mode and host.power_on_config keys. See the following section for information about the values.

There is also an API call that lets you set these fields simultaneously:

void host.set_host_power_on_mode(string mode, Dictionary<string,string> config)
<!--NeedCopy-->

host.power_on_mode

Definition: Contains key/value pairs to specify the type of remote-power solution.
Possible values:
- An empty string, representing power-control disabled.
- “IPMI”: Lets you specify Intelligent Platform Management Interface.
- “wake-on-lan”: Lets you specify Wake on LAN.
- Any other name (used to specify a custom power-on script). This option is used to specify a custom script for power management.
Type: string

host.power_on_config

Definition: Contains key/value pairs for mode configuration. Provides additional information for IPMI.
Possible values:
- If you configured IPMI as the type of remote-power solution, you must also specify one of the following keys:
  - “power_on_ip”: The IP address you specified configured to communicate with the power-control card.
  - “power_on_user”: The IPMI user name associated with the management processor, which you might have changed from its factory default settings.
  - “power_on_password_secret”: Specifies using the secrets feature to secure your password.
- To use the secrets feature to store your password, specify the key “power_on_password_secret”. For more information, see Secrets.
Type: Map (string, string)

Sample script

The sample script imports the XenServer API, defines itself as a custom script, and then passes parameters specific to the host you want to control remotely. You must define the parameters session in all custom scripts.

The result appears when the script is unsuccessful.

import XenAPI
def custom(session,remote_host,
power_on_config):
result="Power On Not Successful"
for key in power_on_config.keys():
result=result+''
key=''+key+''
value=''+power_on_config[key]
return result
<!--NeedCopy-->

Note:

After creating the script, save it in /etc/xapi.d/plugins with a .py extension.

Communicate with XenServer hosts and resource pools

TLS

XenServer uses the TLS 1.2 protocol to encrypt management API traffic. Any communication between XenServer and management API clients (or appliances) uses the TLS 1.2 protocol.

Important:

We do not support customer modifications to the cryptographic functionality of the product.

XenServer uses the following cipher suite:

ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256

SSH

When using an SSH client to connect directly to the XenServer host the following algorithms can be used:

Ciphers:

aes128-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com

MACs:

hmac-sha2-256
hmac-sha2-512
hmac-sha1

KexAlgorithms:

curve25519-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
diffie-hellman-group14-sha1

HostKeyAlgorithms:

ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-ed25519
ssh-rsa

If you want to disable SSH access to your XenServer host, you can do this in xsconsole.

From XenCenter, open the host console and log in as root.
Type xsconsole.
In xsconsole, go to Remote Service Configuration > Enable/Disable Remote Shell.

The console displays whether remote shell is enabled.
To change whether the remote shell is enabled or disabled, press Enter.

Important:

We do not support customer modifications to the cryptographic functionality of the product.

Install a TLS certificate on your host

The XenServer host comes installed with a default TLS certificate. However, to use HTTPS to secure communication between XenServer and Citrix Virtual Apps and Desktops, install a certificate provided by a trusted certificate authority.

This section describes how to install certificates by using the xe CLI. For information about working with certificates by using XenCenter, see the XenCenter documentation.

Ensure that your TLS certificate and its key meet the following requirements:

The certificate and key pair are an RSA key.
The key matches the certificate.
The key is provided in a separate file to the certificate.
The certificate is provided in a separate file to any intermediate certificates.
The key file must be one of the following types: .pem or .key.
Any certificate files must be one of the following types: .pem, .cer, or .crt.
The key is greater than or equal to 2048 bits and less than or equal to 4096 bits in length.
The key is an unencrypted PKCS #8 key and does not have a passkey.
The key and certificate are in base-64 encoded ‘PEM’ format.
The certificate is valid and has not expired.
The signature algorithm is SHA-2 (SHA256).

The xe CLI warns you when the certificate and key you choose do not meet these requirements.

Where do I get a TLS certificate?

You might already have a trusted certificate that you want to install on your XenServer host.
Alternatively, you can create a certificate on your server and send it to your preferred certificate authority to be signed. This method is more secure as the private key can remain on the XenServer host and not be copied between systems.

Creating a TLS certificate has the following steps:

1. Generate a certificate signing request

First, generate a private key and certificate signing request. On the XenServer host, complete the following steps:

To create a private key file, run the following command:
```
openssl genrsa -des3 -out privatekey.pem 2048

```
You are prompted for a pass phrase. This pass phrase is removed in a following step.

Remove the pass phrase from the key:

openssl rsa -in privatekey.pem -out privatekey.nop.pem
<!--NeedCopy-->

Create the certificate signing request by using the private key:

openssl req -new -key privatekey.nop.pem -out csr
<!--NeedCopy-->

Follow the prompts to provide the information necessary to generate the certificate signing request.
- Country Name. Enter the TLS Certificate country codes for your country. For example, CA for Canada or JM for Jamaica. You can find a list of TLS Certificate country codes on the web.
- State or Province Name (full name). Enter the state or province where the pool is located. For example, Massachusetts or Alberta.
- Locality Name. The name of the city where the pool is located.
- Organization Name. The name of your company or organization.
- Organizational Unit Name. Enter the department name. This field is optional.
- Common Name. Enter the FQDN of your XenServer host. We recommend specifying either an FQDN or an IP address that does not expire.
- Email Address. This email address is included in the certificate when you generate it.
The certificate signing request is saved in the current directory and is named csr.
Display the certificate signing request in the console window by running the following command:
```
cat csr

```

Copy the entire certificate signing request and use this information to request the certificate from the certificate authority.

Example certificate signing request:

-----BEGIN CERTIFICATE REQUEST-----
MIIDBDCCAewCAQAwgYsxCzAJBgNVBAYTAlVLMRcwFQYDVQQIDA5DYW1icmlkZ2Vz
aGlyZTESMBAGA1UEBwwJQ2FtYnJpZGdlMRIwEAYDVQQKDAlYZW5TZXJ2ZXIxFTAT
...
SdYCkFdo+85z8hBULFzSH6jgSP0UGQU0PcfIy7KPKyI4jnFQqeCDvLdWyhtAx9gq
Fu40qMSm1dNCFfnACRwYQkQgqCt/RHeUtl8srxyZC+odbunnV+ZyQdmLwLuQySUk
ZL8naumG3yU=
-----END CERTIFICATE REQUEST-----
<!--NeedCopy-->

2. Send the certificate signing request to a certificate authority

Now that you have generated the certificate signing request, you can submit the request to your organization’s preferred certificate authority.

A certificate authority is a trusted third-party that provides digital certificates. Some certificate authorities require the certificates to be hosted on a system that is accessible from the internet. We recommend not using a certificate authority with this requirement.

The certificate authority responds to your signing request and provides the following files:

the signed certificate
if applicable, an intermediate certificate

You can now install all these files on your XenServer host.

3. Install the signed certificate on your XenServer host

After the certificate authority reponds to the certificate signing request, complete the following steps to install the certificate on your XenServer host:

Get the signed certificate and, if the certificate authority has one, the intermediate certificate from the certificate authority.
Copy the key and certificates to the XenServer host.

Run the following command on the host:

xe host-server-certificate-install certificate=<path_to_certificate_file> private-key=<path_to_private_key> certificate-chain=<path_to_chain_file>

The certificate-chain parameter is optional.

For additional security, you can delete the private key file after the certificate is installed.

Manage the administrator password

When you first install a XenServer host, you set an administrator or root password. You use this password to connect XenCenter to your host or (with user name root) to log into xsconsole, the system configuration console.

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

Note:

XenServer administrator passwords must contain only printable ASCII characters.

Change the password

You can use XenCenter, the xe CLI, or xsconsole to change the administrator password.

XenCenter

To change the administrator password for a pool or standalone host by using XenCenter, complete the following steps:

In the Resources pane, select the pool or any host in the pool.
On the Pool menu or on the Server menu, select Change Server Password.

To change the root password of a standalone host, select the host in the Resources pane, and click Password and then Change from the Server menu.

If XenCenter is configured to save your host login credentials between sessions, the new password is remembered. For more information, see Store your host connection state.

After changing the administrator password, rotate the pool secret. For more information, see Rotate the pool secret.

xe CLI

To change the administrator password by using the xe CLI, run the following command on a host in the pool:

  xe user-password-change new=<new_password>
<!--NeedCopy-->

Note:

Ensure that you prefix the command with a space to avoid storing the plaintext password in the command history.

After changing the administrator password, rotate the pool secret. For more information, see Rotate the pool secret.

xsconsole

To change the administrator password for a pool or a standalone host by using xsconsole, complete the following steps:

On the pool coordinator, go to the console.
Log in as root.
Type xsconsole. Press Enter. The xsconsole is displayed.
In xsconsole, use the arrow keys to navigate to the Authentication option. Press Enter.
Navigate to Change Password. Press Enter.
Authenticate with the administrator password.
In the Change Password dialog:
1. Enter your current password.
2. Enter a new password.
3. Enter the new password again to confirm it.
The Password Change Successful screen is displayed. Press Enter to dismiss.

If the host is pool coordinator, this updated password is now propagated to the other hosts in the pool.

After changing the administrator password, rotate the pool secret. For more information, see Rotate the pool secret.

Reset a lost root password

If you lose the administrator (root) password for your XenServer host, you can reset the password by accessing the host directly.

Reboot the XenServer host.
When the GRUB menu shows, press e to edit the boot menu entry.
Add init=/sysroot/bin/sh to the line that starts with module2.
Press Ctrl-X to boot into a root shell.

At the command shell, run the following commands:

chroot /sysroot
passwd

(type the new password twice)

sync
/sbin/reboot -f
<!--NeedCopy-->

If the host is pool coordinator, this updated password is now propagated to the other hosts in the pool.

After changing the administrator password, rotate the pool secret.

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:

In the Resources pane, select the pool or any host in the pool.
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. 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

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

xe CLI

Get the pool UUID:

xe pool-list
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 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 was 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:

port	VLAN	GROUP	Age
14	0	227.0.0.1	15
1	0	querier	24

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 should 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.

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

The official version of this content is in English. Some of the Cloud Software Group documentation content is machine translated for your convenience only. Cloud Software Group has no control over machine-translated content, which may contain errors, inaccuracies or unsuitable language. No warranty of any kind, either expressed or implied, is made as to the accuracy, reliability, suitability, or correctness of any translations made from the English original into any other language, or that your Cloud Software Group product or service conforms to any machine translated content, and any warranty provided under the applicable end user license agreement or terms of service, or any other agreement with Cloud Software Group, that the product or service conforms with any documentation shall not apply to the extent that such documentation has been machine translated. Cloud Software Group will not be held responsible for any damage or issues that may arise from using machine-translated content.

Was this helpful

Hosts and resource pools

November 5, 2024

Contributed by:

X X

November 5, 2024

Contributed by:

X X

XenServer hosts and resource pools overview
Requirements for creating resource pools
Create a resource pool
Add a host to a pool by using the xe CLI
Create heterogeneous resource pools
Add shared storage
Remove XenServer hosts from a resource pool
Prepare a pool of XenServer hosts for maintenance
Export resource pool data
Host power-on
Communicate with XenServer hosts and resource pools
Install a TLS certificate on your host
Manage the administrator password
Rotate the pool secret
Enable IGMP snooping on your XenServer pool
Enable migration stream compression on your XenServer pool
Change the NTP configuration on a server

Was this helpful

Hosts and resource pools

XenServer hosts and resource pools overview

Requirements for creating resource pools

Create a resource pool

Add a host to a pool by using the xe CLI

Create heterogeneous resource pools

Add shared storage

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

Remove XenServer hosts from a resource pool

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

Prepare a pool of XenServer hosts for maintenance

To prepare a host in a pool for maintenance operations by using the CLI

Export resource pool data

To export resource data

Host power-on

Powering on hosts remotely

Use the CLI to manage host power-on

To enable host power-on by using the CLI

To turn on hosts remotely by using the CLI

Configure a custom script for the Host Power On feature

Key/Value Pairs

host.power_on_mode

host.power_on_config

Sample script

Communicate with XenServer hosts and resource pools

TLS

SSH

Install a TLS certificate on your host

Where do I get a TLS certificate?

1. Generate a certificate signing request

2. Send the certificate signing request to a certificate authority

3. Install the signed certificate on your XenServer host

Manage the administrator password

Change the password

XenCenter

xe CLI

xsconsole

Reset a lost root password

Rotate the pool secret

XenCenter

xe CLI

Enable IGMP snooping on your XenServer pool

XenCenter

xe CLI

View the IGMP snooping table

Enable migration stream compression on your XenServer pool

Change the NTP configuration on a server

In this article