XCP-ng : Intégration dans Xen Orchestra et benchmarks

Introduction

Cet article fait directement suite à celui-ci traitant de l’installation de l’hyperviseur XCP-ng et de Xen Orchestra (XO).

Pour rappel Xen Orchestra (XO) est la plateforme de gestion Web capable de contrôler des environnements de virtualisation basés sur XCP-ng (et Xen).

Disponible sous forme d’appliance, elle est dans ce cas, soumise à un licencing si l’on souhaite tirer parti de toutes les fonctionnalités.

Son déploiement à partir du code source autorise quant à lui l’usage de l’ensemble des fonctions de l’outil à savoir:

• Gestion des machines virtuelles
• Sauvegarde et restauration
• Surveillance temps réels
• Gestion des snapshots
• Réseau et stockage
• Multi-tenancy et sécurité
• Automatisation

Il est maintenant temps de profiter de tout ça en enregistrant mes deux serveurs XCP-ng sur mon instance XO.

Configuration

On se connecte à XO depuis son navigateur web. Le compte est admin@admin.net associé au mot de passe admin.

Gestion des comptes

Pour des raisons évidentes de sécurité, la première chose que nous allons changer est cet identifiant par défaut.

Il suffit d’aller dans la section Settings, puis d’aller dans Users pour modifier à la fois le login et le password du compte admin.

C’est là qu’apparait toute de suite une des logiques retenues dans l’interface de XO : le Click to edit. Beaucoup des champs sont modifiables en cliquant directement dessus, même si graphiquement ce n’est pas la première chose qui saute aux yeux. Ne cherchez donc pas un bouton edit ou une petite icône pouvant représenter une modification.

De même une fois édité, le paramètre est fait…pas de bouton Apply ou autres. On n’aime ou pas...

Une fois cette étape passée, on peut se concentrer sur l’enregistrement des serveurs.

Création du pool

Si vous n’avez jamais déclaré d’hyperviseur jusque-là, vous serez directement invité à le faire dès la page d’accueil.

Sinon cela se passe dans la section New puis Server.

Il est nécessaire de renseigner vos serveurs par leur adresse IP au niveau du champ host et pas par leur nom DNS.

Préférez le champ Label pour donner le nom de la machine. Renseignez le password associé au compte root que vous avez choisi lors de la l’installation de XCP-ng.

Pensez également à activer l’option Unauthorized Certificates (sauf si bien sûr vous avez généré vos certificats en amont).

Une fois vos serveurs enregistrés, vous observerez qu’ils sont chacun rattachés à un pool différent, portant le même nom que le serveur lui-même.

Or, me concernant je souhaite associer mes deux serveurs au sein du même pool. En effet, un pool permet principalement de:

• Centraliser la gestion des ressources.
• Assurer un HA
• Partager la configuration réseau
• Déplacer les VMs d’un serveur à autre

On n’est en face d’un fonctionnement à la cluster VMware.

La première chose à faire et de renommer le premier pool correspondant au premier serveur pour lui donner un nom plus parlant.

On peut le faire via la GUI mais j'ai préféré le faire par l’API XAPI et la commande xe (histoire de s'habituer a la CLI) directement en se connectant en SSH sur le premier serveur (prdxcptyn001).

À l’aide de la commande xe pool-list, on liste les pools.

On récupère l’ID et on renomme ce dernier via la commande xe pool-param-set uuid=uuid_du_pool name-label="nouveau_nom".

Lorsqu’on retourne sur la GUI de XO, le serveur est désormais associé à un pool portant le nouveau nom.

Il ne reste plus qu’a se déplacer dans la configuration du pool, puis de cliquer sur Add host pour sélectionner le second serveur.

Celui-ci sera déplacé de son pool par défaut pour rejoindre le pool du premier serveur.

On remarque qu’il y a une notion de Master. Celui-ci a pour mission de:

• Coordonner le pool
• Gérer les ressources

Sa perte peut devenir problématique, mais normalement, si le master d’un pool venait à être indisponible, un autre serveur survivant peut être promu.

