XCP-ng : Installation des serveurs et de Xen Orchestra

Introduction

J’ai décidé de faire évoluer mon homelab pour y intégrer une autre technologie de virtualisation.

En effet, pour ceux qui ne le sauraient pas, le rachat de VMware par Broadcom a provoqué un séisme dans l’IT.

N’hésitez pas à lire mon article sur le sujet, pour en apprendre davantage.

Je ne suis pas convaincu de la fin de VMware en entreprise et pour moi l’hyperviseur stars de ces 20 dernières années, ESXi et tout l’écosystème vSphere qui s’y rattache, va encore faire partie du paysage IT pendant quelques temps encore.

De grand acteurs ne se laissent pas faire, et il n’est pas impossible que Broadcom soit obligé de revenir sur certaines de ses décisions.

Néanmoins on ne peut pas nier que la confiance est brisée et que certains vont commencer à étudier sérieusement d’autres solutions.

Personnellement, je prends ce changement comme une opportunité de regarder ce qui se fait ailleurs et d’ajouter de nouvelles compétences à mon profil. Sans compter que Broadcom a mis fin à la version gratuite de ESXi.

J’ai donc choisi de retirer deux de mes serveurs ESXi pour les basculer sous XCP-ng.

XCP-ng fait partie de ces solutions de virtualisation présentes sur le marché depuis longtemps, mais qui a bénéficié ces derniers temps d'une mise en avant en raison de la crise VMware.

Malgré cela, il a moins connu la lumière que Proxmox VE, déjà bien exploité des amateurs de homelab.

J’ai déjà eu l’occasion de tester ce dernier, c’est un excellent produit, mais qui me perturbe un peu dans son approche. Pas de console unifiée à la vCenter, une GUI quelque peu veillotte, pas mal de customisation à réaliser dans certains cas...

.

Bref sans remettre en cause la qualité de Proxmox VE, et bien que ce dernier soit l'alternative à VMware la plus médiatisée, j’ai souhaité m’intéresser à une autre solution open source du marché: XCP-ng.

Informations sur XCP-ng

Historique

Contrairement à beaucoup d’autres produits de virtualisation, XCP-ng ne repose pas sur KVM (Kernel-based Virtual Machine) (comme Proxmox VE), mais sur Xen. C’est un hyperviseur de type 1 développé à partir de 2003 comme projet de recherche à l’université de Cambridge.

Très innovant pour l’époque et jugé très performant de par son principe de paravirtualisation, il nécessitait néanmoins l’usage d’OS invités modifiés conscients d’être virtualisés.

L’arrivée des instructions de virtualisions dans les CPUs (Intel VT-x et AMD-V) a permis de lever ces limitations et Xen à évoluer pour permettre aujourd’hui de supporter beaucoup d’OS invité de type x86.

Au vu du succès de la solution, rapidement les initiateurs du projet à Cambridge ont fondé la société XenSource, en charge de la promotion et du développement commercial de Xen.

Puis en octobre 2007, le géant Citrix rachète XenSource. Très vite l’entreprise américaine va proposer XenServer, une solution complète basée sur Xen.

Le projet Xen va être placé en 2013 sous la responsabilité de la Linux Foundation sous une nouvelle marque Xen Project pour le différentier de l’implémentation commerciale de Citrix.

Il est important de distinguer l’hyperviseur Xen, open source et sous gestion de la Linux Foundation de l’implémentation commercial faite par Citrix.

En 2018 justement, cette implémentation commerciale XenServer va devenir Citrix Hypervisor et mettre fin à la version gratuite du produit Citrix qui était jusqu’à présent disponible avec quelques limitations.

Hors des 2010, cette version gratuite était concurrencée par un fork open source de XenServer sous le nom de XCP (Xen Cloud Platform).

C’est ce fork qui en 2018 va servir de base pour XCP-ng afin de proposer une alternative à la fin de la version gratuite de XenServer (devenu Citrix Hypervisor).

