XCP-ng : l'alternative open source basee sur Xen face a VMware

XCP-ng occupe une place particulière dans le paysage des hyperviseurs open source. Il ne cherche pas à réinventer la virtualisation de type 1 : il s’appuie sur Xen, une technologie ancienne, éprouvée et largement déployée en entreprise. Son intérêt pour les administrateurs VMware en phase de migration tient autant à sa maturité technique qu’à son modèle de gouvernance, complété par Xen Orchestra pour l’administration, l’automatisation et la sauvegarde.

Pour une infrastructure déjà structurée autour des concepts de clusters, de pools d’hôtes, de migration à chaud et de sauvegardes centralisées, XCP-ng propose une trajectoire relativement familière. Il ne reproduit pas vSphere à l’identique, mais il couvre une grande partie des besoins courants de virtualisation d’entreprise sans dépendre d’une licence propriétaire par socket ou par cœur.

De XenServer à XCP-ng : une filiation directe

XCP-ng signifie Xen Cloud Platform - New Generation. Le projet est né en 2018 dans un contexte de forte incertitude autour de XenServer, alors distribué par Citrix sous le nom Citrix Hypervisor.

La pile technique repose sur le projet Xen, un hyperviseur de type 1 installé directement sur le matériel. Xen sépare l’hyperviseur, appelé Xen Hypervisor, du domaine de contrôle Dom0. Sur XCP-ng, Dom0 s’appuie sur une distribution Linux maintenue par le projet et prend en charge les pilotes, les outils d’administration locaux, la gestion réseau et le contrôle des machines virtuelles.

Cette architecture est historiquement différente de celle de KVM, utilisée notamment par Proxmox VE. Avec Xen, les machines virtuelles peuvent fonctionner en paravirtualisation, en virtualisation matérielle HVM ou dans un mode hybride HVM avec pilotes paravirtualisés. En pratique, les systèmes invités modernes utilisent généralement la virtualisation matérielle Intel VT-x ou AMD-V, complétée par des pilotes Xen pour optimiser les entrées-sorties.

XCP-ng est issu de la branche open source de XenServer. Il reprend donc une grande partie de ses mécanismes : API XAPI, pools d’hôtes, stockage partagé, réseaux virtuels, snapshots, migration à chaud et gestion centralisée. La différence fondamentale est organisationnelle et commerciale : XCP-ng est développé comme distribution open source communautaire, avec Vates comme principal contributeur et fournisseur de support professionnel.

Citrix Hypervisor a connu plusieurs évolutions de stratégie et de licence au fil des années. La pérennité de l’écosystème XenServer côté entreprise est désormais portée par Cloud Software Group et sa communauté, mais XCP-ng reste une branche distincte avec son propre cycle de publication, ses dépôts et son écosystème opérationnel. Pour un DSI ou un administrateur, il faut donc éviter de raisonner uniquement en termes de “fork gratuit de Citrix”. XCP-ng est aujourd’hui un produit autonome, construit sur une filiation technique commune.

Une architecture pensée pour les pools d’hôtes

L’unité de gestion centrale dans XCP-ng est le pool. Un pool regroupe plusieurs serveurs physiques XCP-ng sous une administration commune. Un hôte est désigné comme maître du pool, tandis que les autres hôtes rejoignent ce domaine de gestion. Les métadonnées du pool sont répliquées entre les membres, ce qui permet de préserver l’inventaire des VM, des réseaux, des stockages et de leurs associations. Pour aller plus loin, consultez le comparatif complet des hyperviseurs. La documentation officielle XCP-ng détaille l’architecture des pools et du dom0.

Le fonctionnement rappelle le principe d’un cluster vSphere, avec quelques différences importantes. XCP-ng ne fournit pas nativement un équivalent complet et intégré de VMware DRS. La répartition automatique de charge, les politiques de placement poussées ou l’orchestration fine des ressources relèvent davantage de Xen Orchestra et de scripts d’automatisation que d’un moteur de planification aussi complet que celui de vCenter.

Le clustering doit également être distingué de la haute disponibilité. Créer un pool permet d’administrer plusieurs hôtes ensemble et de déplacer des VM d’un serveur à l’autre. Cela ne garantit pas, à lui seul, le redémarrage automatique des VM lors d’une panne matérielle.