J’avoue être un peu limite sur ce sujet, car je débute sur XCP-ng et je manque d’expérience sur ce point. J’espère en apprendre plus avec le temps.

Quoiqu’il en soit, on termine avec un pool au complet.

On peut maintenant s’attacher au réseau.

Configuration réseau

Mon but est de reproduire exactement la même configuration que pour mon lab VMware en exploitant trois VLANs. Deux ont besoin d’être tagués, car sur une même interface.

• DMZ_FIRST : Non tagué
• VLAN_WEB : VLAN 6
• LAN : VLAN 1

A noter que comme pour mon lab VMware, je dédie une carte à l'administration.

Il suffit pour cela de se rendre dans la section New puis Network.

On sélectionne ensuite le pool dans lequel la configuration réseau va être associée. C’est très pratique, car cela centralise le paramétrage et chaque serveur du pool va pouvoir être configuré à l’identique. Il est bien sûr nécessaire pour cela que chaque serveur soit câblé à correctement et que la configuration réseau en amont soit la même.

Dans mon cas, étant donné qu’il s’agissait avant de deux ESXi, ils sont déjà à la cible.

Je n’ai qu’a eu suivre les indications de la GUI pour déclarer l’ensemble de mes réseaux.

Je peux mettre à jour leur description si nécessaire.

Me voilà prêt à migrer mes premières VMs de mon lab VMware vers ce lab XCP-ng.

Migration de VMs de ESXi à XCP-ng

J’ai choisi d’y copier mes deux machines virtuelles me servant de template:

• prdtpllin501 : VM sous Ubuntu 24.04. L’objectif est d’avoir son pendant prdtpllin502 sous XCP-ng
• prdtplk8s501 : VM sous PhotonOS 5.0 L’objectif est d’avoir son pendant prdtplk8s502 sous XCP-ng

Rien de compliqué, puisque l’import est directement possible depuis le menu Import.

Il suffit d’indiquer l’URL de son vCenter, un login disposant des accès nécessaires et on peut ensuite browser les VMs pour choisir celle à migrer sur le pool XO.

Pour l’instant je n’ai pas de stockage partagé, donc la VM source sera copiée sur le disque propre au serveur XCP-ng que je choisis comme cible.

Il est obligatoire d’indiquer un Original Template. Si vous ne trouvez pas votre bonheur dans la liste vous pouvez choisir l’OS se rapprochant au mieux de votre OS source ou choisir comme ça a été le cas pour moi et ma VM sous PhotonOS l’option Other Install Media.

Une fois lancé, l’import peut être suivi dans la rubrique Tasks.

À noter que pour une synchro complète il faut éteindre la VM source en fin de copie.

Mes VMs étant petites, il n’a fallu que quelques minutes pour pouvoir démarrer ma première VM sur mon lab XCP-ng.

On peut mettre à jour les informations sur la VM en éditant directement le titre et la description

Reconfiguration des VMs

On peut exploiter l’onglet Console pour entrer dans la VM et commencer à modifier la configuration de l’OS.

Dans mon cas, il me fallait changer l’IP et le hostname pour ne pas être en conflit avec les VM d’origine que je souhaite garder sur mon lab VMware.

Fonction de l’OS à traiter, il peut y’avoir un changement de nom de l’interface réseau.

Dans le cas de PhotonOS, je n’ai pas eu de soucis, mais dans le cas de Ubuntu, l’interface a basculé de ens33 à enX0.

Il faut donc penser à mettre sa configuration à jour.

Installation des outils guest

Il reste une dernière étape pour terminer la migration. Il faut installer, a l’image des vmware tools, les outils xe-guest.

Ceci peuvent être disponible directement dans les repos de votre OS, comme c’est le cas pour ma VM Ubuntu et dans ce cas il suffit d’exploiter le gestionnaire de package de la distribution:

sudo apt install xe-guest-utilities

Sinon, il faut récupérer les sources ou un paquet disponible directement sur le repos git suivant.

