Proxmox VE vs VMware ESXi en 2026 : le point de vue de l'exploitant de serveurs dédiés

La réponse courte

Pour un serveur dédié mono-locataire ou un petit cluster en 2026, Proxmox VE est le choix par défaut, et VMware ESXi ne se défend que si vous payez déjà la pile vSphere complète (et que vous l'utilisez). C'est une position plus tranchée que celle de la plupart des comparatifs, et la suite de l'article la justifie : ce qu'a fait le changement de licences de Broadcom, ce que l'ESXi gratuit revenu sait faire ou non, les différences d'architecture qui comptent sur du bare metal, les pannes multi-nœuds qui font mal en production, et un calcul de coût par nœud sans complaisance.

Pourquoi lire celui-ci plutôt qu'un autre : l'essentiel du contenu Proxmox vs ESXi est écrit pour des homelabs (optimisé pour un mini-PC) ou par des éditeurs de sauvegarde (des listes de fonctionnalités qui se terminent par « et voici notre produit »). L'exploitant de serveurs dédiés a d'autres contraintes (la reprise passe uniquement par l'IPMI, le matériel est mono-locataire, il n'y a pas de SAN, et le réseau se configure sur l'hôte), et ces contraintes changent la réponse.

Ce qui a changé : Broadcom, et le retour d'ESXi

Deux événements ont remis cette comparaison à zéro, et il faut tenir compte des deux.

Le changement de licences. Depuis le rachat de VMware par Broadcom, les licences perpétuelles ont disparu : tout passe par abonnement, licencié par cœur physique, avec un minimum de 16 cœurs par CPU facturé même sur les processeurs qui en ont moins. Les anciennes références à la carte ont été fondues en deux offres : VMware vSphere Foundation (VVF) pour le mid-market et la plus large VMware Cloud Foundation (VCF) pour un cloud privé complet (VCF ajoute NSX, SDDC Manager et 4× la capacité vSAN incluse). Il y a aussi eu, en 2025, un minimum de 72 cœurs par commande très commenté ; son statut actuel reste confus (certains canaux indiquent qu'il a été retiré après la levée de boucliers, d'autres le citent encore), traitez-le donc comme une question à poser à votre revendeur, pas comme une règle fixe. Pour un petit exploitant équipé de CPU récents à grand nombre de cœurs, le modèle par cœur plus le plancher d'abonnement porte le coût annuel bien au-dessus de ce que coûtait auparavant la licence pour le même matériel.

L'ESXi gratuit est revenu, mais lisez les limites. Broadcom a réintroduit un ESXi gratuit avec la version 8.0 Update 3e en avril 2025. La question « faut-il simplement revenir à l'ESXi gratuit ? » s'est donc rouverte ; voici les limites documentées, tirées directement de la KB de Broadcom :

• 8 vCPU par machine virtuelle. Pas 8 au total, 8 par VM. Une seule VM de base de données à 16 vCPU est exclue.
• Jusqu'à 2 CPU physiques (sockets) par hôte. C'est un plafond de sockets, pas de VM.
• Les API de gestion sont en lecture seule. C'est la limite qui pèse le plus : les outils de sauvegarde tiers (Veeam et consorts) s'appuient sur des API en écriture (VADP), donc vous ne pouvez pas sauvegarder les VM d'un ESXi gratuit avec eux. Pas de vMotion, de DRS ni de HA non plus.
• Il ne peut pas être géré par vCenter, et il n'y a ni support ni SLA.

Mises bout à bout, ces limites font de l'ESXi gratuit un bon produit pour un lab ou un hôte isolé, et une base inadaptée pour un serveur de production géré et sauvegardé, surtout sur une machine bi-socket récente avec 32 cœurs ou plus par socket, où le plafond de 8 vCPU par VM et l'absence d'API de sauvegarde se font sentir tout de suite. À la mi-2026, le build gratuit est toujours 8.0U3e ; vSphere 9 existe, mais il n'y a pas d'ESXi 9 gratuit. « L'ESXi gratuit est de retour » est donc vrai, et presque sans conséquence pour un serveur de production.

L'architecture, là où elle compte sur du bare metal

Les tableaux fonctionnalité par fonctionnalité passent à côté de ce qui diffère quand vous possédez toute la machine. Quatre points comptent.

Modèle d'hyperviseur : KVM + LXC vs un Type-1 pur. Proxmox VE fait tourner à la fois des machines virtuelles KVM complètes et des conteneurs système LXC depuis une seule interface ; ESXi est un hyperviseur Type-1 pur qui ne fait tourner que des VM. Sur une seule machine dense, cette différence se chiffre en argent : les conteneurs LXC partagent le noyau de l'hôte, ce qui permet d'empiler bien plus de charges Linux sur le même matériel qu'avec des VM complètes, tout en gardant des VM pour ce qui a besoin de son propre noyau ou d'une frontière d'isolation stricte.

Stockage : défini par logiciel vs la pile VMware. Proxmox fournit d'emblée ZFS (local, avec snapshots, checksums et réplication), Ceph RBD (distribué, hyperconvergé) et LVM-thin, plus répertoire/NFS/iSCSI. VMware fournit VMFS sur stockage bloc et vSAN, et dans les offres actuelles la capacité vSAN est comptée par cœur dans la licence. Sur un serveur dédié avec du NVMe local et sans SAN, ZFS sur un nœud ou Ceph sur quelques nœuds s'impose naturellement, et c'est inclus au lieu d'être licencié au téraoctet.

Réseau : du Linux sur l'hôte. Le réseau de Proxmox repose par défaut sur des bridges Linux, avec Open vSwitch et un framework SDN disponibles ; vous le configurez dans /etc/network/interfaces comme sur n'importe quelle machine Linux, ce que fait déjà un exploitant de serveurs dédiés. VMware utilise des vSwitches standard ou distribués, avec NSX uniquement dans l'offre VCF. Quand votre chemin de reprise est une console IPMI, « c'est juste du réseau Linux » est un avantage concret.

API et automatisation. Proxmox livre une API REST complète sur chaque installation (HTTPS sur 8006, pvesh, jetons d'API), gratuitement. La surface d'automatisation de vSphere se trouve derrière vCenter et une licence payante, et surtout, l'API de l'ESXi gratuit est en lecture seule : la version gratuite n'a donc aucune API d'automatisation ou de sauvegarde exploitable. Si vous pilotez votre infrastructure avec Terraform ou Ansible, Proxmox s'automatise dès le premier jour, sans frais.

La réalité de l'exploitation (ce qu'aucun tableau de fonctionnalités ne couvre)

C'est ici que l'expérience d'un exploitant en production s'écarte d'un test en homelab. Proxmox est excellent, mais il a des angles vifs qui n'apparaissent qu'à l'échelle multi-nœuds et sous pression mémoire. Les connaître à l'avance fait la différence entre une infrastructure sans histoires et une mauvaise nuit. Voici ceux qui mordent le plus souvent, avec le correctif.

L'ARC de ZFS qui grignote la RAM des invités

L'incident classique de Proxmox sur ZFS : des VM se mettent à swapper ou sont tuées par l'OOM killer sur un hôte qui « a largement assez de RAM », parce que le cache en mémoire de ZFS (l'ARC) a grossi jusqu'à la remplir. ZFS considère la RAM libre comme disponible pour le cache, et en cas de contention l'ARC et les allocations des invités se disputent la mémoire.

Ce n'est pas théorique : les forums Proxmox en débordent. Dans un fil représentatif, un hôte de 64 GB sous Proxmox 8.1.4 avait un ARC proche de 32 GB ; comme l'a résumé un habitué du forum, « ZFS prend 32GB, la VM 16.5GB, Proxmox prend 2GB, ce qui fait 80 % », et l'OOM killer a fini par tuer la VM Windows Server de 16 GB, récupérable seulement par un redémarrage via IPMI. Dans un autre, un hôte de 32 GB avait un ARC bloqué à 15.5 GiB (99.7 %) et tuait sans cesse un invité Windows par OOM, alors que ses VM ne demandaient qu'environ 8 GB à elles toutes. Même cause dans les deux cas : l'ARC laissé à l'ancienne valeur par défaut de ZFS, environ la moitié de la RAM de l'hôte.

Les versions récentes de Proxmox atténuent le problème : depuis PVE 8.1, l'installateur plafonne l'ARC à 10 % de la RAM de l'hôte, avec un maximum de 16 GiB, alors qu'avant 8.1 il reprenait la valeur par défaut de ZFS, 50 % (62.5 % sur ZFS 2.3.0+). Mais des hôtes installés sur d'anciennes versions, mis à niveau sur place ou montés à la main peuvent encore tourner avec l'ancienne valeur. Le correctif est explicite : définissez zfs_arc_max (en octets) dans /etc/modprobe.d/zfs.conf et régénérez l'initramfs. Pour plafonner l'ARC à 8 GiB :

# 8 GiB in bytes
echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf
update-initramfs -u -k all
reboot

Un piège documenté : si la valeur choisie pour zfs_arc_max est inférieure ou égale à zfs_arc_min, baissez aussi zfs_arc_min, sinon la modification n'est pas prise en compte. La règle empirique documentée est d'environ 2 GiB de base plus ~1 GiB d'ARC par TiB de pool, le reste allant aux invités, et la vraie leçon est de vérifier arc_summary sur tout hôte dont vous héritez au lieu de supposer que le plafond est en place. Dans le cas des 64 GB ci-dessus, l'exploitant a retenu un plafond de 24 GiB ; dans celui des 32 GB, un plafond de 4 GiB a ramené l'hôte à une utilisation mémoire stable d'environ 70 %.

Un cluster à deux nœuds a besoin d'un QDevice pour le quorum

Un cluster à deux nœuds ressemble à de la HA sans en être. Le clustering de Proxmox repose sur corosync, qui a besoin d'une majorité des votes pour garder le quorum ; avec deux nœuds, en perdre un laisse au survivant une voix sur deux (pas de majorité), et il cesse donc de prendre des décisions de cluster pour éviter le split-brain. Les équipes le découvrent au pire moment : un nœud meurt et le « cluster » se fige.

Le correctif est soit un vrai cluster à trois nœuds, soit un Corosync QDevice, un démon externe léger (il peut tourner sur une petite VM, voire sur un Raspberry Pi à côté) qui apporte une troisième voix, celle de l'arbitre. Tranchez la question avant que le second nœud passe en production, pas après.

Ceph sur trop peu de nœuds ou un réseau trop faible

Ceph est excellent et ne pardonne pas le sous-dimensionnement. La recommandation de Proxmox est d'au moins 3 nœuds (5 recommandés en production) et d'un réseau dédié de 10 Gbps au minimum, 25 Gbps ou plus dès que vous êtes sur NVMe. Faites tourner Ceph sur deux nœuds, ou sur un lien partagé de 1 Gbps, et vous obtenez la déception attendue : blocages pendant la reconstruction, pics de latence, et une resynchronisation qui sature le lien dont vos VM ont besoin. Si vous n'avez ni le nombre de nœuds ni le réseau pour Ceph, utilisez plutôt ZFS avec réplication. C'est le bon outil pour deux ou trois nœuds.

Migration à chaud : des attentes réalistes

La migration à chaud fonctionne bien sous Proxmox, mais deux chiffres sont souvent confondus : l'interruption de bascule (la brève pause pendant laquelle la dernière mémoire modifiée et l'état CPU sont transférés) et la durée totale de migration (le temps que prend tout le transfert). Ils se comportent différemment, et les forums Proxmox regorgent de journaux de tâches qui le montrent. Proxmox vise une interruption de bascule maximale par défaut de 100 ms, qui augmente automatiquement (200 ms, 400 ms, …) seulement si l'invité modifie sa RAM plus vite que le lien ne peut l'écouler. Sur un stockage partagé ou rapide, la bascule mesurée se situe entre quelques dizaines et quelques centaines de millisecondes, presque quelle que soit la taille de la VM. Voici des valeurs réelles que des exploitants ont collées depuis leurs propres migrations :

Ces journaux donnent deux leçons d'exploitant. D'abord, l'interruption de bascule ne dépend pratiquement ni de la taille de la RAM ni du débit du lien pour une migration qui se déroule normalement : c'est la durée totale qui varie avec RAM ÷ débit. Ensuite, ce qui plombe le plus la durée totale n'est pas le réseau mais le tunnel de chiffrement SSH : il est limité à un seul cœur et plafonne couramment le débit bien en dessous de la carte réseau. Dans un cas avec une VM de 32 GB sur un lien Ceph de 40 Gbps, la migration sécurisée par défaut a pris plus de 20 minutes ; passer à migration: insecure sur le réseau de cluster de confiance l'a ramenée à 30 secondes. Et soyez précis sur le mot « interruption » : la valeur journalisée correspond à la pause stop/copy de QEMU, et une interruption nulle n'existe pas ; une bascule sous la seconde sur stockage partagé est l'objectif réaliste, pas zéro. Rien de cela n'est un défaut de Proxmox ; c'est le genre de détail qu'un test en homelab ne fait jamais apparaître et qu'un exploitant de flotte intègre à sa planification.

Coût : par nœud, pas par siège

Les approches homelab et par siège masquent ce qui intéresse l'exploitant : la facture récurrente par nœud physique. Les deux modèles ont des formes opposées, et c'est cette forme qui compte.

Proxmox est gratuit en production sous AGPLv3 ; l'abonnement est optionnel et facturé par socket CPU et par an, uniquement pour le dépôt enterprise stable et le support. Relevés sur la page tarifaire de Proxmox (juillet 2026, hors TVA, en EUR) : Community 120 €, Basic 370 €, Standard 550 €, Premium 1 100 €, par socket et par an. Sur un nœud bi-socket, cela va de 0 € (dépôt no-subscription) à 2 200 €/an au niveau le plus élevé.

VMware est un abonnement par cœur physique avec le minimum de 16 cœurs par CPU. Broadcom ne publie pas de grille tarifaire publique, donc chaque chiffre est une estimation tierce datée, mais le modèle suffit à comprendre. Un nœud bi-socket à 32 cœurs par socket représente 64 cœurs à licencier, facturés chaque année. Le chiffre le mieux sourcé concerne VCF : un VP de Broadcom a décrit une baisse « de 700 $ par cœur et par an à 350 $ » lors de la relance de juin 2024, mais cette « baisse » est trompeuse, puisque VCF à 350 $ intègre désormais NSX, vSAN et Aria et s'impose à de nombreux clients : pour la plupart, l'effet net a été une hausse, pas une économie. Pour l'offre VVF destinée au mid-market, les calculs de revendeurs en 2026 situent le marché entre 150 $ et 190 $ par cœur et par an, contre une moyenne d'environ 135 $ encore citée depuis la relance.

Vérifiez auprès d'un revendeur : les chiffres ci-dessous sont des estimations tierces datées (juillet 2026), pas des prix publiés par Broadcom.

Les chiffres VMware sont annuels et récurrents ; la colonne Proxmox est un forfait de support optionnel et fixe (ou zéro avec le dépôt no-subscription). Sur une petite flotte, l'écart se cumule chaque année.

Côté sauvegarde : Proxmox Backup Server est gratuit et open source, avec des sauvegardes incrémentales côté client et dédupliquées côté serveur pour les VM, les conteneurs et les hôtes physiques. Veeam est excellent et prend désormais en charge Proxmox VE comme plateforme à part entière (ajouté dans Backup & Replication 12.2, en 2024), mais c'est un abonnement par charge de travail en plus. Si le poste sauvegarde pèse dans votre budget, PBS fait encore pencher le calcul en faveur de Proxmox.

En résumé : pour une petite flotte, le coût par nœud de Proxmox est un forfait de support fixe et optionnel (ou zéro), alors que celui de VMware est un abonnement obligatoire, récurrent et par cœur, qui augmente avec le nombre de cœurs. Sur les CPU actuels à grand nombre de cœurs, l'écart est large et se cumule chaque année.

Quand ESXi reste le bon choix

Pour être crédible, il faut dire où le sortant l'emporte, et il l'emporte dans certains cas :

• Vous exploitez déjà (et utilisez) la pile vSphere complète. Si DRS, vSAN, NSX et l'automatisation vCenter portent votre exploitation et que les réflexes de votre équipe sont ceux de vSphere, tout arracher pour économiser sur les licences peut coûter plus que ce que cela rapporte.
• Une certification éditeur ou une appliance exige ESXi. Certains logiciels d'entreprise et appliances virtuelles ne sont certifiés ou supportés que sur vSphere. Si un contrat de support en dépend, la question est tranchée.
• Un processus d'entreprise audité est construit autour de vCenter. La gestion des changements, le RBAC et les outils de conformité branchés sur vCenter représentent un coût de changement réel. Une migration doit en tenir compte.
• Vous avez déjà investi dans vSAN ainsi que dans le modèle d'exploitation qui va avec, et vous n'êtes pas prêt à le reconstruire sur Ceph.

Aucun de ces cas ne décrit le locataire type de serveur dédié ou la petite flotte d'hébergement, mais si l'un d'eux vous correspond, la maturité d'ESXi est réelle et elle n'a pas disparu.

Migrer d'ESXi vers Proxmox : la version courte

Depuis la version 8.2, Proxmox VE intègre un assistant d'import pour les invités VMware : vous ajoutez l'ESXi (ou vCenter) comme stockage source d'import sous Datacenter → Storage → Add → ESXi, puis vous récupérez les VM. Il dialogue directement avec l'API d'ESXi, prend en charge ESXi 6.5–8.0 et propose un mode « live import » qui démarre la VM tôt et copie le reste en arrière-plan. Deux réserves tirées de migrations réelles sont à connaître d'abord :

• Ce n'est pas rapide, et vSAN n'est pas pris en charge. L'importateur passe par l'API de VMware, qui limite le débit ; des utilisateurs du forum signalent des débits aussi bas que ~30 MB/s via vCenter, et certains contournent l'assistant pour les grosses VM au profit d'un Storage vMotion vers NFS. Les VM hébergées sur vSAN ne peuvent pas du tout être importées par l'assistant.
• Les invités Windows ont besoin d'une préparation VirtIO, sinon ils ne démarrent pas. Importez un disque de démarrage Windows directement sur un contrôleur VirtIO SCSI et il plante en écran bleu avec INACCESSIBLE_BOOT_DEVICE (code d'arrêt 0x7B), parce que Windows n'a pas de pilote de stockage VirtIO chargé. Le correctif documenté consiste à démarrer d'abord l'invité en SATA/IDE, installer les pilotes virtio-win, puis passer le disque de démarrage en VirtIO SCSI, ou à cocher la case « Prepare for VirtIO-SCSI » de l'assistant, et idéalement à installer les pilotes VirtIO pendant que la VM est encore sur ESXi.

Une procédure pas à pas complète mérite son propre guide ; retenez ici que la migration est un chemin balisé et documenté (le wiki officiel de migration Proxmox le décrit de bout en bout), pas une reconstruction à partir de zéro.

Le verdict, sous conditions

• Choisissez Proxmox VE si vous exploitez un serveur dédié mono-locataire ou un petit cluster, voulez des VM KVM et des conteneurs LXC sur un même hôte, tenez au stockage ZFS/Ceph et à une API REST gratuite, et préférez payer un forfait de support fixe et optionnel par socket plutôt qu'un abonnement obligatoire par cœur. C'est le choix par défaut pour le public auquel s'adresse cet article.
• Choisissez VMware vSphere payant si vous êtes déjà engagé sur DRS/vSAN/NSX/vCenter et les utilisez au quotidien, dépendez d'une certification éditeur précise ou avez un processus audité construit autour de vCenter, et pouvez absorber l'abonnement par cœur.
• Choisissez l'ESXi gratuit seulement si vous voulez un hôte de lab unique, non géré et non sauvegardé, et pouvez vivre avec 8 vCPU par VM, deux sockets et aucune API de sauvegarde. C'est un produit de homelab, pas un produit serveur.

Si vous pesez cette décision, notre guide complémentaire sur ce qu'est un hyperviseur bare metal et la comparaison des quatre principales plateformes couvre aussi XCP-ng et Hyper-V, et notre guide d'installation pas à pas de Proxmox VE détaille l'installation depuis un disque vierge. Si ce que vous prévoyez est de quitter un cloud public facturé à l'usage plutôt que les licences VMware, notre guide de migration cloud couvre le lift-and-shift et la modernisation des bases de données.

Questions fréquentes

Proxmox VE est-il prêt pour la production ?

Oui. Il est sous AGPLv3, sans plafond de fonctionnalités, de VM ou de nœuds, il sort des versions à un rythme prévisible depuis des années, et c'est la destination la plus courante des équipes qui quittent VMware. La version actuelle est Proxmox VE 9.2 (mai 2026), basée sur Debian 13 « Trixie ». Les réserves tiennent à l'exploitation, pas à la maturité : dimensionnez l'ARC de ZFS, ne faites pas tourner de HA à deux nœuds sans QDevice, et donnez à Ceph les nœuds et le réseau dont il a besoin.

Proxmox peut-il remplacer vCenter ?

Pour la plupart des exploitants, oui : le plan de gestion de Proxmox (interface web plus API REST) est intégré à chaque nœud et fonctionne en cluster nativement, il n'y a donc pas d'appliance de gestion séparée à licencier comme c'est le cas de vCenter. Ce qu'il ne remplace pas à l'identique, c'est l'ensemble de fonctionnalités DRS/NSX/vSAN d'un déploiement vSphere complet ; si elles sont au cœur de votre exploitation, c'est cet écart qu'il faut peser.

L'ESXi gratuit va-t-il revenir, ou est-il déjà de retour ?

Il est de retour. Broadcom a réintroduit l'ESXi gratuit avec le build 8.0 Update 3e en avril 2025. Mais il est plafonné à 8 vCPU par VM et à deux sockets physiques, ne peut pas être géré par vCenter et n'expose qu'une API en lecture seule, si bien que les outils de sauvegarde tiers ne peuvent pas protéger ses VM. Il convient à un lab, pas à un serveur de production sauvegardé. À la mi-2026, il n'existe pas d'ESXi 9 gratuit.

Combien de nœuds faut-il au minimum pour un cluster Proxmox ?

Vous pouvez faire tourner un seul nœud indéfiniment. Pour une haute disponibilité fiable, il faut trois nœuds afin que corosync dispose toujours d'une majorité de votes. Deux nœuds peuvent former un cluster mais ne conservent pas le quorum quand l'un tombe. Ajoutez un QDevice comme arbitre externe si vous n'en avez que deux. Ceph, lui, demande trois nœuds au minimum et cinq en production.

Déployer Proxmox VE sur Serverside.com

Proxmox a besoin de bare metal, et c'est précisément ce que nous fournissons. Serverside.com déploie Proxmox VE 9.2 sous forme d'image prête à l'emploi sur du matériel mono-locataire en moins d'une minute ; vous avez l'accès root complet sur toute la machine, donc le choix du dépôt, l'organisation du stockage et la configuration du cluster vous appartiennent. Le matériel s'y prête directement : des AMD EPYC à grand nombre de cœurs avec de la DDR5 ECC pour des hôtes denses en VM et en conteneurs, et un réseau rapide, qui compte pour les tâches gourmandes en bande passante où Proxmox excelle : Ceph et la réplication ZFS entre nœuds. Une mitigation DDoS permanente sur notre réseau ASN 55285 protège aussi bien le plan de gestion que vos invités.

Prêt à en monter un ? Parcourez nos serveurs dédiés Proxmox VE pour déployer l'image prête à l'emploi, ou toute la gamme de serveurs dédiés. Proxmox étant basé sur Debian, nos pages Debian et Ubuntu couvrent le système sous-jacent si vous préférez monter l'hôte vous-même. Vous découvrez tout cela ? Commencez par notre guide d'installation de Proxmox VE.