La haute disponibilité de XCP-ng repose sur plusieurs éléments :

• plusieurs hôtes dans un pool ;
• un stockage partagé accessible par les hôtes concernés ;
• un mécanisme de fencing ou de contrôle de l’état des hôtes ;
• une configuration cohérente des réseaux de gestion et de stockage ;
• une capacité réellement disponible pour absorber la perte d’un hôte.

Dans une architecture de production, le stockage partagé est souvent le point le plus déterminant. XCP-ng prend en charge plusieurs types de Storage Repository, ou SR : NFS, iSCSI, Fibre Channel, SMB dans certains scénarios, stockage local, ainsi que des solutions logicielles comme Ceph via des intégrations adaptées. Le choix dépendra surtout du niveau de performance, de résilience et de compétence disponible dans l’équipe.

Un point souvent sous-estimé concerne l’homogénéité du matériel. La migration à chaud entre deux hôtes exige une compatibilité processeur raisonnable. Dans des environnements Intel ou AMD homogènes, le problème est généralement maîtrisable. En revanche, mélanger des générations de CPU trop éloignées ou changer de constructeur sans plan de migration peut compliquer la mobilité des VM.

Xen Orchestra : la console qui transforme l’exploitation quotidienne

Xen Orchestra est l’outil d’administration web le plus couramment associé à XCP-ng. Il ne faut pas le considérer comme une simple interface graphique : il constitue la couche d’exploitation centrale de nombreuses plateformes XCP-ng.

Il existe deux modes principaux. Xen Orchestra peut être utilisé via son offre hébergée, ou déployé localement sous la forme de Xen Orchestra Appliance, souvent appelée XOA. Cette appliance est elle-même une machine virtuelle qui se connecte aux hôtes et pools XCP-ng via l’API XAPI.

Xen Orchestra apporte notamment :

• l’inventaire centralisé des pools, hôtes, VM, réseaux et stockages ;
• la création et le clonage de VM à partir de modèles ;
• la gestion des droits par utilisateurs, groupes et rôles ;
• l’intégration LDAP ou Active Directory selon les besoins ;
• la supervision de base et la consultation des métriques ;
• l’automatisation par tâches planifiées ;
• la gestion des snapshots ;
• l’orchestration des migrations ;
• la sauvegarde centralisée des VM ;
• les tests de restauration et la restauration à granularité fichier dans certains cas.

Pour une équipe habituée à vCenter, Xen Orchestra est le composant qui donne une cohérence opérationnelle à XCP-ng. L’administration en ligne de commande reste possible, et souvent indispensable lors du dépannage, mais l’interface XOA limite fortement le besoin de manipuler les outils locaux au quotidien.

Un exemple simple de vérification côté hôte peut être réalisé avec xe, l’outil CLI historique de XAPI :

# Lister les hôtes connus dans le pool
xe host-list

# Lister les VM, y compris les modèles et les VM système
xe vm-list

# Afficher les Storage Repository
xe sr-list

# Afficher les réseaux configurés
xe network-list

La CLI est utile pour le diagnostic, mais l’exploitation industrielle passe plutôt par l’API, Xen Orchestra, Ansible, Terraform ou des scripts internes. Le projet met à disposition des mécanismes d’automatisation, tandis que Xen Orchestra propose également une API et des fonctions d’export/import adaptées aux workflows DevOps.

Migration à chaud, snapshots et sauvegarde : ce qu’il faut réellement évaluer

La migration à chaud permet de déplacer une machine virtuelle en fonctionnement d’un hôte vers un autre. Dans le cas le plus simple, les deux hôtes accèdent au même stockage partagé : seules l’exécution de la VM, son état mémoire et certains éléments de contexte doivent être transférés.

Cette fonctionnalité est essentielle pour les opérations de maintenance. Elle permet de mettre à jour le microcode, le firmware, le système XCP-ng ou le matériel d’un hôte sans interruption applicative, à condition que le pool dispose de ressources suffisantes.

