Proxmox VE 9 pour un administrateur VMware : ce qui change et ce qui manque

Ce que cet article fait et ne fait pas

Les comparatifs de fonctionnalités entre VMware et Proxmox existent par centaines. Celui-ci n’en est pas un. Nous partons du vocabulaire et des réflexes d’un administrateur VMware — vCenter, vMotion, vSAN, DRS, NSX — et nous posons trois questions pour chaque concept : quel est l’équivalent dans Proxmox VE 9.2, où la correspondance tient, et où elle ne tient plus.

Nous ne traitons ici ni la procédure de migration (c’est le rôle des articles dédiés), ni les coûts de licence (ils dépendent du devis Broadcom), ni les alternatives comme OpenStack ou Nutanix.

Le pont de vocabulaire

Ce qui se retrouve

Gestion centralisée

L’interface web de Proxmox VE donne une vue unifiée de tous les nœuds d’un cluster : VMs, conteneurs, stockage, réseau. N’importe quel nœud sert de point d’entrée. Pour la gestion de plusieurs clusters, Proxmox Datacenter Manager 1.1 fournit un tableau de bord centralisé avec supervision Ceph intégrée. PDM ne remplace pas vCenter — il n’offre pas encore de RBAC unifié ni de gestion des permissions à l’échelle de plusieurs clusters — mais il couvre la supervision et les opérations courantes.

Migration à chaud

La live migration dans Proxmox VE repose sur les capacités natives de QEMU/KVM : transfert itératif de la mémoire, phase de convergence, basculement en quelques millisecondes. Le mécanisme est mature et fiable. La différence avec vMotion est dans les prérequis : vMotion fonctionne avec vSAN activé en un clic ; la live migration PVE nécessite un stockage partagé configuré séparément (Ceph, NFS ou iSCSI). Le résultat est le même, le chemin est plus long.

Haute disponibilité

Le système HA de Proxmox VE détecte la défaillance d’un nœud, déclenche le fencing (par watchdog matériel ou IPMI), et redémarre les VMs marquées HA sur les nœuds survivants. Le délai typique est de deux à trois minutes. C’est fonctionnellement comparable à vSphere HA. Les groupes HA permettent de définir des préférences de placement et des priorités de basculement.

Templates et automatisation

Les templates PVE et Cloud-Init couvrent le même besoin que les templates VMware : créer une image de référence et en dériver des clones avec personnalisation réseau et système au premier démarrage. L’API REST de Proxmox est complète et bien documentée. Terraform (via le provider Telmate ou bpg) et Ansible (via le module community.general.proxmox) s’intègrent directement. Il n’y a pas de suite comparable à vRealize Automation, mais les briques existent et s’assemblent.

Ce qui change

Le stockage n’est pas intégré par défaut

vSAN s’active dans vCenter en quelques clics sur des disques locaux. Ceph dans Proxmox VE est un composant séparé : il faut installer les paquets (pveceph install), initialiser le cluster, déployer monitors, managers et OSDs, puis créer des pools. Le résultat — un stockage distribué et répliqué — est comparable. Mais là où vSAN est une fonctionnalité de vSphere, Ceph dans PVE est un sous-système à part entière avec sa propre documentation, ses propres commandes de diagnostic (ceph -s, ceph osd tree) et ses propres contraintes de dimensionnement (réseau dédié, disques dédiés, règles CRUSH).

Ce n’est pas nécessairement un inconvénient. Ceph est un projet indépendant avec une communauté massive et un écosystème propre. Mais c’est un changement de posture : l’administrateur VMware qui activait vSAN depuis vCenter devient un opérateur Ceph en plus d’être un opérateur PVE.

Le réseau est Linux, pas NSX

VMware NSX fournit un réseau défini par logiciel complet : micro-segmentation, load balancing distribué, pare-feu distribué, routage L3 entre segments. Proxmox VE 9.2 propose un SDN en progression — zones VLAN, VXLAN, EVPN avec BGP, et depuis la version 9.2, WireGuard comme protocole de fabric — mais la portée reste celle du réseau Linux sous-jacent : bridges, VLAN, tunnels. Il n’y a pas de load balancer intégré, pas de micro-segmentation au niveau des flux applicatifs, pas de pare-feu distribué comparable à NSX.