C’est ce que j’ai dû faire pour PhotonOS. Heureusement, celui-ci peut exploiter le package RPM et il suffit d’installer les prérequis suivants:

tdnf install gcc make libtool autoconf automake wget (a adapter fonction de votre distribution)

De récupérer ensuite le RPM.

wget https://github.com/xenserver/xe-guest-utilities/releases/download/v8.4.0/xe-guest-utilities-8.4.0-1.x86_64.rpm (la version est susceptible d'évoluer avec le temps).

Puis de lancer son installation.

rpm -ivh xe-guest-utilities-8.4.0-1.x86_64.rpm

(Vous pouvez ignorer le message d’erreur en fin d’installation).

Une fois le paquet déployé, il m’a fallu activer le service associé.

systemctl enable xe-linux-distribution
systemctl start xe-linux-distribution

Une fois le service démarré, on peut observer que des informations complémentaires sont affichées dans la GUI de XO.

À noter que pour les OS Windows, une ISO est disponible directement auprès de XCP-ng à l'URL suivante.

Un petit mot sur l'API

Avant d’enchainer sur les performances, sachez qu’il est possible de manipuler les VMs directement via l’API XAPI (Xen Project Management API) et la commande xe comme j’ai pu le faire dans l’étape de renommage du pool.

Il suffit de se connecter en ssh sur l’un ou l’autre des serveurs et vous disposez de tout un ensemble de commande pour piloter les VMs.

Par exemple lister les VMs avec xe vm-list ou démarrer une vm avec xe vm-start.

À retenir dans le cas où XO venait à ne plus fonctionner ou pour faire du debug.

Suivi des performances

Maintenant que le pool est prêt, que des VMs sont en exécution, il est possible de suivre la consommation de son infra directement dans XO.

Plusieurs fenêtres sont disponibles pour obtenir des statistiques d’usage.

La plupart des objets (VMs, Pool...) proposent des métriques qu’il est possible de parcourir au sein de XO.

Benchmark: VMware ESXi vs XCP-ng

Il est temps maintenant de comparer un peu VMware à XCP-ng au niveau des performances.

Protocole de test

Dans mon cas, j’ai deux serveurs ESXi et deux serveurs XCP-ng qui tournent exactement sur les mêmes types de machines. En l’occurrence des mini stations de travail Lenovo datant de 2018 comme j’ai pu les décrire ici.

Ces machines exploitent un processeur i5-8500T CPU @ 2.10GHz, 16 Go de mémoire avec un SSD NVME M2 Crucial P5 Plus.

Les nœuds ESXi et XCP-Ng sont donc identiques en termes de hardware. C’est la même version de BIOS sur toutes les machines.

J’ai déployé une VM Ubuntu 24.04 (prdlinben501) sur un serveur ESXi et une VM Ubuntu 24.04 (prdlinben502) sur un serveur XCP-ng (avec Opentofu/Terraform, mais ça je le garde pour plus tard 😊).

Les deux OS sont exactement sur le même niveau de patch et d'outils preinstallés.

Les VMs ont les mêmes paramètres:

• 4 vCPU
• 4 Go de mémoire
• Disque de 120 Go

Chaque VM est toute seule sur son hyperviseur.

Côté VMware on n’est sur une version ESXi 8.0.2 et côté XCP-ng on n’est sur la version 8.2.1.

Aucune customisation n’a été réalisée d’un côté ou de l’autre, et on n’est sur une configuration par défaut des VMs.

Je me suis basé sur Phoronix Test Suite en sélectionnant quelques benchmarks applicatifs pour comparer les résultats entre chaque VMs.

Avant d’entamer les présentations, il est important de préciser que la science des benchmarks est complexe et sujet à polémique. Beaucoup de paramètres peuvent entrer en jeu lorsqu’on décide de comparer des architectures, y compris des paramètres qu’on ne maitrise pas.

