Upgrade d'une plateforme Xen Orchestra/XCP-ng

Introduction

Il y a quelque temps de cela, j’ai mis en ligne deux articles sur l’usage et l’installation de la solution de virtualisation de la société française Vates : à savoir XCP-ng et Xen Orchestra.

Je vous invite à en prendre connaissance, le premier, étant une introduction à l’offre de l’entreprise avec un tutoriel d'installation, le second les instructions de déploiement de VMs accompagnées d'une comparaison de performance entre VMware et XCP-ng. Cela s’inscrit dans mon envie d’avoir une alternative à ESXi pour mon mini lab suite au rachat de VMware par Broadcom.

Après plusieurs semaines d’utilisation sans incident, il est temps de faire une mise à jour de l’ensemble de la stack.

Pour rappel, XCP-ng est un hyperviseur basé sur Xen et embarqué dans un OS sur base redhat.

Xen Orchestra (XO) est un outil d’administration capable de gérer plusieurs serveurs XCP-ng sous la forme de pool.

Xen Orchestra (XO) se déploie:

• Soit sous forme d’appliance, simple et rapide à mettre en œuvre, mais avec des fonctionnalités bridées si vous ne faites pas l’acquisition d’une licence payante.
• soit directement à partir des sources GIT, le produit étant totalement open source. Dans ce cas vous ne pouvez pas avoir de support, mais toutes les fonctionnalités vous sont accessibles.

C’est ce second choix que j’ai fait pour mon usage personnel. J’ai choisi une base Ubuntu pour accueillir Xen Orchestra, le détail de l’installation étant disponible ici.

Mise à jour de Xen Orchestra (XO)

Dans le cadre d’une mise à jour de la stack Vates, Xen Orchestra (XO) est le premier composant à updater. Ce que je vais décrire ne concerne que l’installation à partir des sources (l’appliance embarque la gestion des mises à jour et automatise le processus).

La première opération consiste à mettre à jour l’OS que vous avez retenu pour XO. Dans mon cas Ubuntu: un simple sudo apt update puis sudo apt upgrade suffit.

Cliquez sur l'image pour l'agrandir.

Fonction du type de mise à jour, un reboot peut-être nécessaire. À noter qu’un restart de Xen Orchestra, n’a pas d’impact sur le fonctionnement de vos VMs (un peu comme le vCenter pour ceux à qui ça parle).

Une fois la couche OS à jour, on peut poursuivre avec Xen Orchestra.

On a la possiblité de vérifier la version de départ de XO, via le menu About de l’interface graphique.

Cliquez sur l'image pour l'agrandir.

Pour la suite, il faut basculer en ssh sur le serveur XO et se remettre dans le contexte d’installation de l’outil.

De mon côté, j’avais créé un user spécifique xouser pour faire tourner la solution (voir ici). Je dois donc prendre l’identité de cet utilisateur via la commande sudo su – xouser.

Puis on se positionne à l’emplacement des sources clonées la première fois. En l’occurrence dans mon cas /home/xouser/xen-orchestra (voir ici).

Cliquez sur l'image pour l'agrandir.

Cliquez sur l'image pour l'agrandir.

Comme l’indique le guide officiel, il suffit normalement de faire un git pull --ff-only pour récupérer les dernières versions des sources.

Néanmoins vous pouvez rencontrer, comme moi, un message d’erreur concernant le fichier /xo-server/config.toml qui a été modifié sans être ajouté au repo d’origine. Il y’a donc un conflit entre votre version du fichier de config, et celui qui doit être récupéré dans les nouvelles sources.

Cliquez sur l'image pour l'agrandir.

Pour évitez tout souci, il faut donc mettre votre fichier de config de côté via une opération de stash au niveau de git. La commande git stash dans Git est utilisée pour mettre de côté temporairement les modifications en cours dans votre répertoire de travail, sans avoir à les valider (commit). Cela permet de "stocker" ces modifications pour pouvoir revenir à un état propre de votre code.