Depuis, Xen continue d’être porté par la Linux Foundation et soutenu par de grands acteurs comme AMD ou AWS . L’hyperviseur de niveau 1 qui en découle est implémenté sous un produit payant par Citrix et dans une version open source par la société Vates via XCP-ng.

Vates et l'écosystème XCP-ng

Vates est une société française fondée en 2012 à Grenoble. Aujourd’hui l’entreprise compte plus d’une quarantaine de personnes.

Vates est à l'initiative du projet communautaire XCP-ng et participe activement à son developpement. Elle propose également un support payant pour les entreprises.

Elle développe aussi Xen Orchestra (xo), la solution de gestion associée à XCP-ng (et compatible Xen) qui peut être installée directement à partir des sources du produit ou via l’appliance proposée par Vates.

Vates dispose d’un parc client conséquent…Surtout sur le marché US.

J’en profite pour faire un aparté. C’est quand même dingue de se dire qu’une entreprise française existe depuis plus de 10 ans et propose une solution de virtualisation conçue autour d’une base solide mais qu’elle ne soit pas davantage déployée en Europe, a minima en France.

Moi le premier, je m’en veux de ne pas m’être intéressé plus tôt à l’offre de la société tricolore. Il est dommage d’attendre de se retrouver au pied du mur pour commencer à regarder ce qui existe au plus proche de chez soi.

On sait que les guerres géopolitiques se font désormais sur le numérique, et qu’il devient important d’avoir à disposition des leaders technologiques pour s’affirmer dans le monde.

J’espère vraiment que la dépendance IT du marché européen aux solutions américaine, particulièrement mise en avant avec la crise VMware permettront à des entreprises comme Vates, de grossir et d’avoir davantage de moyens pour proposer une concurrence à jeux égale avec des géants de la tech US.

Objectif du lab

Revenons aux fondamentaux.

Le but de ce lab et de basculer deux ESXi sous XCP-ng afin d’obtenir un pool de serveurs, l’équivalent d’un cluster chez VMware.

Ce pool va devoir être géré par Xen Orchestra, car de base, un serveur XCP-ng ne peut être piloté qu’en CLI via l’API XAPI (Xen Project Management API). A noter que Vates travaille sur Xen Orchestra Lite une version allégée de Xen Orchestra intégré pour simplifier la gestion d’un serveur XCP-ng sans avoir à déployer d’autres solutions. Une belle manière de proposer une alternative a la défunte version gratuite de ESXi.

Concernant Xen Orchestra, je ne vais pas utiliser l’appliance. J’ai pu la tester, elle est très facile à déployer via le site https://vates.tech/deploy.

Mais l’inconvénient est que l’appliance impose d’acheter une licence pour débloquer toutes les fonctionnalités, à commencer par le backup.

N'hésitez pas à consulter ce lien pour connaitre les différentes formules proposées par Vates et les différences en rapport à la licence retenue.

Souhaitant accéder à l’ensemble des options, je suis finalement parti sur une installation à partir du code source.

Dans ce cas, c’est à vous de déployer l’OS sous-jacent et ensuite d’y installer Xen Orchestra. Il ne vous sera alors pas possible d’avoir un support, mais vous accéderez à toutes les fonctions.

Installation de XCP-ng

L’installation de XCP-ng ne présente aucune difficulté. L’ISO est téléchargeable sur le site, et il suffit de la copier sur une clef USB à l’aide d’un outil comme Rufus.

On boot ensuite sur la clef pour suivre l’assistant d’installation. Attention sur ce point, il se peut que vous ailliez à modifier vos paramètres de boots de votre serveur, notamment désactiver le secure boot. Attention également à la configuration du mode sata, évitez le mode raid au profit de AHCI.

Ces parametres peuvent varier fonction de votre configuration hardware et de son support ou non par XCP-ng. Merci à scls19fr du forum XCP-ng pour m'avoir signalé ce point

On nous demandera une adresse IP, un mot de passe pour le compte root, ainsi que le support ou installer la solution.

A ce titre, et comme c’est indiqué dans la documentation officielle, il ne faut pas utiliser de clef USB comme cible. C’est la solution que j’avais choisie au départ, comme j’avais l’habitude de le faire avec ESXi.

