Proxmox VE vs XCP-ng : choisir un hyperviseur open source

D'abord la réponse

Les deux sont des plateformes d'hyperviseur sérieuses, activement développées, entièrement open source, avec de vraies entreprises derrière. Personne ne se fait renvoyer pour avoir choisi l'une ou l'autre. La version courte de leurs points forts respectifs :

• Proxmox VE est le choix par défaut le plus solide pour les exploitants de serveurs dédiés : tout intégré sur chaque nœud (interface web, clustering, sauvegardes, pare-feu), ZFS et Ceph de premier ordre, conteneurs LXC natifs aux côtés des VM, et une base Linux/KVM moderne qui suit les noyaux actuels. Si vous exploitez d'un à une dizaine d'hôtes et voulez une plateforme autonome, c'est le chemin le plus court.
• XCP-ng séduit là où son héritage XenServer le fait : un hôte hyperviseur délibérément allégé avec une gestion centralisée dans Xen Orchestra (un seul écran pour de nombreux pools et sites), un modèle de release à LTS longue, un support commercial de Vates par hôte (pas par socket), et d'excellents outils d'import VMware. Les équipes venant d'ESXi + vCenter retrouvent souvent une forme familière.

Le reste, c'est le raisonnement, et les détails que les deux camps de fans ont tendance à passer sous silence.

Architecture : KVM dans Linux vs Xen plus dom0

Proxmox VE est une distribution Debian (actuellement basée sur Debian 13, PVE 9.2, noyau Linux 7.0) dont l'hyperviseur est KVM, un module à l'intérieur du noyau généraliste de l'hôte, QEMU fournissant les périphériques. L'hôte est un système Linux complet : outillage standard, pilotes arrivant avec les mises à jour du noyau, et la possibilité de faire tourner des conteneurs LXC nativement aux côtés des VM.

XCP-ng est une appliance dédiée construite sur Xen (actuellement Xen 4.17 dans XCP-ng 8.3) : un hyperviseur allégé de type 1, façon microkernel, démarre en premier, et toute la gestion tourne dans une VM de contrôle privilégiée, dom0. Il descend de Citrix XenServer (forké ouvertement en 2018, maintenant maintenu par Vates) et hérite à la fois de la vertu de cette conception (un hôte minimal façon appliance, auquel on touche à peine) et de son bagage : le userspace actuel de dom0 est basé sur CentOS 7 avec un noyau de l'ère 4.19, maintenu sécurisé par le rétroportage propre à Vates plutôt que par la fraîcheur de l'upstream. Un XCP-ng 9.0 modernisé est en développement sans date annoncée, donc évaluez la plateforme telle qu'elle est livrée aujourd'hui. Conséquence pratique du dom0 vieillissant : le matériel récent a parfois besoin de pilotes supplémentaires, là où le noyau actuel de Proxmox les a généralement déjà.

