Depuis le rachat de VMware par Broadcom, la question revient dans presque toutes les directions informatiques qui exploitent des hôtes ESXi : faut-il rester ? Les licences perpétuelles ne sont plus vendues depuis décembre 2023, l’offre a été regroupée en quelques bundles vendus en abonnement et au cœur, et les minimums de commande ont augmenté en 2025. Pour une PME ou une collectivité qui faisait tourner quelques hôtes avec une licence achetée une fois pour toutes, la facture change de nature.
Proxmox Virtual Environment est l’alternative qui revient le plus souvent. Ce n’est pas un hasard, mais ce n’est pas non plus une migration qui se fait en un week-end. Voici ce qu’il faut avoir compris avant de se lancer.
Ce qu’est vraiment Proxmox VE
Proxmox VE est une plateforme de virtualisation open source, publiée sous licence AGPLv3 par la société autrichienne Proxmox Server Solutions. Elle repose sur Debian et réunit dans une même interface web deux technologies : KVM pour les machines virtuelles, et LXC pour les conteneurs système, plus légers. La version 9, sortie en août 2025, s’appuie sur Debian 13.
Trois points changent la manière de raisonner quand on vient de vSphere.
Le logiciel est complet sans licence. Le cluster, la migration à chaud, la haute disponibilité, le stockage distribué Ceph et la sauvegarde sont présents dans la version libre. Ce que l’abonnement apporte, c’est l’accès au dépôt « entreprise », plus stabilisé, et le support de l’éditeur. Pour une production, l’abonnement reste recommandé ; mais il se choisit par processeur physique, sans minimum de cœurs, et on peut évaluer toute la plateforme avant de payer quoi que ce soit.
Il n’y a pas de vCenter. Chaque nœud expose la même interface, et le cluster se gère depuis n’importe lequel d’entre eux. C’est plus simple à déployer, mais cela suppose de comprendre le quorum : un cluster de deux nœuds ne sait pas qui a raison quand ils ne se voient plus.
Debian est sous le capot, et c’est un avantage. Tout ce qui se fait dans l’interface se fait aussi en ligne de commande, et l’hôte s’administre comme un serveur Linux. Une équipe à l’aise avec Linux est autonome très vite ; une équipe qui ne l’est pas doit d’abord combler ce manque.
Les équivalences à connaître
| Dans vSphere | Dans Proxmox VE | Ce qui change |
|---|---|---|
| Hôte ESXi | Nœud Proxmox VE | Un serveur Debian complet, administrable en SSH |
| vCenter | Interface web du cluster | Présente sur chaque nœud, sans machine dédiée |
| vMotion | Migration à chaud | Incluse, avec ou sans stockage partagé |
| vSphere HA | Gestionnaire de haute disponibilité | Repose sur le quorum : trois nœuds au minimum, ou un arbitre externe |
| Datastore VMFS | Stockages ZFS, LVM, Ceph, NFS ou iSCSI | Le choix du stockage devient une décision d’architecture |
| vSwitch | Bridge Linux, VLAN, SDN | Configuration réseau Linux classique |
| Outil de sauvegarde tiers | Sauvegarde intégrée, Proxmox Backup Server | Déduplication et vérification des sauvegardes incluses |
Migrer : l’outil existe, la méthode reste à construire
Depuis la version 8.2, Proxmox VE intègre un assistant d’import. On déclare un hôte ESXi comme stockage en lecture seule, la liste de ses machines apparaît, et l’import convertit les disques et reprend l’essentiel de la configuration. L’assistant peut même démarrer la machine côté Proxmox pendant que ses disques finissent d’être copiés, ce qui raccourcit l’interruption.
C’est un vrai progrès, mais l’outil ne fait pas le projet. Les difficultés se trouvent ailleurs.
- Les pilotes. Une machine Windows migrée démarre mieux avec les pilotes VirtIO, à installer avant ou juste après la bascule. Sans eux, disque et carte réseau tournent en mode émulé, plus lent.
- Le réseau. Les groupes de ports et les VLAN doivent être recréés à l’identique. Une erreur de VLAN ne se voit pas à l’import : elle se voit quand l’application ne répond plus.
- Les dépendances. Une base de données, son serveur applicatif et l’annuaire qui les authentifie ne se migrent pas dans n’importe quel ordre.
- La sauvegarde. L’outil de sauvegarde d’hier ne sauvegarde pas forcément la plateforme de demain. Une migration sans test de restauration côté Proxmox est une migration inachevée.
Par où commencer, dans l’ordre
- Inventorier. Machines, systèmes, tailles de disque, VLAN, dépendances applicatives, et les machines qu’on peut éteindre sans prévenir personne.
- Monter une maquette. Trois nœuds, même modestes, pour comprendre le cluster, le quorum et le stockage. C’est là que se prennent les décisions d’architecture, pas en production.
- Choisir le stockage. ZFS local avec réplication, stockage partagé existant en NFS ou iSCSI, ou Ceph sur les nœuds : chaque option a ses conditions et ses limites.
- Migrer d’abord ce qui est simple. Des serveurs Linux sans état, puis des Windows, puis les applications critiques, chacune avec une procédure de retour arrière.
- Prouver la restauration. Restaurer une machine et un conteneur depuis la sauvegarde, chronomètre en main, avant de déclarer la bascule terminée.
- Former l’équipe qui exploitera. La plateforme change, les réflexes d’exploitation aussi : l’équipe doit savoir diagnostiquer un nœud, un stockage ou un réseau virtuel sans dépendre d’un prestataire.
Pourquoi former l’équipe avant de migrer
La tentation est de confier la migration à un intégrateur et de découvrir l’outil ensuite. Le risque est de se retrouver avec une plateforme qui fonctionne, mais que personne en interne ne sait faire évoluer, sauvegarder correctement ou dépanner un vendredi soir.
Deux jours de formation avant la maquette changent la qualité des décisions : l’équipe arrive à la phase d’architecture en sachant ce que coûte un choix de stockage, pourquoi un cluster à deux nœuds pose problème, et comment vérifier qu’une sauvegarde est restaurable. Elle discute d’égal à égal avec l’intégrateur, ou se passe de lui.