Pour beaucoup d’environnements, les bridges Linux, les VLANs et le firewall intégré de PVE (trois niveaux : datacenter, nœud, VM) suffisent. Pour les architectures qui dépendent de NSX — multi-tenancy réseau strict, segmentation applicative fine — l’écart est réel.

Le rééquilibrage automatique est partiel

VMware DRS redistribue automatiquement les VMs entre hôtes en fonction de la charge CPU et mémoire. Proxmox VE 9.2 a introduit le CRS (Cluster Resource Scheduler) en mode dynamique, qui rééquilibre les guests HA en fonction de l’utilisation réelle des ressources. C’est un progrès significatif par rapport aux versions précédentes, qui ne faisaient que réagir aux pannes. Mais le CRS ne couvre que les guests marqués HA — pas l’ensemble des VMs du cluster. Un rééquilibrage global comparable à DRS n’existe pas encore.

L’écosystème tiers

VMware bénéficie d’un écosystème tiers massif construit sur vingt ans : Veeam, Zerto, Commvault, SolarWinds, des dizaines d’outils de monitoring, de backup et de disaster recovery certifiés. Proxmox VE a son propre outil de sauvegarde (Proxmox Backup Server), son monitoring intégré, et un écosystème en croissance rapide — mais plus jeune et plus étroit. Si votre exploitation repose sur des intégrations tierces spécifiques, vérifiez leur existence dans l’écosystème PVE avant de décider.

Le modèle de support

VMware offre un support commercial global avec des SLA contractuels, une base de connaissances étendue et un réseau de partenaires certifiés. Le support Proxmox VE fonctionne différemment : toutes les fonctionnalités sont disponibles sans souscription. La souscription (de 110 à 1 100 EUR par socket CPU et par an) donne accès au dépôt enterprise, au support technique par ticket, et à des paquets testés plus longtemps avant publication. Aucune fonctionnalité n’est verrouillée derrière la souscription.

Pour les équipes habituées au support VMware, le changement est culturel autant que technique. La communauté Proxmox (forum, listes, documentation officielle) est active et réactive. Mais un ticket de support Proxmox n’a pas le même périmètre qu’un ticket VMware GSS. Les organisations qui ont besoin d’un accompagnement plus large passent par des partenaires intégrateurs — c’est le positionnement d’EC INTELLIGENCE.

Rester sur VMware reste une option

vSphere 8 atteint sa fin de support général le 11 octobre 2027. Ce n’est pas un arrêt de fonctionnement — les hôtes continuent de tourner — mais les correctifs de sécurité s’arrêtent. Pour les organisations qui disposent d’un parc VMware stable, d’un contrat de support tiers, ou d’un calendrier de migration qui dépasse 2027, rester sur VMware avec un plan de sortie documenté peut être le choix le plus rationnel. Chaque changement de cap en cours de migration coûte des mois de travail. Mieux vaut un cadrage solide avant de bouger qu’un départ précipité vers une cible mal évaluée.

Ce que cet article ne traite pas

• La procédure de migration VMware vers Proxmox (article dédié sur le blog).
• Les coûts comparés de licences VMware et de souscriptions Proxmox (volatils, dépendent du devis Broadcom).
• Les alternatives à Proxmox : OpenStack, Nutanix, Hyper-V, cloud public.
• Le dimensionnement matériel pour Ceph.
• La configuration détaillée du SDN, de la HA ou de Ceph (couverts dans nos prestations cloud privé et dans les tutoriels du blog).

Sources : Proxmox VE 9 Administration Guide, pve.proxmox.com. Notes de version Proxmox VE 9.2, mai 2026. Proxmox Datacenter Manager 1.1, mai 2026. Broadcom, cycle de vie vSphere 8, octobre 2022. EC INTELLIGENCE, Formation Administration Proxmox VE 9, Chapitre 1.5, janvier 2026.