XCP-ng: Evolution du Lab V2.0 - Installation de Xen Orchestra et création du pool

Introduction

Xen Orchestra

Xen Orchestra, tout comme vCenter pour ESXi, est un outil de gestion centralisée qui permet de créer des groupes d'hyperviseurs pour assurer des fonctionnalités de haute disponibilité et de déplacement de VM à chaud.

À l'image de vCenter, Xen Orchestra peut être stoppé sans pénalité sur les VMs et sur les process de HA ; il permet de configurer et d'initier l'ensemble, mais n'est pas critique pour la disponibilité de la plateforme.

Les pools

Côté XCP-ng, on ne parle pas de cluster, mais de pool.

La mise en place d'un pool permet de débloquer entre autres les fonctionnalités suivantes :

Pour avoir un HA fonctionnel, il faut un minimum de trois nodes. En effet, un pool se base sur l'élection d'un master. C'est un des serveurs du pool retenu comme point d'entrée pour toute la gestion des activités et des décisions au sein du pool. S'il venait à être indisponible, le pool survit, mais sa gestion n'est plus possible.

C'est pourquoi, même si un pool peut être établi avec deux nodes (cas de mon premier lab), si on souhaite du HA, il faut un troisième node afin de pouvoir procéder à une nouvelle élection d'un master en cas de perte du master par défaut.

On conseille donc toujours d'avoir un nombre impair de nodes.

Objectifs

Dans cette partie du tutoriel correspondant à la mise en place de mon lab V2.0 sous l'écosystème de Vates, on va s'attarder sur le déploiement de Xen Orchestra et de l'initialisation du pool.

Xen Orchestra peut s'installer selon trois manières différentes :

• Via une appliance fournie et maintenue par Vates . C'est la solution la plus simple et la plus adaptée à une production. Néanmoins, si son accès est gratuit, l'accès aux fonctionnalités avancées, comme la sauvegarde ou autre, n'est possible que via la souscription d'une licence.
• Via un script maintenu par Ronivay. C'est devenu un standard dans la communauté XCP-ng.
• Via la récupération des sources directement.

Qu'il s'agisse de l'installation par le script de Ronivay ou à partir des sources, ces deux méthodes permettent un usage complet de Xen Orchestra.

Néanmoins, bien que le script de Ronivay simplifie grandement les choses, j'ai retenu l'installation par les sources. Cela me permet de ne pas dépendre de solutions externes et c'est une méthode que j'avais déjà utilisée dans mon précédent lab. Je vais donc la reprendre en l'améliorant légèrement.

En ce qui concerne l'emplacement de Xen Orchestra, il est possible de choisir l'un des nœuds du futur pool pour cela. Comme il est admis d'exécuter vCenter sur un cluster VMware, il est tout à fait supporté d'exécuter une VM Xen Orchestra sur un pool.

Pour rappel, une fois le pool initié, la disponibilité de Xen Orchestra n'est pas critique pour le respect des fonctionnalités internes au pool.

Je vais donc partir sur la base de la VM Rocky Linux 10 déployée sur mon premier serveur XCP-ng, prdxcpsrv001, comme vue dans l'article précédent. Pour rappel, la VM est exécutée sur le SR local de prdxcpsrv001.

Déploiement de Xen Orchestra

Prérequis

La première chose à faire va être d'installer tous les prérequis pour la compilation de Xen Orchestra à partir des sources.

sudo dnf install -y epel-release
                sudo dnf groupinstall "Development Tools" -y \
sudo dnf install -y git python3 make gcc-c++ cairo-devel libpng-devel nfs-utils openssl\
    glib2-devel libjpeg-turbo-devel pango-devel

Xen Orchestra est codé en nodeJS, il faut donc installer l'écosystème qui s'y rattache sur Rocky Linux 10.

Par contre, attention : étant donné que Rocky Linux 10 est assez récent au moment de la rédaction de ces lignes, il faut procéder à quelques ajustements pour qu'il soit compatible avec Xen Orchestra. Des modifications sont par exemple requises au niveau du choix de l'installation de nodeJS.

Il faut privilégier l'installation de la version de la branche 24 :

sudo dnf install -y nodejs24 nodejs24-npm

Puis procéder à la création des liens symboliques pour l'appel de la commande node et npm :

sudo ln -s /usr/bin/node-24 /usr/bin/node
node -v

sudo ln -sf /usr/bin/npm-24 /usr/bin/npm
npm -v

on installe également la commande yarn.

sudo npm install -g yarn
yarn -v

Xen Orchestra a également besoin d'une base in-memory. Traditionnellement c'était Redis qui était utilisé, mais les changements de licence opérés par son éditeur en 2024 ont poussé la communauté à un fork pour la création d'un produit alternatif baptisé Valkey.