Une dissipation de chaleur un peu moins bonne (poussière, pâte ou pad thermique asséché ou mal positionné) limitant la monté en fréquence du CPU, optimisation du code qui privilégie un système au détriment d’un autre, différence de révision hardware….

Bref les résultats qui vont suivre doivent être considérés comme de l’information complémentaire visant à fournir une tendance entre des applicatifs identiques s’exécutant d’un côté sous vmware de l’autre sous XCP-ng.

Encodage MP3

C’est un test qui fait intervenir principalement le CPU. Le but est d’encoder un fichier au format WAV vers le format MP3. Moins le traitement dure, mieux c’est.

Dans cet exercice, c’est très difficile de se positionner tant les résultats sont proches, avec une très très légère avance de XCP-ng, mais qui n'est pas significative à ce niveau

Compression GZIP

Là encore c’est le CPU et également la mémoire qui est mis en avant. Le test consiste à compresser des données avec GZIP.Le temps le plus bas l’emporte.

Ici aussi l’écart est très faible, mais cette fois-ci c’est vmware qui est légèrement devant, mais ce n’est pas significatif non plus.

Compression Decompression 7ZIP

Toujours un exercice de compression, mais cette fois-ci le résultat est donné en MIPS (million d’instructions par seconde). On évalue également la décompression.

On note une très légère avance de XCP-ng.

Apache (httpd)

On rentre dans un test plus complexe, ou plusieurs itérations vont être réalisées. Le but est de simuler des connexions simultanées sur un serveur Apache. Plus on peut traiter de requêtes par seconde mieux c’est.

Dans ce benchmark, VMware prend de l’avance. L’OS exécuté sur ESXi est environ 17% plus rapide que l’OS sur XCP-ng.

MariaDB

On utilise le fameux moteur SQL pour calculer le nombre de requêtes par seconde réalisables sur une base de tests.

VMware fait mieux de deux requêtes, mais ce n’est pas marquant.

Compilation Kernel Linux

On en revient à des tests plus orientés puissance brut, avec le temps de compilation d’un kernel linux.

C’est XCP-ng qui passe devant en mettant quelque seconde de moins que VMware pour cet exercice

NGINX

Comme pour le test apache, on évalue le nombre de requêtes pas seconde pour se connecter à un site fictif.

Même si l’écart est moins conséquent que pour apache, on n’a un différence de performance de 5,5% en faveur de VMware.

Analyse et observations

Si je me base sur ces tests, j’en conclus que l’écart de performance entre une VM sous VMware et une VM sous XCP-ng est le plus souvent négligeable.

L’exception vient de la mise en œuvre d’un moteur web ou VMware se démarque clairement. Difficile de comprendre pourquoi, peut être un lien avec le driver des cartes réseau (Intel I350) ou une différence d’usage de la stack réseau entre les deux systèmes. Mais dans une situation de production, c’est clairement un sujet à creuser et à considérer sérieusement.

A noter que d'autres benchmarks pourraient arriver par la suite. Il faudrait tester davantage de situations, notamment avec un OS Microsoft pour etre plus complet dans les conclusions.

Sans compter les cas de contension. Il est important de pouvoir savoir comment un Hyperviseur gère la montée en charge jusqu'a arriver à saturation des ressources du serveurs physiques.

C'est par contre très chronophage, mais si je peux je mettrais à jour l'article avec de nouvelles comparaisons.

Conclusion

Le duo XCP-ng et Xen Orchestra est clairement intéressant. Cet ensemble totalement open source permet de construire une architecture de virtualisation embarquant bon nombre de fonctionnalités.

Il n'est pas possible dans cet article de tout vous présenter (j’en garde sous le coude), mais entre les backups intégrés, les plug-ins d’authentification , la database d’ISO et d’autres options, on se retrouve avec un packaging complet et pouvant prétendre à de nombreux usages.

Je serais maintenant honnête, on n’est pas, d’après moi, au niveau d’un VMware. Certaines briques avancées comme NSX-T, VSAN, DRS ou SDRS, pour qui ça parle, gardent une longueur d’avance. Sans compter l'écosystème qui gravite autour de VMware.