La migration avec stockage local existe dans certains scénarios, mais elle doit être évaluée avec davantage de prudence. Déplacer simultanément l’état d’exécution et les disques d’une VM peut générer une charge réseau importante et allonger l’opération. Dans la plupart des plateformes critiques, le stockage partagé reste le choix le plus prévisible pour les migrations fréquentes.

Les snapshots constituent un autre mécanisme central. Ils permettent de capturer l’état d’une VM avant une opération sensible : mise à jour applicative, modification de schéma, changement de pilote, test d’agent de sécurité ou montée de version d’un système invité.

Mais un snapshot n’est pas une sauvegarde. Il dépend généralement du stockage primaire et peut dégrader les performances s’il est conservé trop longtemps. Il faut donc l’utiliser comme filet de sécurité temporaire, pas comme méthode de rétention à long terme. Pour aller plus loin, consultez Proxmox VE, l’autre alternative open source.

Xen Orchestra ajoute une vraie couche de sauvegarde. Son approche dite “delta backup” exploite des mécanismes de suivi des blocs modifiés afin d’éviter de recopier l’intégralité d’un disque à chaque exécution. Les sauvegardes peuvent être déposées sur un dépôt distant, par exemple NFS, SMB ou S3 compatible selon l’architecture retenue.

Une stratégie minimale de production devrait inclure :

1. une sauvegarde planifiée avec rétention définie ;
2. un dépôt de sauvegarde distinct du stockage de production ;
3. des tests de restauration réguliers ;
4. un contrôle de la cohérence applicative, notamment pour les bases de données ;
5. une supervision de la durée des jobs et du taux d’échec ;
6. une procédure documentée de reconstruction d’un hôte ou d’un pool.

La fonction de restauration testée automatiquement, lorsqu’elle est utilisée, apporte une valeur opérationnelle importante. Beaucoup d’environnements disposent de sauvegardes théoriquement valides mais n’ont jamais vérifié le délai réel nécessaire pour restaurer un contrôleur de domaine, une base PostgreSQL ou une application métier complète.

XCP-ng est-il mature pour la production ?

Oui, à condition de ne pas confondre maturité logicielle et absence de conception d’architecture. Xen est utilisé depuis longtemps dans des environnements de production, y compris à grande échelle. XCP-ng bénéficie de cette base, de l’expérience héritée de XenServer et d’une communauté active autour de Xen Orchestra.

Pour des charges classiques - serveurs Linux et Windows, applications internes, middleware, services d’infrastructure, serveurs web, outils de supervision, bases de données de taille raisonnable - XCP-ng est techniquement crédible en production.

Les questions importantes sont ailleurs :

• le matériel est-il certifié ou au moins validé avec les versions ciblées ?
• la redondance réseau est-elle correctement conçue ?
• le stockage supporte-t-il la charge et les scénarios de panne ?
• les sauvegardes sont-elles testées ?
• les équipes maîtrisent-elles les procédures de pool, de récupération et de mise à jour ?
• une astreinte doit-elle pouvoir escalader vers un support éditeur ?

L’utilisation de matériel serveur classique avec contrôleur RAID correctement configuré, interfaces réseau redondées et firmware maintenu reste la voie la plus raisonnable. Les installations sur matériel hétérogène ou grand public peuvent fonctionner, mais elles déplacent le risque vers l’exploitation.

La mise à jour des hôtes doit également être intégrée à une procédure. L’ordre typique est le suivant : vérifier la compatibilité, évacuer les VM d’un hôte par migration, appliquer les correctifs, redémarrer si nécessaire, contrôler les services et réintégrer l’hôte dans la capacité disponible. Xen Orchestra peut aider à orchestrer une partie de ces opérations, mais ne remplace pas une validation de changement.

Vates et le support commercial : un élément à ne pas négliger

L’open source ne signifie pas nécessairement absence de support. Vates joue un rôle central dans l’écosystème XCP-ng et Xen Orchestra. L’entreprise contribue au développement, publié des outils, maintient des offres commerciales et propose des contrats de support.

Pour une petite équipe avec des charges non critiques, l’édition communautaire et les ressources publiques peuvent suffire. Pour une plateforme hébergeant un ERP, une messagerie, une production industrielle ou des services clients, le support commercial mérite d’être évalué dès le cadrage.