C'est cette base qui est désormais disponible dans Rocky Linux 10 :

sudo dnf install valkey -y
sudo systemctl enable --now valkey

On peut vérifier que l'instance est correctement installée avec la commande :

valkey-cli ping

Usage d'un compte dédié

À partir de là, il est conseillé d'exploiter un compte spécifique pour l'exécution de Xen Orchestra. En l'occurrence, j'ai choisi de créer un compte xo:

sudo useradd -r -M -d /opt/xo -s /bin/bash xo

En complément, on va créer un fichier sudo pour cet utilisateur afin de l'autoriser à faire certaines actions en contexte root, notamment les commandes de montage :

sudo vim /etc/sudoers.d/xo

Le contenu est le suivant:

xo ALL=(root)NOPASSWD: /bin/mount, /bin/umount, /bin/findmnt

On sélectionne un dossier pour installer les fichiers binaires, dans mon cas /opt/xo Pour lequel on attribue les autorisations appropriées en relation avec l'utilisateur créé précédemment :

sudo mkdir /opt/xo
sudo chown -R xo:xo /opt/xo

Compilation des sources

On bascule ensuite dans le contexte de l'utilisateur xo :

sudo -u xo -i

On se place dans le répertoire fraîchement créé :

cd /opt/xo

Puis on clone le repo de Xen Orchestra :

git clone -b master https://github.com/vatesfr/xen-orchestra .

Puis on lance leur compilation avec les commandes :

yarn
yarn build

On peut ensuite sortir du contexte de l'utilisateur xo.

Configuration de Xen Orchestra

Paramétrage du fichier de configuration par défaut

On récupère ensuite le fichier de configuration par défaut pour le copier dans un dossier spécifique créé dans la branche /etc du serveur :

sudo mkdir -p /etc/xo-server
sudo cp /opt/xo/packages/xo-server/sample.config.toml /etc/xo-server/config.toml

On n'oublie pas d'autoriser l'utilisateur xo à lire ce fichier :

sudo chown xo:xo /etc/xo-server/config.toml

Puis on édite cette nouvelle configuration pour l'adapter à notre besoin :

sudo vi /etc/xo-server/config.toml

On confirme l'emplacement des data de Xen Orchestra :

datadir = '/var/lib/xo-server/data'

On active la redirection http vers https.

On fixe l'URL à laquelle notre instance de Xen Orchestra va répondre. En l'occurrence, pour moi, je mets le hostname de la VM.

On active l'écoute sur le port 8080 pour http et 8443 pour https.

On indique l'emplacement de la clef et du certificat qu'on va utiliser pour https (on va créer ces composants juste après).

On va aussi customiser le path de montage des volumes, notamment NFS que va utiliser Xen Orchestra via le path /mnt/xo-server (ne pas oublier de le créer et d'autoriser l'utilisateur xo a écrire) et surtout, on autorise Xen Orchestra à faire du sudo avec l'option useSudo = true (en cohérence avec notre fichier sudo créé précédemment).

On n'oublie pas de créer le répertoire /var/lib/xo-server et d'y attribuer les droits appropriés pour le compte xo, afin que ce dernier puisse y stocker les données de Xen Orchestra.

sudo mkdir -p /var/lib/xo-server
sudo chown xo:xo /var/lib/xo-server
            

De même on crée le répertoire /run/xo-server avec les droits appropriés pour le compte xo afin qu'il puisse créé le processus.

sudo mkdir -p /run/xo-server
sudo chown xo:xo /run/xo-server
            

Et le petit dernier le répertoire /mnt/xo-server toujours avec les bon droits pour le compte xo afin qu'il puisse créé des points de montage dans ce folder.

sudo mkdir -p /mnt/xo-server
sudo chown xo:xo /mnt/xo-server
            

Création du certificat

Pour être en cohérence avec cette configuration, on va générer la clef key.pem et le certificat certificate.pem, qu'on placera dans /etc/xo-server/certs/ (qu'on créera au préalable, et avec toujours les droits appropriés pour l'utilisateur xo).

Je ne vais pas m'attarder sur ce point, l'idée n'est pas d'expliquer comment faire un certificat, chacun peut utiliser la méthode de son choix en fonction de son architecture et de ses habitudes.

Personnellement, je me contente d'appeler openssl pour générer mon CSR (Certificate Signing Request) et ma clef :

sudo openssl req -new -nodes -sha256 -keyout key.pem -out xo.csr -newkey rsa:4096 \
  -subj "/C=FR/ST=Ile-de-France/L=Paris/O=COOLCORP/OU=Infrastructure/CN=prdxcpxor501.coolcorp.priv" \
  -reqexts req_ext -config openssl-san.cnf