Si j’ai pu aller au bout de l’opération, l’installation a duré plus de 2H…et par la suite la moindre opération d’update sur le serveur était d’une extrême lenteur.

XCP-ng permet néanmoins d’être installé sur le même disque que sur celui qui sera destiné à héberger des VMs, en n’occupant que très peu de place. Vous avez le choix entre un formatage en LVM (Logical Volume Manager ), plus performant, mais imposant la réservation complète de la volumétrie.

Si vous souhaitez maximiser l’espace disque en partant sur une stratégie Thin (Allocation granulaire de capacité) il vous faudra choisir un formatage classique, jugé moins performant.

Personnellement, je suis resté en LVM.

Après quelques minutes, le serveur est prêt. Une page web est accessible vous proposant des liens vers les différents moyens de gérer désormais le serveur, Xen Orchestra ou la CLI.

Il faut savoir que Xen déploie l’équivalent d’un service console chez VMware, mais appelé ici dom0 (Xen utilise la notion de domain). Cet espace privilégié contient un dérivé de CentOS intégrant la Xen Management Toolstack.

Chaque serveur XCP-ng a donc son dom0. Vous pouvez vous y connecter en SSH et vous serez à même de mettre à jour cette partie avec des commandes de type yum update.

Installation de Xen Orchestra

Déploiement de la VM

Comme je l’ai indiqué plus haut, j’ai retenu une installation de Xen Orchestra à partir du code source.

J’ai donc d’abord déployé une VM Ubuntu Server en version 24.04 sur mon cluster VMware. En effet, j’ai trouvé intéressant de déporter Xen Orchestra à l’extérieur des serveurs XCP-ng. De base quand vous déployez l’appliance, elle s’exécute sur le serveur XCP-ng désigné comme cible, mais dans mon cas, je suis libre de faire tourner la VM ou je veux.

Si jamais un souci venait à se produire sur les serveurs XCP-ng, je pourrais toujours garder la main sur Xen Orchestraa.

A noter également que l’indisponibilité de Xen Orchestra n’entraine pas une indisponibilité du pool de serveur ni des VMs qui s’y exécutent.

Pourquoi pas à terme, faire tourner un vCenter sur XCP-ng et avoir ainsi un croisement des solutions de gestions.

Comme j’ai pu l’expliquer ici, je déploie mes VMs avec OpenTofu (terraform). Je me suis donc inspiré de mes travaux précédents pour décrire mon serveur Xen Orchestra que j’ai décidé de nommer prdxcpxoc501.

Je ne vais pas détailler ici la procédure de déploiement, mais le code source IAC (Infrastructure As Code) est disponible dans mon github pour ceux qui le souhaitent.

N’hésitez pas à lire cet article pour plus de détails sur OpenTofu/Terrafom.

Au bout de quelques minutes, ma VM Ubuntu est prête. Je n’ai plus qu’à m’y connecter avec mon compte classique et commencer l’installation de Xen Orchestra.

Installation et prérequis

On s’assure d’abord d’être bien à jour côté OS avec les commandes:

sudo apt update
sudo apt upgrade

Puis on installe les dépendances.

Xen Orchestra tourne sous NodeJS, il faut donc installer l’environnement avec la commande:

sudo apt install nodejs

On s’assure que NodeJS est opérationnel avec la commande:

node -v

Puis on va installer tout le nécessaire à la compilation, en y incluant la base clef/valeur Redis, nécessaire également à la solution.

Il suffit de passer la commande.

sudo apt install build-essential redis-server libpng-dev git python3-minimal libvhdi-utils lvm2 cifs-utils nfs-common ntfs-3g

On démarre redis avec les commandes:

systemctl restart redis.service
systemctl status redis.service

Puis on s’assure que redis répond correctement avec la commande:

redis-cli ping

Il faut maintenant installer le gestionnaire de package JavaScript Yarn, mais en commençant d’abord par son alterego npm avec la commande:

sudo apt install npm

Puis via npm on peut récupérer yarn.

sudo npm install -g yarn

On vérifie la version de yarn.

yarn --version

On dispose désormais de tous les prérequis logiciels à Xen Orchestra.

On va s’attarder maintenant sur le prérequis de contexte en commençant par déclarer un utilisateur dédié à l’exécution de Xen Orchestra, nommé xouser.

Cela évitera de faire tourner l’application en root.

Pour cela on utilise les enchainements de commandes suivantes:

sudo useradd xouser
mkdir -p /home/xouser
chown -R xouser:xouser /home/xouser

Étant donné que l’utilisateur ne dispose pas des droits root, il ne pourra pas utiliser les ports 80 et 443 qui sont des ports réservés sur les OS linux récents.

Plusieurs solutions sont possibles pour lever ces restrictions, mais celle qui me parait la plus simple est d’utiliser des règles de natages via iptables.

Ainsi, l’application utilisera le port 8080 à la place du 80, le 8443 à la place du 443, mais la redirection de ces ports se fera automatiquement grâce aux règles iptable suivantes:

sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8443

L’utilisateur xouser devra également être amené à monter des répertoires, il faut donc lui autoriser la commande mount et d’autres binaires.

Pour cela on va lui créer un fichier sudoer xouser dans /etc/sudoers.d/ (sudo vim /etc/sudoers.d/xouser).

Le contenu du fichier xouser est le suivant:

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

Il faut également créer un dossier /run/xo-server puis donner les droits à l’utilisateur xouser.

sudo mkdir /run/xo-server
sudo chown -R xouser:xouser /run/xo-server

De la même manière, j’ai choisi arbitrairement de stocker les données dans /opt/xo-server.

On crée donc le dossier et on donne les bons droits.

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

Compilation et déploiement

On peut enfin passer à la compilation de Xen Orchestra.

Pour ça on se connecte dans le contexte de l’utilisateur xouser avec la commande:

sudo su - xouser

On s’assure d’être dans le home

pwd

On clone les sources du projet.

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

On rentre dans le dossier récupéré.

cd xen-orchestra

On passe à la compilation avec les commandes:

yarn
yarn install

On rentre dans l’arborescence produite.

cd packages/xo-server

On crée l’emplacement de la configuration.

mkdir -p ~/.config/xo-server

Puis on n’y copie une version modèle de la configuration par défaut.

cp sample.config.toml ~/.config/xo-server/config.toml

Qu’on va pouvoir s’empresser d’éditer.

vim ~/.config/xo-server/config.toml

On va remplacer l’emplacement des datas par défaut:

datadir = '/opt/xo-server/data'

On active la redirection https.

redirectToHttps = true'

On indique l’URL à laquelle sera publié Xen Orchestra.

'publicUrl = 'https://prdxcpxoc501.coolcorp.priv''

puis on va activer l’écoute sur les ports 8080 et 8443.

 
# Basic HTTP.
[[http.listen]]
# Address on which the server is listening on.
#
# Sets it to 'localhost' for IP to listen only on the local host.
#
# Default: all IPv6 addresses if available, otherwise all IPv4 addresses.
# hostname = 'localhost'

# Port on which the server is listening on.
#
# Default: undefined
port = 8080

# Instead of `host` and `port` a path to a UNIX socket may be specified
# (overrides `host` and `port`).
#
# Default: undefined
# socket = './http.sock'

# # Basic HTTPS.
# #
# # You can find the list of possible options there
# # https://nodejs.org/docs/latest/api/tls.html#tls.createServer
# #
# # The only difference is the presence of the certificate and the key.
[[http.listen]]
# #hostname = '127.0.0.1'
port = 8443

On décommente la référence au certificat et à la clef privée utilisée pour https.

On va décider arbitrairement de les héberger dans /opt/xo-server/.

cert = '/opt/xo-server/certificate.pem'
key = '/opt/xo-server/key.pem'

Enfin on autorise le sudo.

useSudo = true

Toute la configuration est prête.