C’est exactement ce qu’on va faire ici pour maintenir son fichier de config en état tout en récupérant les nouveaux fichiers de Xen Orchestra.

Pour cela il faut enchainer les commandes suivantes:

git config --global user.email "votre-email@votre-domaine.xxx"
git config --global user.name "Prenom Nom"
git add packages/xo-server/config.toml
git commit -m "Sauvegarde des modifications avant la fusion"
git stash push -m "Sauvegarde temporaire de config.toml"

Cliquez sur l'image pour l'agrandir.

Normalement, une fois ces commandes réalisées, on peut refaire un git pull --ff-only qui cette fois-ci ne pose plus de soucis.

Avec les nouvelles sources récupérées, on peut procéder à la compilation de ces dernieres via la commande:

Yarn

Cliquez sur l'image pour l'agrandir.

Puis la commande:

yarn build

Cliquez sur l'image pour l'agrandir.

Enfin, on restore son fichier de config d’origine via l’instruction git stash pop.

Cliquez sur l'image pour l'agrandir.

Cette commande est utilisée dans Git pour récupérer les modifications précédemment mises en réserve (stashed) et les appliquer à la branche courante tout en supprimant ces modifications de la pile des stashes.

On peut sortir de l’utilisateur dédié à XenOchestra pour faire un redémarrage du service (cela implique d’avoir créer un service pour XO au préalable, plus de détails disponible ici).

sudo systemctl restart xo-server

Cliquez sur l'image pour l'agrandir.

On vérifie le statut via: sudo systemctl status xo-server.

Cliquez sur l'image pour l'agrandir.

Si on retourne dans la section « about » de la GUI, on devrait maintenant avoir une version à jour.

Cliquez sur l'image pour l'agrandir.

Xen Orchestra est « up to date”, il est temps de passer à l’hyperviseur via l’update de XCP-ng.

Mise à jour de XCP-ng

Attention, contrairement aux opérations précédentes, ces mises à jour peuvent avoir un impact sur l’exécution de vos VMs. Il est donc souhaité de mettre en maintenance son node avant de le mettre à jour.

Si vous avez une configuration avec de multiples serveurs, il est possible de déplacer vos VMs pour éviter d’avoir à les arrêter.

Dans mon cas, n’ayant rien de critique, je me contente d’éteindre mes machines virtuelles. J’ai une interruption de services, mais qui ne me pose pas de soucis.

Il existe deux types de mise à jour pour XCP-ng.

• Une mise à jour basique: utile pour patcher et mettre à niveau son serveur dans une version proche de sa version actuelle.
• Une mise à jour majeure: nécessaire pour passer d’une nouvelle version issue d’une nouvelle branche du projet.

Mise à jour mineure XCP-ng

Nous allons démarrer par une mise à jour basique. De toute façon, même si l’objectif est de réaliser une mise à jour majeure, il est toujours conseillé de d’abord faire un upgrade de ses hyperviseurs via le gestionnaire de paquet avant d’envisager de basculer sur une toute nouvelle version.

En l’occurrence, XCP-ng étant basé sur un socle type RedHat, il suffit de se connecter en root sur son serveur, puis de faire un classique yum update.

Cliquez sur l'image pour l'agrandir.

Fonction du nombre de mises à jour en attente et de leur impact, il est possible que vous ayez à redémarrer vos serveurs. Personnellement, c’est une opération que je conseille quoiqu’il arrive pour être sûr de démarrer sur un hyperviseur totalement à jour.

Une fois cet upgrade mineur réalisé, on peut basculer sur un upgrade majeur. Il est possible parfois de pouvoir également employer une mise à jour via le gestionnaire de package, mais ce n’est pas conseillé et souvent non supporté.

Mise à jour majeure XCP-ng