Puis je soumets mon CSR à ma PKI interne, en l'occurrence une architecture Windows ADCS, pour récupérer mon certificat :

certreq -attrib "CertificateTemplate:TPL-SRV-WEB-DEFAULT" -submit .\xo.csr

Je place le contenu de la clef et du certificat dans le bon dossier sur le serveur et je n'oublie pas d'attribuer les bons droits pour que le compte xo puisse accéder à ces derniers :

sudo mkdir -p /etc/xo-server/certs/
sudo chown xo -R /etc/xo-server/certs/

Mise en place du service

Avant de démarrer la solution, on prépare son fichier de service afin qu'il soit géré par systemd :

sudo vi /etc/systemd/system/xo-server.service

Voici le contenu du service :

[Unit]
Description=Xen Orchestra Server
After=network-online.target valkey.service
Wants=valkey.service

[Service]
Type=simple
User=xo
Group=xo
WorkingDirectory=/opt/xo/packages/xo-server
ExecStart=/usr/bin/node dist/cli.mjs --config /etc/xo-server/config.yaml
Restart=always
RestartSec=5
Environment="NODE_ENV=production"
SyslogIdentifier=xo-server
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

On y retrouve notre utilisateur xo et on précise le fichier de configuration utilisé (facultatif, mais préférable).

Puis on rafraîchit systemd pour ensuite activer le service et le lancer :

sudo systemctl daemon-reload
sudo systemctl enable --now xo-server
sudo systemctl status xo-server

On n'oublie pas les ouvertures de flux firewall pour l'accès à l'interface depuis l'exterieur:

sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --permanent --add-port=8443/tcp
sudo firewall-cmd --reload

Si tout va bien, on peut se connecter à l'url de Xen Orchestra, soit https://prdxcpxor501.coolcorp.priv:8443/ pour moi.

Par défaut, l'utilisateur admin est [email protected] et son mot de passe est admin.

Création du pool

On arrive sur l'interface de Xen Orchestra 6, une GUI nouvellement en place à l'écriture de ce tutoriel, mais qui n'a pas encore complètement pris le relais de la version 5.0.

En l'état, la plateforme offre une bonne visibilité avec une ergonomie moderne, mais on est limité dans les actions possibles.

Il faut malheureusement revenir à la version 5.0 pour la suite. Pour ça, on clique sur le raccourci en haut à droite.

Changement du mot de passe par défaut de l'admin

De là, notre premier réflexe va être de changer le mot de passe par défaut pour notre utilisateur admin.

Pour cela, dans Settings on se rend dans la section Users et on édite le password du compte.

Inscription des serveurs

On enchaîne avec l'inscription des serveurs dans Xen Orchestra.

Comme aucun hôte n'est encore enregistré, on peut suivre l'invitation Add Server, sinon on passe dans la section New puis Server.

De là on renseigne nos trois serveurs en passant par leur adresse IP. On utilise le login et le mot de passe déclaré lors de l'installation de XCP-ng (voir article précédent).

On n'oublie pas de décocher l'option Vérification du certificat.

Cette étape remplie, chaque serveur est désormais présent dans un pool qui porte son nom.

Bascule des serveurs dans un même pool

L'objectif va être de renommer le pool du premier serveur.

Pour cela, rien de plus simple : on clique sur le pool en question et on le renomme en xcp-pool.

Puis on va configurer les deux autres serveurs pour qu'ils quittent leur pool actuel afin de rejoindre celui du premier serveur. Pour cela également, pas de difficulté : on utilise la GUI pour changer l'appartenance au pool.

On se rend sur le pool xcp-pool, puis via l'option add hosts, on ajoute les autres serveurs.

À la fin, nos trois serveurs sont dans le pool xcp-ng et on peut noter que prdxcpsrv001 est vu comme le master.

On peut retourner sur la vue Xen Orchestra 6 via l'option Try XO 6. On a une vue plus agréable de l'ensemble. Veuillez noter que la capture suivante a été prise après l'ajout de VMs supplémentaires, et surtout que le master a basculé sur prdxcpsrv002 suite à un test de HA.

Conclusion

Xen Orchestra est maintenant déployé avec un pool opérationnel constitué de nos serveurs XCP-ng.

Il est dommage que la version 6 ne soit pas encore complète, nous obligeant à utiliser la version 5.0 pour certaines tâches. Mais les choix ergonomique et de design vont dans le bon sens à mon goût.

Il va maintenant falloir se lancer dans la configuration avancée avec la définition des réseaux et du stockage.

Mais cela donnera lieu à de futurs articles à venir.