Lorsque les DSI évaluent des alternatives open source à VMware, Proxmox et XCP-ng sont souvent étudiés en parallèle. oVirt apparaît également dans les comparatifs, notamment en raison de son héritage KVM et Red Hat. Les trois solutions ne présentent toutefois ni la même trajectoire, ni le même modèle de support.
Mais ils sont construits différemment, opérés différemment, et leurs points forts se manifestent dans des contextes différents. Une comparaison honnête commence par comprendre leur héritage respectif.
Deux héritages, une même ambition
XCP-ng est un fork de Citrix XenServer, lui-même basé sur le projet Xen Research. L'hyperviseur Xen a une longue histoire en environnement serveur — il a été la base de l'infrastructure AWS dans ses premières années, et il est réputé pour son isolation forte entre VMs (domaine 0 séparé du domaine hôte). XCP-ng est maintenu par Vates, société française, avec un modèle commercial basé sur le support et sur Xen Orchestra Pro.
Proxmox est basé sur KVM (Kernel-based Virtual Machine), le module de virtualisation intégré au noyau Linux depuis 2007. KVM est aujourd'hui l'hyperviseur de référence dans les environnements cloud majeurs (OpenStack déploie KVM massivement). Proxmox ajoute à KVM une couche de gestion cluster, une interface web, et l'intégration des containers LXC.
Les implications pratiques de ce choix d'hyperviseur de base sont plus importantes qu'il n'y paraît.
Expérience de gestion
XCP-ng se gère via Xen Orchestra (XO), une interface web développée par Vates. XO est fonctionnellement riche : gestion des pools, live migration, sauvegarde native intégrée, monitoring des ressources. La version Community Edition est self-hosted et couvre l'essentiel pour des déploiements modestes. La version Pro (Xen Orchestra Pro / Xen Orchestra from Sources) ajoute de la complétion fonctionnelle et du support.
L'interface XO est considérée par beaucoup comme plus polished que l'interface Proxmox native sur certains aspects de workflow de gestion quotidienne — notamment la vue multi-pool.
Proxmox a une interface web native directement intégrée dans l'installation. Elle est fonctionnelle et bien pensée pour les opérations courantes. Elle n'a pas la même orientation "vue opérateur multi-sites" que XO dans sa version Pro. En revanche, l'API REST Proxmox est plus documentée et plus largement supportée par les outils d'IaC (Terraform provider officiel, module Ansible officiel).
Backup et restauration
C'est l'un des points de différence les plus pratiques au quotidien.
XCP-ng avec Xen Orchestra propose une sauvegarde native intégrée directement dans XO. Les jobs de backup VMs sont configurés dans l'interface, les snapshots Delta sont gérés, et la copie vers du stockage NFS, SMB, ou S3 est native. La gestion des rétentions, la planification, et le reporting de sauvegarde sont disponibles sans outil tiers.
Proxmox sépare la sauvegarde dans un produit dédié : Proxmox Backup Server (PBS). PBS est un système de backup spécialisé avec une déduplication incrémentale efficace, un chiffrement natif, et une vérification d'intégrité. C'est architecturalement plus robuste pour des volumes importants — mais ça demande de déployer et d'opérer un service séparé.
Pour de petits déploiements, la sauvegarde intégrée à XO est plus simple à mettre en œuvre. Pour des environnements plus larges avec des exigences de backup structurées, PBS offre plus de contrôle et de fiabilité.
Containers et workloads modernes
Proxmox intègre nativement LXC (Linux Containers) aux côtés des VMs KVM. Les containers LXC sont gérés depuis la même interface, avec les mêmes outils de backup et le même réseau. Pour des workloads Linux légers (proxies, caches, petits services), LXC est un complément intéressant qui économise la surcharge d'une VM complète.
XCP-ng est un hyperviseur VM-only. Les containers ne font pas partie de sa proposition. Si l'organisation veut faire tourner des containers, ça passe par des VMs hébergeant Docker ou Kubernetes — comme n'importe quel autre hyperviseur.
Pour les organisations dont les roadmaps incluent des workloads container natifs ou des clusters Kubernetes sur l'infrastructure de virtualisation, Proxmox offre une intégration plus cohérente.
Maturité de la communauté et support commercial
Les deux projets disposent de communautés actives, de forums et d'une base d'utilisateurs en entreprise.
XCP-ng bénéficie du soutien de Vates, société qui maintient activement le projet et commercialise des offres de support. La trajectoire du projet est stable et bien communiquée. Sa base installée en entreprise est significative en Europe, notamment dans les organisations historiquement équipées de Citrix XenServer.
Proxmox est maintenu par Proxmox Server Solutions GmbH et propose des souscriptions professionnelles. La base installée a nettement progressé depuis 2023, ce qui élargit l'écosystème de prestataires, de documentation et de formation. Le dépôt Proxmox Enterprise, destiné aux environnements de production, est accessible avec une souscription.
En termes de présence sur le marché français et européen, les deux ont des partenaires et intégrateurs. Proxmox a une avance en termes de volume de déploiements récents et de richesse de l'écosystème tiers.
Où placer oVirt dans le comparatif ?
oVirt reste un projet communautaire actif fondé sur KVM. La version 4.5.7 a été publiée en janvier 2026 et le projet conserve des atouts pour les équipes qui connaissent déjà son architecture centralisée. Il faut cependant distinguer le projet communautaire du produit commercial Red Hat Virtualization (RHV), dont la phase de vie prolongée s'achève en août 2026. La trajectoire commerciale de Red Hat se concentre désormais sur OpenShift Virtualization.
Pour un nouveau programme VMware Exit, oVirt doit donc être évalué avec un modèle de support, une capacité d'exploitation et une feuille de route explicitement documentés. Il peut rester cohérent pour une équipe déjà compétente sur oVirt ou RHV ; pour un nouveau socle généraliste, Proxmox et XCP-ng offrent aujourd'hui une lecture plus directe du support et de l'écosystème.
Sources officielles : notes de version oVirt 4.5.7 et cycle de vie de Red Hat Virtualization.
Adoption en production
Les deux tournent en production dans des environnements sérieux. Le contexte d'exploitation compte davantage qu'un classement abstrait de maturité.
XCP-ng est davantage présent dans des organisations qui viennent de Citrix XenServer et qui cherchent une continuité de l'expérience opérationnelle. La migration XenServer → XCP-ng est souvent moins coûteuse que XenServer → Proxmox, notamment pour les équipes qui maîtrisent déjà le modèle Xen.
Proxmox est davantage choisi par des organisations qui viennent de VMware ou qui démarrent une infrastructure de virtualisation sans héritage fort. L'écosystème KVM, la documentation disponible, et la traction récente en font le choix dominant pour les nouvelles installations open source.
Le critère différenciant
La vraie question de ce choix n'est pas technique. C'est organisationnelle.
Si votre équipe a des profils KVM/Linux, un appétit pour l'IaC, et des besoins de containers en parallèle des VMs — Proxmox est le choix naturel.
Si votre équipe vient d'un héritage XenServer, préfère une interface de gestion orientée opérateur, et veut une continuité d'expérience Xen sans casser les workflows existants — XCP-ng est cohérent.
Dans les deux cas, le projet open source sous-jacent est sérieux. Ce qui détermine la fiabilité en production, c'est moins le choix entre KVM et Xen que la maîtrise de l'outil par l'équipe qui l'opère.