Mais avant de démarrer le produit, il faut s’occuper du certificat.

On n’a vu dans la conf qu’on n’exploitait /opt/xo-server/key.pem en tant que clef privée et le certificat associé doit être dans /opt/xo-server/certificate.pem.

La première chose est de se rendre dans /opt/xo-server/ puis d’y générer la clef avec le csr associé.

Je ne vais pas rentrer dans le détail du fonctionnement des certificats, je vais simplement reprendre ce que j’ai déjà pu expliquer dans cet article (la partie sur le certificat associé au dashboard Traefik).

Je prépare un fichier de conf openssl-san.cnf pour openssl chargé de renseigner les noms DNS auquel devra être associé le certificat. En l’occurrence prdxcpxoc501.coolcorp.priv.

    
      [req]
      distinguished_name = req_distinguished_name
      req_extensions = req_ext
      [req_distinguished_name]
      [req_ext]
      subjectAltName = DNS:prdxcpxoc501.coolcorp.priv

Puis je génère la clef privée et le csr avec la commande:

   
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=prdxcpxoc501.coolcorp.priv" \
-reqexts req_ext \
-config openssl-san.cnf

Je récupère le contenu du CSR pour le soumettre à ma PKI (de mon côté j’utilise une PKI Windows).

En me basant sur un template de certificat proposé par ma PKI, j’obtiens mon certificat.

Je recopie le contenu de ce certificat dans le fichier certificate.pem dans /opt/xo-server/.

Je dispose maintenant de la combinaison clef/certificat pour assurer le HTTPS.

On voit le bout du tunnel.

Je peux maintenant repasser avec mon utilisateur standard et créer le fichier de service xo-server.service associé à Xen Orchestra.

Celui sera créé dans /etc/systemd/system/.

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

Voici son contenu:

[Unit]
Description=XO Server
After=network-online.target

[Service]
User=xouser
Group=xouser
Environment="DEBUG=xo:main"
Restart=always
SyslogIdentifier=xo-server

# Be sure to edit the path below to where your Node and your xo-server install is located!
ExecStart=/usr/bin/node /home/xouser/xen-orchestra/packages/xo-server/dist/cli.mjs

[Install]
WantedBy=multi-user.target

Je peux recharger systemd avec la commande:

sudo systemctl daemon-reload

Puis activer le service xo-server pour enfin le démarrer.

sudo systemctl enable --now xo-server
sudo systemctl start xo-server

Je m’assure que tout va bien avec la commande:

sudo systemctl status xo-server

Il ne me reste plus qu’à faire pointer l’enregistrement dns prdxcpxoc501.coolcorp.priv vers l’IP de ma VM et tester l’accès à Xen Orchestra depuis l’URL https://prdxcpxoc501.coolcorp.priv/.

L’accès est OK, le certificat est bien présent. Je peux m’authentifier avec le compte par défaut admin@admin.net et le mot de passe par default admin: me voilà sur l’interface de Xen Orchestra.

Conclusion

C’est la fin de cet article. Celui-ci m’aura permis de décrire l’écosystème de virtualisation proposé par la société française Vates.

Il est important de préciser que je démarre avec cette solution, il est possible que je me trompe dans la compréhension de certains principes, car je n'ai pas une grande maturité du sujet.

Mais venant de VMware, j’ai plus de simplicité à m’y retrouver dans l’approche retenue de XCP-ng et le fonctionnement de Xen.

Même si KVM a tendance à devenir la solution par défaut pour la virtualisation sous Linux, et que des acteurs comme AWS ont eux-mêmes démarré une transition vers KVM en lieu et place de Xen , ce dernier semble rester très adapté à un usage professionnel.

Le projet continu d'être activement développé, fournissant à la société Vates (entreprise française je le rappel ! Cocorico ) un socle robuste pour poursuivre leur développement de XCP-ng et de sa solution de gestion associée Xen Orchrestra.

Il reste maintenant à poursuivre la mise en place de mon homelab sous cet écosystème. La création du pool de serveur et la suite de la configuration sont décrites dans l'article suivant.