Depuis l'annonce du changement de licence Broadcom, un seul nom revient dans toutes les conversations de migration : Proxmox. C'est mérité, mais ce n'est pas la seule sortie. XCP-ng traite exactement les mêmes dossiers de migration, avec un noyau d'hyperviseur différent et un historique qui remonte à XenServer. Il capte une part croissante des migrations là où le duo Xen Orchestra plus sauvegarde intégrée répond mieux au cahier des charges que Proxmox seul.
Cet article ne vend pas XCP-ng contre Proxmox. Il pose la mécanique réelle des deux modèles, et dit sans détour dans quels cas Proxmox reste le bon choix.
Xen et KVM, deux modèles d'hyperviseur qui ne se ressemblent pas
Proxmox repose sur KVM, un hyperviseur de type 2 au sens strict de l'implémentation : le noyau Linux hôte contient le module KVM, et QEMU émule le matériel pour chaque VM. C'est simple à raisonner, ça hérite de tout l'écosystème Linux (cgroups, réseau, stockage), et c'est ce qui a permis à Proxmox de fusionner virtualisation KVM et conteneurs LXC dans le même outil, comme on l'a détaillé en production avec LXC sur Proxmox.
XCP-ng repose sur Xen, un hyperviseur de type 1 au sens historique : Xen s'installe directement sur le matériel, en dessous de tout le reste. Ce qu'on appelle Linux sur un hôte XCP-ng n'est pas l'hôte lui-même, c'est le dom0, une VM privilégiée qui gère le matériel pour le compte de l'hyperviseur. Les VM invitées (domU) ne parlent jamais directement au matériel : tout passe par le dom0 ou par des pilotes paravirtualisés.
Cette séparation a une conséquence opérationnelle directe. Un bug ou une charge excessive dans le dom0 peut dégrader tout l'hôte, mais le dom0 lui-même reste isolé du plan de contrôle des VM au sens architecture, ce qui est l'argument historique de Xen sur l'isolation multi-tenant. AWS a fait tourner son infrastructure sur Xen pendant plus d'une décennie avant de basculer vers son propre hyperviseur Nitro, précisément sur cet argument d'isolation à grande échelle.
Côté performance pure sur une charge généraliste, la différence entre les deux modèles est aujourd'hui marginale. Le point réellement structurant, c'est l'écosystème autour de l'hyperviseur, pas l'hyperviseur seul.
Xen Orchestra : la console qui fait la différence
Proxmox VE embarque sa propre interface web et son cluster natif dès l'installation, gratuit. XCP-ng, à l'inverse, expose une API XAPI sans interface graphique construite. Toute la gestion passe par Xen Orchestra (XO), un projet développé par Vates, l'éditeur qui pilote aussi XCP-ng.
Le modèle de licence de XO structure toute la décision d'adoption. XO Lite est gratuit et suffit pour de l'administration basique : création de VM, consultation des métriques, opérations simples. Les fonctions qui comptent en production, sauvegarde avancée, plan de reprise, répartition de charge, contrôleur SDN, support éditeur, sont réservées aux abonnements payants Starter, Standard, Premium et Entreprise. Le modèle est donc l'inverse de Proxmox : l'hyperviseur est gratuit des deux côtés, mais la console de gestion complète est payante chez Vates alors qu'elle est incluse chez Proxmox (l'abonnement Proxmox finance le support et les dépôts stables, pas l'interface).
Ce détail change le calcul économique. Sur une infra où on ne veut jamais dépendre d'un abonnement pour administrer son cluster, Proxmox part avec un avantage net. Sur une infra où on accepte de payer pour une console mature en échange d'un support éditeur réactif, XO Premium ou Entreprise tient largement la comparaison, notamment sur le multi-site et le SDN.
La sauvegarde intégrée, l'argument le plus solide de XCP-ng
C'est ici que XCP-ng marque le point le plus net. Xen Orchestra intègre un moteur de sauvegarde complet dans le même outil que celui qui gère les VM : sauvegarde delta incrémentale, réplication continue vers un site distant, restauration différentielle, contrôle d'intégrité automatique des jeux de sauvegarde, et prise en charge des disques volumineux au-delà de 2 To depuis les dernières versions de XO 6.
Sur Proxmox, la sauvegarde passe par Proxmox Backup Server, un produit à part, à déployer et opérer séparément, avec son propre stockage de déduplication. C'est un excellent outil, mais c'est une seconde brique d'infrastructure à maintenir, avec son propre cycle de mise à jour et sa propre supervision.
Pour une équipe qui veut un seul plan de contrôle pour la virtualisation et la sauvegarde, sans ajouter de composant, XO répond directement au besoin. La règle qu'on applique quand on évalue une bascule : compter le nombre de systèmes distincts à opérer, pas le nombre de fonctionnalités cochées sur une plaquette. Un backup intégré dans la même console réduit un runbook entier de procédures de couplage entre deux produits.
Où Proxmox reste objectivement meilleur
Le sur-engineering marche dans les deux sens, et il faut le dire franchement.
L'écosystème et la traction communautaire. Proxmox a une base d'installation bien plus large, un forum extrêmement actif, et une comparaison directe avec VMware déjà largement documentée par la communauté. Sur un incident à 2h du matin, la probabilité de trouver quelqu'un qui a déjà rencontré exactement votre erreur est plus élevée sur Proxmox.
Les conteneurs natifs. LXC intégré nativement dans Proxmox, avec un cycle de vie unifié avec les VM, n'a pas d'équivalent direct côté XCP-ng. Si une partie significative de votre parc tourne en conteneurs système plutôt qu'en VM complètes, Proxmox évite une brique supplémentaire.
L'import ESXi. L'assistant d'import ESXi de Proxmox, considérablement amélioré depuis la version 8, simplifie une bascule VMware ligne par ligne. XCP-ng n'a pas d'équivalent aussi direct dans son outillage natif ; la migration passe généralement par un export OVA intermédiaire ou par les outils tiers du marché.
Le rapprochement avec Kubernetes. Si votre trajectoire de moyen terme mène vers des VM pilotées depuis Kubernetes, la voie KubeVirt qui fait tourner des VM dans un cluster Kubernetes s'appuie sur KVM, pas sur Xen. Un socle Proxmox reste plus proche de cette trajectoire si elle est actée.
Sur un parc de moins de dix hôtes sans exigence de sauvegarde avancée intégrée, Proxmox seul, éventuellement complété par Proxmox Backup Server, reste le choix le plus simple à opérer. XCP-ng se justifie quand la sauvegarde et la réplication multi-site sont un besoin de premier ordre dès le jour un, et que le budget d'un abonnement XO est déjà acté.
Le verdict côté ops
Les deux plateformes savent gérer une infrastructure de production, la question n'est pas la maturité technique, elle est acquise des deux côtés depuis longtemps. La question est le modèle d'exploitation qu'on veut porter.
Sur une migration VMware vers Proxmox déjà engagée, il n'y a aucune raison de revenir en arrière pour aller vers Xen : le travail de recâblage réseau et de reprise des habitudes d'exploitation serait perdu deux fois. Sur une migration qui démarre de zéro, avec une exigence forte de sauvegarde intégrée et de réplication géographique, XCP-ng mérite d'être benché avant de trancher, pas écarté par réflexe parce que Proxmox occupe tout l'espace médiatique.
Choisir un hyperviseur qui tiendra cinq ans, benché sur votre charge réelle plutôt que sur la popularité du moment, c'est le travail qu'on fait avant chaque migration qu'on opère depuis les datacenters Fullsave de Toulouse et TDF de Bordeaux. Si votre parc VMware arrive en fin de contrat et que le choix Proxmox contre XCP-ng reste ouvert, on peut chiffrer les deux trajectoires avant que la décision ne soit prise dans l'urgence.
Sources
- XCP-ng | Xen Project : positionnement officiel du projet XCP-ng au sein de la fondation Xen.
- Backup - XCP-ng Documentation : documentation officielle des mécanismes de sauvegarde disponibles sur XCP-ng.
- Xen Orchestra 6.1 : annonce des évolutions du moteur de sauvegarde et du modèle de licence par abonnement.
- Proxmox vs VMware vs XCP-ng: 2026 Hypervisor Guide : comparaison indépendante des trois plateformes sur les critères de migration 2026.