Ce type de mise à jour est plus rare, et correspond à des sorties majeures de XCP-ng. Vates exploite 2 types de releases. Une dite LTS (Long Term Support) valable 5 ans et une version standard, généralement deux fois par an.

Et ça tombe bien puisqu’au moment d’écrire cet article, la version standard 8.3 de XCP-ng est sortie il y a quelques semaines, à savoir le 7 octobre 2024. Je vais donc délaisser la version 8.2, qui reste la release LTS, pour bénéficier des nouveautés de la 8.3.

C’est une version importante avec beaucoup d’évolutions sous le capot. Je vous invite à lire le détail de l’annonce de la release sur le site de Vates pour en apprendre davantage sur ce qu’elle apporte.

Pour ce type d’update, il est préféré de passer directement par l’ISO. Comme j’avais pu l’expliquer dans mon article traitant de l’installation de XCP-NG, il suffit d’utiliser une clef USB et un outil comme rufus, pour copier l’ISO sur la clef, la rendre bootable et pouvoir suivre l’assistant d’installation de l’hyperviseur.

À la différence de ma première installation, cette fois-ci l’installateur de XCP-ng détecte la présence d’une précédente version déjà en place sur le disque du serveur. Il me suffit donc de valider l’upgrade plutôt qu’une nouvelle installation et de suivre les quelques écrans de confirmation qui suivent.

Cliquez sur l'image pour l'agrandir.

Cliquez sur l'image pour l'agrandir.

Après quelques minutes, on peut redémarrer le serveur en retirant la clef et laisser la nouvelle version de XCP-ng démarrer.

Cliquez sur l'image pour l'agrandir.

Une fois l’hyperviseur en ligne, il est conseillé de procéder de suite à une mise à jour des paquets, comme on n’a déjà pu le faire via la commande yum update. Il y’a très souvent déjà des correctifs de disponibles suite à la publication de l’ISO.

Cliquez sur l'image pour l'agrandir.

Une fois toutes les mises à jour faites, on peut se rendre sur l’interface de Xen Ochestra et vérifier que les serveurs sont bien dans la nouvelle release de XCP-ng, à savoir dans mon exemple, la version 8.3.

Avant de conclure, je vous invite à tester la nouvelle GUI, nommée XO Lite, embarquée désormais par défaut dans l’hyperviseur XCP-ng. Il suffit de taper l’IP de votre serveur pour accéder à cette interface que je trouve extrêmement pratique. Cela renforce pour moi la crédibilité de XCP-ng comme remplaçant à la version gratuite de ESXi disparue avec le rachat de Broadcom.

Il est possible de passer de cette interface à Xen Orchestra très facilement, ce qui permet d’offrir deux vues intéressantes, la première via XO lite avec un résumé de l’état de son hyperviseur et la seconde plus complète, mais plus complexe via Xen Ochestra pour piloter son pool de serveurs XCP-ng.

Cliquez sur l'image pour l'agrandir.

Cliquez sur l'image pour l'agrandir.

Cliquez sur l'image pour l'agrandir.

Conclusion

La mise à jour d’une stack Vates à travers l’upgrade de Xen Orchestra et XCP-ng se faite très facilement. Même si le choix d’avoir déployé Xen Orchestra via les sources complexifie un peu le travail, il n’y a finalement rien d’insurmontable. Je continu de croire que l’écosystème Vates est promis à un bel avenir, même s’il connait une notoriété moindre que Proxmox.

Les produits sont complets, performants et méritent qu’on s’y attarde. Les travaux sur la version 9.0 ont déjà commencé. Cette future LTS devrait être construite un peu différemment avec un focus sur l’idée d’offrir la meilleure solution possible pour ceux qui seraient forcés de quitter VMware.

Souhaitons bon courage aux équipes de Vates et espérons que les frenchies arrivent se faire une place sur ce marché de la virtualisation largement bousculé ces derniers temps…ils le méritent sans aucun doute !