Mais sur la couche d’hyperviseur pure et du management centralisé, je considère XCP-ng/XO comme une alternative crédible a ESXi/vCenter (mis à part les différences d'ergonomie qui me semble en faveur d'un vCenter, mais c'est aussi une question d'habitude).

Sans compter qu’au vu de ma faible expérience sur ce duo fançais XO/XCP-ng de l'entreprise Vates, il y'a sans doute beaucoup de choses à découvrir.

Je n’ai pas pu évaluer encore les opérations d’update, mais avec l’arrivée de XCP-ng 8.3 ça ne saurait tarder.

Concernant les performances, c’est difficile de se prononcer. Comme je l’ai déjà dit, beaucoup de paramètres entrent en jeu, mais sur pas mal de tests que j’ai pu réaliser on note un écart non significatif entre VMware et XCP-ng.

Seuls les tests autour d’Apache et NGNIX montrent un avantage net pour VMware, mais qu’il faudrait chercher à expliquer pour savoir s’il n’y a rien à faire du côté configuration de XCP-ng pour améliorer ça.

J’en profite d’ailleurs pour évoquer la problématique que peut représenter une bascule d’Hyperviseur. Sur le papier de nombreuses solutions concurrentes à VMware existent, et oui on peut tout à fait s’engager dans une démarche visant à abandonner les solutions de l’éditeur phare de la virtualisation.

Mais attention, c’est un projet qu’il ne faut pas minimiser et ramener à de simples déplacements de VMs. Je vois trop d’article ou de marketing mettant en avant qu’il suffit de quelques clics pour passer d’un écosystème à un autre. C’est simplement faux.

Il faut prendre le temps de choisir sa cible, de la configurer correctement et surtout d’évaluer ses performances et sa redondance. Déplacer une VM de gauche à droite ne suffit pas pour un environnement de production. Il faut maximiser les phases de recettes, et intégrer tout ce qui peut graviter autour des hyperviseurs : supervision/sauvegarde/CICD.

Si des solutions comme Phoronix Test Suite facilitent les comparaisons, rien ne vaut des cas concrets représentés par des applicatifs réellement utilisés dans l'entreprise intéressée par la migration.

Le cas de la gestion des compétences est bien entendu primordial. Une équipe expérimentée autour d'un produit spécifique, ça représente une très forte valeur ajoutée pour une société. Reformer ses équipes présente un coup qui parfois peut s'avérer plus important qu'une augmentation de licence...sans compter la perte de la maitrise opérationnelle avec laquelle il faudra compter pendant un temps.

J’ai pu m’essayer au provider terraform XO pour y déployer une VM. J’ai pu arriver à un résultat, mais même si Terraform et l’adoption du IAC m’a grandement simplifié les choses pour basculer d’un déploiement sous VMware vers XCP-ng, j’ai quand même du prendre du temps pour comprendre le fonctionnement du provider XO et réadapter mes scripts.

Ce qui évident pour moi c’est que je n’ai pas prévu d’abandonner VMware et j’ai clairement prévu de poursuivre sous XCP-ng, car a mon humble avis fonction de uses cases et des entreprises, il y’a un intérêt à savoir exploiter les deux, ou du moins à avoir une alternative VMware dans son portefeuille de compétences.

Je réitère ce que j’ai pu dire dans le précédent article sur le sujet, je ne comprends pas pourquoi l’écosystème de l’entreprise française Vates n’est pas plus mis en avant sur notre territoire.

Sur le forum communautaire de XCP-ng, on note une belle activité dans les rubriques anglophones, mais rien dans la section française….

Face à un Proxmox VE la combinaison XCP-ng/XO me semble plus séduisante et mieux intégrée…peut être que le choix de Xen en lieu et place de KVM ne joue pas en la faveur du frenchie.

En tout cas je vais continuer l’aventure XCP-ng/XO de mon côté et ne manquerait pas de partager mes découvertes au fil du temps.