Le sujet n’est pas uniquement l’accès à une hotline. Un support structuré apporte généralement :

• une voie d’escalade en cas d’incident complexe ;
• l’accès à des correctifs ou conseils de compatibilité ;
• un cadre contractuel pour les environnements critiques ;
• une expertise sur Xen Orchestra, la sauvegarde et les architectures de référence ;
• une capacité à réduire le temps de diagnostic lors d’une panne rare.

L’approche est différente du modèle VMware historique, souvent très intégré et très standardisé dans les grandes entreprises. Avec XCP-ng, l’équipe conserve davantage de liberté sur le choix du matériel, du stockage et des outils annexes. En contrepartie, elle doit assumer davantage de décisions d’architecture.

XCP-ng ou Proxmox VE : deux alternatives, deux approches

Proxmox VE et XCP-ng sont régulièrement mis en concurrence comme alternatives open source à VMware. La comparaison est légitime, mais ils ne reposent pas sur la même philosophie.

Proxmox VE s’appuie principalement sur KVM pour les machines virtuelles et LXC pour les conteneurs. Il intègre une interface web, un cluster fondé sur Corosync, un pare-feu, une gestion de stockage étendue et une intégration forte avec Ceph. Il attire souvent les équipes qui veulent gérer VM, conteneurs et stockage distribué depuis une même plateforme.

XCP-ng se concentre sur la virtualisation de machines virtuelles Xen et s’appuie sur Xen Orchestra pour l’expérience de gestion centralisée. Son approche peut sembler plus proche de la logique vSphere : pools d’hôtes, console centrale, appliances de gestion, sauvegardes et opérations de migration. Pour aller plus loin, consultez les alternatives à VMware après Broadcom.

Le choix peut être résumé ainsi :

XCP-ng est souvent un bon choix lorsque l’objectif est de remplacer une plateforme XenServer ou de construire une ferme de VM avec une administration centrée sur Xen Orchestra. Il convient également aux équipes qui privilégient une séparation claire entre l’hyperviseur et la couche d’orchestration. Pour aller plus loin, consultez le guide de migration vers Proxmox.

Proxmox VE est souvent plus naturel pour les équipes très à l’aise avec Debian, KVM, LXC et Ceph, ou pour celles qui veulent exploiter des conteneurs au même niveau que les VM. Son intégration native de Corosync et son modèle de cluster sont attractifs, mais nécessitent aussi une compréhension solide du quorum, du réseau de cluster et des scénarios de panne.

Dans les deux cas, le choix ne devrait pas être fait uniquement sur le coût de licence. Il faut comparer la compétence interne, la stratégie de sauvegarde, les besoins de stockage, les applications supportées, les exigences de sécurité et le niveau de support attendu.

Une plateforme à évaluer par un pilote réaliste

La meilleure manière d’évaluer XCP-ng consiste à monter un pilote représentatif. Un seul hôte de test permettra de découvrir l’interface, mais ne validera ni la migration à chaud, ni la haute disponibilité, ni les comportements de stockage.

Un pilote utile devrait comporter au minimum deux ou trois hôtes, un réseau de gestion redondé, un réseau de stockage identifié, un SR partagé et une instance Xen Orchestra. Il doit inclure des VM Windows et Linux proches de la production, des sauvegardes planifiées et au moins une restauration complète.

Les tests à prévoir sont concrets :

• migration à chaud d’une VM applicative ;
• arrêt forcé d’un hôte selon un scénario contrôlé ;
• restauration complète d’une VM ;
• restauration d’un fichier ou d’une base selon les outils disponibles ;
• saturation réseau temporaire ;
• mise à jour d’un hôte ;
• redémarrage de Xen Orchestra ;
• reprise des opérations après indisponibilité du stockage.

XCP-ng n’est pas une solution “gratuite donc simplifiée”. C’est une pile de virtualisation sérieuse qui demande les mêmes fondamentaux que toute infrastructure de production : capacité, réseau, stockage, sauvegarde, documentation et procédures de crise. Son principal avantage est de rendre ces briques accessibles dans un modèle ouvert, sans enfermer l’organisation dans une tarification propriétaire imprévisible.