Une différence de capacité découle directement des architectures : Proxmox fait tourner des conteneurs nativement ; XCP-ng est VM uniquement (les conteneurs vont à l'intérieur des VM).

Gestion : intégrée partout vs un seul écran pour tout

C'est la scission philosophique qui détermine la plupart des adoptions réelles :

• Proxmox : chaque nœud embarque l'interface web complète ; n'importe quel nœud gère l'ensemble du cluster. Rien de plus à déployer, aucune VM de gestion à maintenir en vie, la contrepartie étant que la supervision multi-cluster/multi-site n'est pas le point fort intégré.
• XCP-ng : l'hôte n'offre que le XO Lite intégré et léger pour l'essentiel ; la vraie gestion vit dans Xen Orchestra (XO), un déploiement séparé qui gère ensuite de nombreux pools et sites depuis un seul endroit, y compris tout le système de sauvegarde. Il existe deux versions de XO : l'appliance clé en main (XOA) est limitée en fonctionnalités sur le palier gratuit, tandis que compiler XO depuis les sources débloque tout, gratuitement : même code, sans QA ni support. (L'interface XO 6 réécrite est sortie fin 2025 et continue de mûrir ; l'interface XO 5 reste l'outil quotidien pour certaines opérations.)

Aucun des deux n'a tort : l'intégré-par-nœud est plus simple à petite échelle ; le hub-and-spoke fait mieux évoluer la supervision. Adaptez cela au nombre d'hôtes et de personnes dont vous disposez.

Le tableau comparatif

Deux lignes du tableau méritent les notes de bas de page que les fournisseurs omettent. La limite de 2 TiB par disque qui a poursuivi XCP-ng pendant des années n'a vraiment été levée qu'en mai 2026, quand le support de QCOW2 est passé en GA (nouveau plafond 16 TiB) : assez récent pour que beaucoup de conseils en ligne le traitent encore comme d'actualité, dans les deux sens. Et SMAPIv3, la pile de stockage de nouvelle génération de XCP-ng, reste en tech preview : le stockage de production d'aujourd'hui tourne sur la pile plus mature mais plus ancienne que les travaux QCOW2 ont prolongée.

Stockage et sauvegardes : la différence de profondeur

Pour un exploitant de serveurs dédiés, c'est le plus grand atout de Proxmox : ZFS dès l'installation (sommes de contrôle, snapshots, réplication) et Ceph totalement intégré pour les clusters hyperconvergés, les deux gratuits, les deux de premier ordre dans l'interface. Le modèle SR de XCP-ng couvre bien les backends standards, mais ZFS/Ceph n'y sont pas des citoyens de premier ordre, et la réponse hyperconvergée de Vates (XOSTOR) est un module payant.

Les sauvegardes sont plus proches de la parité, mais façonnées différemment : Proxmox associe vzdump intégré au Proxmox Backup Server, séparé et gratuit, pour des sauvegardes dédupliquées, vérifiées et chiffrées ; l'équivalent de XCP-ng vit dans Xen Orchestra (sauvegardes delta, réplication continue, mirroir vers du stockage froid, remotes S3), réellement capable, avec la même nuance sources-ou-payant que XO lui-même. Une remarque sur l'écosystème qui en dit long sur la maturité des deux plateformes : Veeam a ajouté un support officiel pour Proxmox puis XCP-ng dans ses versions récentes : le monde de la sauvegarde entreprise traditionnelle traite désormais les deux comme mainstream.

Tarifs et support : par socket vs par hôte

Les deux plateformes sont pleinement fonctionnelles sans abonnement : vous payez pour des dépôts stables/testés et des humains, pas pour des fonctionnalités. Les modèles diffèrent dans leur forme, ce qui compte selon la structure de votre parc de serveurs :

• Proxmox facture par socket CPU : de €120 (Community, accès au dépôt enterprise) à €1,100 (Premium, réponse en 2 heures) par socket et par an. Les serveurs bi-socket comptent double ; les machines mono-socket sont bon marché à couvrir.
• Vates VMS facture par hôte (ou au forfait) : Essential à $2,000/an couvrant jusqu'à 3 hôtes, Pro $1,000/hôte/an, Enterprise $1,800/hôte/an avec 24/7. Les hôtes bi-socket denses ne coûtent pas plus cher, les petites structures à trois hôtes s'insèrent parfaitement dans le palier forfaitaire.

Passez votre topologie réelle au crible des deux grilles tarifaires ; le gagnant bascule selon le nombre de sockets. Les paliers gratuits des deux entreprises sont assez honnêtes pour que beaucoup de parcs de production tournent sans abonnement avec le support communautaire, un choix légitime si votre équipe sait se dépanner seule.

Pour les réfugiés de VMware

Les deux projets ont passé les années post-Broadcom à polir la piste. Proxmox fournit un assistant d'import ESXi (pointez-le vers un hôte, importez les VM avec leurs disques). L'import V2V de Xen Orchestra transfère depuis ESXi/vSphere via le VDDK propre à VMware : seulement les blocs alloués, support de la migration warm, sources vSAN incluses. Aucune des deux migrations n'est plus la partie difficile ; la partie difficile, c'est de repenser les habitudes opérationnelles (vCenter → XO vient naturellement ; vCenter → le modèle par nœud de Proxmox est un changement mental plus important, adouci par de meilleures options de stockage au bout du compte).

Verdict, sous conditions

• Choisissez Proxmox VE si vous êtes exploitant de serveurs dédiés et voulez une plateforme par machine avec tout à bord (ZFS/Ceph, conteneurs, sauvegardes via PBS) et une prise en charge matérielle par noyau actuel. La recommandation par défaut pour la plupart des lecteurs de ce blog, et la raison d'être de notre gamme Proxmox.
• Choisissez XCP-ng si vous centralisez la gestion de plusieurs pools/sites dans un seul XO, vous appréciez l'hôte allégé façon appliance et les longues fenêtres LTS, vous venez de XenServer/ESXi et le modèle de pool convient à votre équipe, ou des tarifs de support par hôte conviennent à du matériel dense.
• Dans tous les cas, vous obtenez une vraie plateforme, pas un compromis : développement actif, véritable import VMware, véritables solutions de sauvegarde, et des entreprises (Proxmox GmbH, Vates) dont les intérêts sont alignés avec les produits open source.

Questions fréquentes

Le dom0 de XCP-ng, basé sur CentOS 7, est-il un problème de sécurité ?

Pas de la façon que les mots suggèrent : l'équipe sécurité de Vates rétroporte les correctifs vers le userspace de dom0 et Xen lui-même est activement patché, donc « CentOS 7 est EOL » ne signifie pas « XCP-ng n'est pas patché ». Les coûts honnêtes sont ailleurs : un noyau plus ancien signifie que le matériel récent nécessite parfois un travail de pilotes, et la plateforme porte une dette technique que le XCP-ng 9.0 en développement doit résorber (aucune date de sortie annoncée). Jugez le produit tel qu'il est livré aujourd'hui : sécurisé, un peu daté en dessous, avec une modernisation visiblement en cours.

Qu'est-ce qui est le plus rapide, Xen ou KVM ?

Il n'y a pas de réponse générale honnête : les deux sont des conceptions de type 1 matures, à quelques pourcents l'une de l'autre sur des charges de travail serveur typiques, et les résultats basculent selon la charge de travail, l'OS invité, le stockage et le réglage. Quiconque cite un benchmark tranché entre hyperviseurs mesure généralement des piles de stockage ou la fraîcheur des pilotes, pas les hyperviseurs. Choisissez selon le modèle de gestion, l'intégration du stockage et l'écosystème (les dimensions ci-dessus, où les différences sont réelles et durables), pas sur des micro-benchmarks.

Dois-je payer pour obtenir toutes les fonctionnalités de Xen Orchestra ?

Non. C'est le fait le plus mal compris de cette comparaison. Le code source de XO est entièrement ouvert avec chaque fonctionnalité (y compris la suite de sauvegarde complète) ; le compiler soi-même depuis les sources (des scripts communautaires ramènent cela à quelques commandes) débloque tout, gratuitement. Ce que Vates vend, c'est l'appliance XOA prête à l'emploi avec QA et support derrière. Budgétez honnêtement cela dit : un XO « gratuit » compilé depuis les sources signifie que c'est vous qui le mettez à jour et le dépannez, le même calcul d'auto-support que le dépôt sans abonnement de Proxmox.

Lequel dois-je utiliser sur un serveur dédié unique ?

Proxmox, dans la plupart des cas : l'interface intégrée signifie que la machine se gère elle-même sans rien déployer en plus, ZFS dès l'installateur donne une résilience de stockage sur un seul hôte, LXC permet aux petits services d'éviter la surcharge des VM, et l'histoire mono-nœud est aboutie. L'architecture de XCP-ng (hôte allégé, gestion ailleurs) brille avec plusieurs hôtes ; sur exactement un serveur, cela signifie soit faire tourner XO en VM sur l'hôte qu'il gère, soit vivre avec les bases de XO Lite.

Déploiement sur Serverside

Quel que soit le côté de cette comparaison sur lequel vous atterrissez, le socle est le même : nos serveurs dédiés avec stockage NVMe et réseau privé sont livrés avec Proxmox VE préinstallé en moins d'une minute, et XCP-ng s'installe proprement via notre ISO + console KVM-over-IP si la voie Xen est la vôtre. ASN 55285, mitigation DDoS permanente, et du matériel que chaque hyperviseur consommera avec plaisir.

Le côté Proxmox de l'étagère : ce qu'est Proxmox VE, la comparaison avec ESXi, installation, réseau, et clustering.