XCP-ng ou Proxmox VE : pourquoi la question revient
La recherche « xcp-ng » progresse nettement en France ces derniers jours. Après le passage de VMware à l'abonnement par cœur, que nous avons détaillé dans notre comparatif Proxmox vs VMware, deux hyperviseurs open source reviennent dans toutes les discussions d'administrateurs : Proxmox VE, bâti sur KVM, et XCP-ng, bâti sur Xen. Les deux s'installent directement sur le matériel, gèrent des machines virtuelles Linux et Windows, savent former un cluster et se passent de licence payante.
Ce guide compare XCP-ng et Proxmox VE sur ce qui compte quand on virtualise un serveur dédié : l'architecture Xen contre KVM, l'interface de gestion (Xen Orchestra contre l'interface web intégrée de Proxmox), le stockage (SR contre ZFS et Ceph), les sauvegardes, la haute disponibilité, les licences et le support, la migration depuis VMware. Il se termine par des critères concrets pour deux cas courants : un serveur dédié seul, et un petit cluster de trois machines. Toutes les versions citées sont celles de novembre 2026.
La réponse courte
- Un serveur dédié seul : Proxmox VE est le choix le plus direct. L'interface web est sur le nœud, ZFS et les conteneurs LXC sont intégrés, et Proxmox Backup Server couvre les sauvegardes. XCP-ng fonctionne très bien en mono-nœud, mais il faut ajouter une VM Xen Orchestra pour les sauvegardes et la gestion complète.
- Un cluster de trois serveurs : les deux conviennent. Proxmox VE fait de la haute disponibilité sur disques locaux grâce à la réplication ZFS ou à Ceph intégré. XCP-ng exige un stockage partagé pour sa HA (NFS, iSCSI ou XOSTOR) et donne avec Xen Orchestra un outil de sauvegarde et de réplication très complet.
- Vous venez de XenServer ou de VMware et cherchez un éditeur européen avec support par hôte : XCP-ng et son éditeur français Vates. Vous voulez un support facturé par socket et un écosystème Debian : Proxmox VE et son éditeur autrichien Proxmox Server Solutions.
XCP-ng et Proxmox VE : présentation
XCP-ng est une plateforme de virtualisation clé en main, issue du code de XenServer et maintenue par la société française Vates. Elle assemble l'hyperviseur Xen, un domaine de contrôle Linux (le dom0) et la pile de gestion XAPI, pilotable en ligne de commande avec xe. La version en cours est XCP-ng 8.3 LTS, sortie le 7 octobre 2024 et passée en support long terme le 16 juin 2025 ; elle est maintenue jusqu'au 30 novembre 2028 (notes de version XCP-ng 8.3). Elle embarque Xen 4.17.5 et un dom0 en noyau Linux 4.19 sur une base CentOS 7 dont l'équipe sécurité du projet rétroporte les correctifs. Les mises à jour arrivent par lots réguliers : en novembre 2026, trois lots de sécurité ont déjà été publiés. La prochaine version majeure annoncée est XCP-ng 9.0, sans date.
Proxmox VE (Virtual Environment) est une distribution Debian spécialisée, publiée sous licence AGPLv3 par Proxmox Server Solutions GmbH, à Vienne. Elle combine KVM/QEMU pour les machines virtuelles et LXC pour les conteneurs système, avec une interface web, une API REST et des outils en ligne de commande (qm, pct, pvecm). La version actuelle est Proxmox VE 9.2, publiée le 21 mai 2026 sur Debian 13 avec un noyau Linux 7.0, QEMU 11.0, ZFS 2.4 et Ceph Tentacle ; une édition ARM64 est sortie le 5 août 2026. Si vous êtes encore sur la branche 8, notre guide migrer Proxmox VE 8 vers 9 détaille la mise à niveau.
Xen contre KVM : deux architectures d'hyperviseur
Les deux sont des hyperviseurs de type 1 qui exploitent les extensions matérielles Intel VT-x ou AMD-V. Leur différence tient à la place de Linux dans la pile.
Xen et le dom0 (XCP-ng)
Xen est un hyperviseur autonome qui démarre avant tout système d'exploitation. Il ne gère que le processeur, la mémoire et l'ordonnancement des VM, et délègue les pilotes matériels (disques, cartes réseau) à une machine virtuelle privilégiée, le dom0. Les VM invitées, appelées domU, passent par le dom0 pour leurs entrées/sorties via des pilotes paravirtualisés. Conséquences pratiques :
- Le dom0 reçoit une quantité fixe de RAM, retirée de ce que vous pouvez donner aux VM. La documentation XCP-ng recommande 4 Gio pour un hôte jusqu'à 64 Gio de RAM, 8 Gio jusqu'à 128 Gio et 16 Gio au-delà, à régler avec
/opt/xensource/libexec/xen-cmdline --set-xen dom0_mem=8192M,max:8192Mpuis un redémarrage. - Vous ne choisissez pas le noyau du dom0 : c'est celui empaqueté par Vates, mis à jour avec
yum update. Quand une faille touche les pilotes du dom0, comme les avis Xen XSA-526 à 528, la correction vient du projet. - XCP-ng 8.3 exige la virtualisation matérielle et la SLAT (Intel EPT ou AMD NPT), accepte jusqu'à 64 vCPU par VM et 960 processeurs logiques par hôte, et gère vTPM et Secure Boot pour Windows 11.
KVM, module du noyau Linux (Proxmox VE)
KVM est un module du noyau Linux : c'est le système hôte lui-même qui devient hyperviseur, et chaque VM est un processus QEMU. Il n'y a pas de domaine de contrôle séparé : le Debian de Proxmox VE est l'hôte, avec ses pilotes, son pare-feu et ses outils habituels. Les pilotes paravirtualisés sont les VirtIO (disque, réseau, mémoire ballon), intégrés au noyau Linux des invités et à installer sous Windows.
Proxmox VE ajoute les conteneurs LXC, qui partagent le noyau de l'hôte : un serveur de jeu Linux, une base de données ou un reverse proxy y tournent sans le surcoût mémoire d'une VM complète. XCP-ng ne propose que des machines virtuelles. Sur un serveur dédié qui héberge surtout des services Linux, cette différence pèse plus que l'écart de performance brute entre Xen et KVM, faible dans les deux cas pour le calcul et surtout lié aux pilotes pour les entrées/sorties.
Xen Orchestra contre l'interface web intégrée de Proxmox
XCP-ng : XO Lite sur l'hôte, Xen Orchestra pour tout le reste
XCP-ng 8.3 embarque XO Lite, une console web servie par l'hôte lui-même sur https://adresse-de-l-hote, avec le compte root. Elle sert à démarrer l'infrastructure et aux opérations de base sur les VM, mais n'a pas encore atteint la version 1.0 et ne fait ni sauvegardes ni gestion multi-pool : pour cela, la documentation renvoie à Xen Orchestra.
Xen Orchestra (XO) est une application web séparée, qui tourne dans une VM et pilote un ou plusieurs pools. Deux façons de l'obtenir :
- XOA, l'appliance de Vates, déployée depuis XO Lite (action « Deploy XOA ») ou depuis l'hôte avec
bash -c "$(wget --no-verbose -O- https://xoa.io/deploy)". Vates recommande 2 vCPU et 4 Gio de RAM sans sauvegardes, 4 vCPU et 8 Gio avec des tâches de sauvegarde ou de migration V2V. Un essai donne l'ensemble des fonctions Premium pendant 30 jours, puis l'appliance revient au jeu de fonctions Free tant qu'aucun abonnement n'est actif. - XO compilé depuis les sources, gratuit, sur un Debian avec Node.js LTS et Redis. Le code est entièrement open source, mais Vates le réserve aux labs et aux évaluations : pas de support professionnel, pas de QA, et une bannière le rappelle dans l'interface.
Xen Orchestra livre aujourd'hui deux interfaces, XO 5 et la nouvelle XO 6, avec une version mensuelle et deux canaux (latest et stable). Certaines fonctions, comme l'import depuis VMware, ne sont encore disponibles que dans XO 5.
Proxmox VE : l'interface est dans chaque nœud
Sur Proxmox VE, l'interface web est servie par chaque nœud sur le port 8006 et rien n'est à déployer. Dans un cluster, n'importe quel nœud permet de gérer l'ensemble, grâce au système de fichiers de configuration partagé (/etc/pve) répliqué par Corosync : il n'y a pas de maître unique. Sauvegardes, réplication, pare-feu, Ceph, SDN et haute disponibilité se configurent depuis la même interface. Pour piloter plusieurs clusters depuis une console unique, Proxmox publie séparément Proxmox Datacenter Manager.
Côté XCP-ng, un pool a un hôte maître (pool master) qui porte l'API XAPI de l'ensemble ; Xen Orchestra s'y connecte et peut gérer de nombreux pools à la fois. Un pool accepte jusqu'à 64 serveurs, tous du même fabricant de processeur et au même niveau de mise à jour.
Stockage : SR et VDI contre ZFS et Ceph
Le modèle XCP-ng : SR, VDI et PBD
Dans XCP-ng, un SR (storage repository, dépôt de stockage) est l'endroit où sont rangés les disques des VM. Chaque disque virtuel est un VDI (virtual disk image), et le lien entre un hôte et un SR est un PBD, qui décrit comment y accéder (disque local, partage NFS, cible iSCSI). Les types pris en charge officiellement (documentation stockage XCP-ng) :
- Locaux : EXT (allocation fine, thin provisioning) et LVM (allocation complète) ;
- Partagés : NFS (thin), iSCSI et Fibre Channel/HBA (thick), et XOSTOR, le stockage hyperconvergé de Vates basé sur LINSTOR et DRBD ;
- Fournis en l'état, sans support : ZFS local, XFS, CephFS, Ceph RBD, GlusterFS, MooseFS.
Le format de disque par défaut reste le VHD, limité à 2 040 Gio par disque. Depuis le 5 mai 2026, XCP-ng 8.3 gère aussi le QCOW2, jusqu'à 16 381 Gio par disque sur la plupart des SR (hors XOSTOR et SMB) : un disque de plus de 2 040 Gio est créé automatiquement en QCOW2 quand le SR le permet. La vieille limite des 2 To, souvent citée dans les comparatifs, n'est donc plus bloquante.
XOSTOR réplique les volumes entre hôtes du pool : il demande au moins 3 machines, au plus 7 par pool, un nombre de copies de 1 à 3 fixé à la création, et de préférence une interface réseau de 10 Gbit/s dédiée. Son support s'ajoute aux offres Vates, il n'est inclus dans aucune.
Le modèle Proxmox VE : ZFS, LVM-thin et Ceph intégrés
Proxmox VE propose ZFS dès l'installateur (miroir, RAID10, RAIDZ), avec snapshots, compression, sommes de contrôle et envoi incrémental. Entre deux nœuds, la réplication de stockage copie les disques ZFS locaux d'une VM vers un autre nœud selon un planning, toutes les 15 minutes par défaut et jusqu'à une fois par minute. À côté, LVM-thin, NFS, iSCSI, SMB/CIFS et les formats qcow2 et raw sont disponibles.
Pour un vrai stockage partagé sans baie externe, Proxmox VE intègre Ceph (RBD pour les disques de VM, CephFS pour les fichiers), installable et supervisé depuis l'interface. La documentation demande au moins trois serveurs, idéalement identiques, un réseau d'au moins 10 Gbit/s réservé au trafic Ceph, un OSD par disque physique sans contrôleur RAID, et au moins 8 Gio de RAM par OSD pour de bonnes performances.
En résumé : sur des disques locaux, Proxmox VE en fait plus sans composant supplémentaire (ZFS supporté, réplication, Ceph). XCP-ng est à l'aise avec un NFS ou un iSCSI existant, et XOSTOR comble l'hyperconvergé à partir de trois hôtes.
Sauvegardes : Xen Orchestra contre Proxmox Backup Server
Sur XCP-ng, les sauvegardes passent par Xen Orchestra, qui propose plusieurs modes :
- Snapshots tournants, planifiés et conservés par rotation ;
- Sauvegarde complète et sauvegarde incrémentale (seuls les blocs modifiés après la première copie complète) vers un dépôt de sauvegarde : local, NFS, SMB, Amazon S3 ou compatible S3, Azure Blob Storage ;
- Réplication complète ou incrémentale (anciennement Disaster Recovery et Continuous Replication), qui garde une copie démarrable des VM sur un autre hôte ou un autre SR ;
- Sauvegarde miroir, qui recopie un dépôt de sauvegarde vers un autre pour une stratégie 3-2-1, et sauvegarde des métadonnées du pool et de XO.
Le chiffrement des dépôts est optionnel et utilise ChaCha20-Poly1305 depuis février 2025 ; la restauration de fichiers individuels n'est possible qu'à partir des sauvegardes incrémentales.
Sur Proxmox VE, l'outil intégré vzdump sauvegarde VM et conteneurs, et Proxmox Backup Server (version 4.2 depuis le 29 avril 2026), libre lui aussi, ajoute les sauvegardes incrémentales dédupliquées, le chiffrement côté client, la restauration de fichiers et la restauration à chaud (live-restore). Il s'installe sur une autre machine, idéalement hors du serveur sauvegardé. La logique est proche : XO concentre gestion et sauvegarde dans une seule application, Proxmox sépare l'hyperviseur et le serveur de sauvegarde. Pour bâtir une stratégie complète, voyez sauvegardes et haute disponibilité d'un serveur dédié et chiffrer ses sauvegardes hors site.
Haute disponibilité et cluster
La haute disponibilité (HA) redémarre automatiquement les VM d'un hôte en panne sur un autre membre du cluster. Les deux plateformes la proposent sans licence, avec des prérequis différents :
- XCP-ng : la HA s'active au niveau du pool (
xe pool-ha-enable heartbeat-sr-uuids=<UUID>ou un interrupteur dans Xen Orchestra). Elle exige un stockage partagé (NFS, iSCSI, Fibre Channel ou XOSTOR) qui sert aussi de SR de heartbeat d'au moins 4 Gio, et des VM dont les disques sont sur ce stockage. Elle fonctionne avec deux hôtes, mais la documentation en recommande trois pour éviter le split-brain. Un hôte isolé se redémarre de lui-même pour protéger les données (fencing). - Proxmox VE : le gestionnaire HA s'appuie sur Corosync pour le quorum et sur un watchdog pour le fencing. La documentation demande au moins trois nœuds, ou deux nœuds plus un QDevice externe, et un stockage partagé ; la HA accepte aussi la réplication ZFS, avec une perte possible des écritures faites depuis la dernière synchronisation.
La migration à chaud d'une VM entre hôtes existe des deux côtés (live migration dans XCP-ng, qm migrate --online dans Proxmox VE), y compris avec des disques locaux copiés au passage. Dans les deux cas, les processeurs des hôtes doivent être du même fabricant.
Licences, coût et support
Licences open source
Aucun des deux n'a de licence payante ni de fonction bridée dans l'hyperviseur. Proxmox VE est sous AGPLv3. XCP-ng assemble des composants sous plusieurs licences libres, dont le noyau Linux (GPLv2) et Xen (GPLv2 pour l'essentiel) ; Xen Orchestra est majoritairement sous AGPLv3. Sans abonnement, Proxmox VE utilise le dépôt pve-no-subscription, moins validé que le dépôt Enterprise, et affiche un rappel à la connexion. XCP-ng reçoit les mêmes mises à jour publiques pour tous.
Deux modèles de support
Proxmox facture son abonnement par socket CPU et par an, prix nets hors taxes (tarifs Proxmox) : Community 120 €, avec le dépôt Enterprise mais sans ticket ; Basic 370 €, 3 tickets par an ; Standard 550 €, 10 tickets ; Premium 1 100 €, tickets illimités et support 24/7 depuis le 19 octobre 2026.
Vates vend des offres groupées qui couvrent le support XCP-ng de tous les hôtes et une appliance Xen Orchestra (tarifs Vates). La grille publique affiche, sans préciser la devise ni les taxes : Essential à 2 000 par an jusqu'à 3 hôtes (6 tickets par an, jours ouvrés) ; Essential+ à 4 000 par an jusqu'à 3 hôtes (tickets illimités, toutes les fonctions) ; Pro à 1 000 par hôte et par an à partir de 3 hôtes ; Enterprise à 1 800 par hôte et par an à partir de 4 hôtes, avec support 24/7 et première réponse sous 1 heure. Des remises s'appliquent sur 3 et 5 ans.
| Configuration | Proxmox VE | XCP-ng (Vates) |
|---|---|---|
| Sans abonnement | 0, toutes fonctions, dépôt no-subscription | 0, toutes fonctions de l'hyperviseur, XO depuis les sources sans support |
| 1 serveur bi-processeur, entrée de gamme | Community : 2 sockets x 120 € = 240 € HT/an, sans ticket | Essential : 2 000 par an, 6 tickets |
| 1 serveur bi-processeur, avec tickets | Basic : 2 x 370 € = 740 € HT/an | Essential : 2 000 par an |
| 3 serveurs bi-processeurs, entrée de gamme | Community : 6 x 120 € = 720 € HT/an | Essential : 2 000 par an |
| 3 serveurs bi-processeurs, tickets illimités | Premium : 6 x 1 100 € = 6 600 € HT/an | Essential+ : 4 000 par an, ou Pro : 3 000 par an |
Les périmètres ne sont pas identiques (délais de réponse, horaires, appliance XOA incluse chez Vates), mais l'ordre de grandeur est clair : pour un serveur seul, Proxmox Community est l'option payante la moins chère ; à partir de trois hôtes, le forfait Vates devient compétitif face aux niveaux Proxmox avec tickets. Le modèle par socket de Proxmox ne dépend pas du nombre de cœurs : un bi-Xeon Gold 6230 à 40 cœurs coûte le même abonnement qu'un bi-Xeon E5-2620 v4 à 16 cœurs.
Migrer depuis VMware vers XCP-ng ou Proxmox VE
Les deux éditeurs ont un outil d'import intégré depuis ESXi.
Vers XCP-ng, Xen Orchestra propose « Import, VM, From VMware » dans l'interface XO 5. XO se connecte à l'hôte ESXi ou au vCenter (port 443, plus le port NFC 902 de l'hôte ESXi), lit les disques et les importe dans un SR. ESXi 7.x et 8.x sont pris en charge, 6.x avec un transfert plus lent. La migration à chaud (warm migration) transfère l'essentiel pendant que la VM source tourne, puis une dernière synchronisation se fait VM éteinte avec l'option « Stop source ». Les disques de plus de 2 To arrivent en QCOW2 si le SR cible le permet. Non pris en charge : disques RDM, disques indépendants, disques chiffrés sans les identifiants.
Vers Proxmox VE, l'assistant d'import ESXi, intégré depuis Proxmox VE 8.2, s'ajoute comme un stockage de type « ESXi ». La VM source doit être éteinte ; l'option d'import à chaud démarre la VM sur Proxmox pendant que la copie des disques se termine, ce qui raccourcit l'interruption. Il a été testé d'ESXi 6.5 à 8.0. Le pas à pas complet est dans notre guide Proxmox vs VMware.
Dans les deux cas : retirez les snapshots, désinstallez VMware Tools, préparez les pilotes (Xen guest tools ou VirtIO sous Windows), faites une migration de test sur un réseau isolé, puis la bascule finale.
Tableau comparatif XCP-ng vs Proxmox VE
| Critère | XCP-ng 8.3 LTS | Proxmox VE 9.2 |
|---|---|---|
| Hyperviseur | Xen 4.17 + dom0 Linux 4.19 | KVM/QEMU 11.0 dans un noyau Linux 7.0 |
| Système de base | CentOS 7 maintenu par le projet | Debian 13 |
| Conteneurs | Non, VM uniquement | Conteneurs LXC intégrés |
| Interface de gestion | XO Lite sur l'hôte, Xen Orchestra (XOA ou sources) dans une VM | Interface web sur chaque nœud (port 8006), Datacenter Manager en multi-cluster |
| Ligne de commande | xe (XAPI) | qm, pct, pvecm, pvesm |
| Cluster | Pool avec hôte maître, jusqu'à 64 serveurs | Cluster Corosync multi-maître |
| Stockage local | EXT, LVM ; ZFS sans support | ZFS, LVM-thin, répertoire |
| Stockage partagé | NFS, iSCSI, FC, XOSTOR (3 à 7 hôtes) | Ceph intégré, NFS, iSCSI, SMB |
| Taille de disque virtuel | VHD 2 040 Gio, QCOW2 jusqu'à 16 381 Gio | qcow2, raw : pas de limite pratique comparable |
| Sauvegarde | Xen Orchestra : complète, incrémentale, réplication, miroir | vzdump + Proxmox Backup Server |
| Haute disponibilité | Stockage partagé obligatoire, 3 hôtes recommandés | 3 nœuds ou 2 + QDevice, stockage partagé ou réplication ZFS |
| Import VMware | XO V2V, migration à chaud | Assistant ESXi intégré, import à chaud |
| Licence | Composants libres (GPLv2 pour Xen et Linux), XO en AGPLv3 | AGPLv3 |
| Support éditeur | Vates (France), offres par pool ou par hôte | Proxmox (Autriche), par socket CPU |
| Fin de support | 8.3 LTS : 30 novembre 2028 | Branche 9 : non annoncée |
Critères pour un serveur dédié seul
Sur une machine unique, il n'y a ni HA ni migration à chaud : ce qui compte, c'est la RAM disponible pour les VM, le stockage local et les sauvegardes.
- RAM : sur un serveur de 128 Go, XCP-ng recommande de réserver 8 Gio au dom0, et une XOA avec sauvegardes prend 8 Gio de plus. Proxmox VE n'a pas de dom0, mais ZFS utilise une partie de la RAM pour son cache (ARC) ; réglez sa taille maximale si vous voulez la garder pour les VM.
- Disques : avec un seul SSD, ZFS apporte snapshots, compression et détection de corruption, pas de redondance. Avec deux disques, un miroir ZFS dans l'installateur Proxmox est le réglage le plus simple. Sous XCP-ng, un SR local EXT en allocation fine fait très bien l'affaire.
- Charges Linux légères (serveurs de jeu, bots, reverse proxy, bases de données) : les conteneurs LXC de Proxmox VE font gagner de la RAM par rapport à une VM par service.
- Sauvegardes : dans les deux cas, envoyez-les hors du serveur, vers un dépôt NFS, S3 ou un Proxmox Backup Server distant.
- Compétences : un administrateur à l'aise sur Debian sera chez lui dans Proxmox VE. Un administrateur qui connaît XenServer retrouvera ses outils (
xe, pools, SR) dans XCP-ng.
Pour ce cas, Proxmox VE est le plus simple à mettre en place. XCP-ng a du sens si vous prévoyez de rejoindre un pool existant ou si votre équipe gère déjà du Xen. Pour dimensionner les VM sur un gros processeur, voyez dimensionner Proxmox VE sur 40 cœurs et notre comparatif Xeon Gold 6230 ou Xeon E5-2620 v4.
Critères pour un cluster de trois serveurs
Trois machines, c'est le minimum recommandé des deux côtés pour un quorum fiable. La vraie question devient : où sont stockés les disques des VM ?
- Pas de baie ni de NAS : Proxmox VE avec Ceph sur les trois nœuds, ou réplication ZFS si une perte de quelques minutes d'écritures est acceptable. Côté XCP-ng, XOSTOR joue ce rôle, avec un support à souscrire en plus.
- Un NFS ou un iSCSI déjà en place : les deux fonctionnent ; XCP-ng s'y appuie naturellement pour sa HA. Attention à ne pas faire de ce partage unique le point faible du cluster.
- Réseau : prévoyez un réseau séparé pour le stockage et la réplication, d'au moins 10 Gbit/s pour Ceph ou XOSTOR. Les serveurs dédiés ElypseCloud ont un port de 1 ou 10 Gbit/s selon l'offre : vérifiez ce point avant de commander les trois machines.
- Matériel homogène : même fabricant de processeur sur tous les hôtes (obligatoire pour un pool XCP-ng et pour la migration à chaud des deux côtés), idéalement le même modèle.
- Sauvegardes et réplication : Xen Orchestra gère dans une seule tâche sauvegarde incrémentale et réplication vers un autre site ; avec Proxmox, un Proxmox Backup Server, hors du cluster, complète la HA.
- Budget support : à trois serveurs bi-processeurs, le forfait Vates Essential et les niveaux Proxmox avec tickets se situent dans des ordres de grandeur proches ; comparez les délais de réponse dont vous avez besoin.
Pour aller plus loin côté réseau, lisez SDN Proxmox et isolation réseau. Si vous possédez déjà vos machines, le housing en datacenter permet d'y installer le cluster de votre choix. Avant de signer, relisez notre checklist avant de louer un serveur dédié.
Glossaire XCP-ng et Proxmox VE
| Terme | Définition |
|---|---|
| Hyperviseur de type 1 | Logiciel de virtualisation installé directement sur le matériel, sans système hôte généraliste en dessous. |
| dom0 | Machine virtuelle privilégiée de Xen qui détient les pilotes matériels et la pile de gestion. |
| XAPI | API et pile de gestion de XCP-ng, utilisée par xe, XO Lite et Xen Orchestra. |
| Pool | Groupe d'hôtes XCP-ng gérés ensemble, avec un hôte maître. |
| SR, VDI, PBD | Dépôt de stockage, disque virtuel, et lien entre un hôte et un dépôt dans XCP-ng. |
| XOSTOR | Stockage hyperconvergé de XCP-ng basé sur LINSTOR et DRBD, de 3 à 7 hôtes. |
| Corosync et quorum | Couche de communication du cluster Proxmox VE, et majorité de nœuds nécessaire pour qu'il prenne des décisions. |
| QDevice | Arbitre externe qui apporte un vote à un cluster Proxmox de deux nœuds. |
| OSD | Démon Ceph qui gère un disque physique du stockage distribué. |
| VirtIO, guest tools | Pilotes paravirtualisés des invités, côté KVM et côté Xen. |
Conclusion
XCP-ng et Proxmox VE sont deux hyperviseurs open source matures, sans licence payante et avec un support éditeur européen optionnel. Proxmox VE regroupe tout dans chaque nœud : interface web, ZFS, Ceph, conteneurs LXC, et un serveur de sauvegarde libre à côté. C'est le choix le plus simple pour un serveur dédié seul et un bon choix pour un cluster de trois machines sur disques locaux. XCP-ng s'appuie sur Xen et sur Xen Orchestra, une console très complète pour les sauvegardes, la réplication et la gestion de plusieurs pools, avec un modèle de support par hôte qui devient intéressant dès trois serveurs.
Quel que soit votre choix, prévoyez dès l'installation les mises à jour de sécurité de l'hôte : voyez sécuriser et mettre à jour Proxmox VE, et pour une alternative plus légère, Incus sur un serveur dédié.
FiveM
Minecraft
Rust
RedM
Hytale