Migration VMware vers Proxmox : le guide terrain post-Broadcom

Arrêtons de tourner autour du pot. Depuis que Broadcom a racheté VMware, la question n'est plus "faut-il envisager une alternative ?", mais "quand et comment on migre ?". Les hausses de tarifs de 800 à 1 500 % ne sont pas une rumeur : ce sont des chiffres documentés par le CISPE et confirmés par des centaines de DSI en Europe.

Si vous lisez cet article, vous avez probablement reçu votre nouveau devis VMware et vous cherchez une sortie. Ce guide est fait pour vous.

En novembre 2023, Broadcom finalise le rachat de VMware pour 69 milliards de dollars. Ce qui a suivi, tout le monde le sait :

• Fin des licences perpétuelles : tout passe en abonnement annuel obligatoire
• Bundles forcés : impossible d''acheter vSphere seul, il faut prendre le pack complet (VCF ou VVF)
• Minimum de cores par contrat revu à la hausse (annoncé à 72 en avril 2025, puis partiellement assoupli sous la pression de l''industrie)
• Pénalité de 20 % si vous renouvelez en retard

En clair : Broadcom a transformé VMware en machine à cash. Les petites et moyennes structures sont les premières victimes, avec des factures multipliées par 10 ou plus du jour au lendemain. L'université de Lille a publiquement signalé une multiplication par 12 de son budget VMware avant négociation.

La réalité du terrain : beaucoup d'entreprises ont commencé à regarder Proxmox VE sérieusement. Et c'est un mouvement qui s'accélère.

Soyons honnêtes sur les deux côtés de la balance.

Ce que vous gagnez

• Coût : économie de 80 à 90 % sur les licences. Pour une infra de 50 VMs, comptez plus de 260 000 euros économisés sur 5 ans par rapport aux tarifs VMware post-Broadcom
• Pas de vendor lock-in : Proxmox est open source (licence AGPL v3). Personne ne peut vous imposer un changement de tarif du jour au lendemain
• Performance : les benchmarks (notamment Blockbridge) montrent des gains significatifs en IOPS et en latence par rapport à vSphere, avec un overhead CPU et mémoire généralement inférieur
• KVM/QEMU : un hyperviseur éprouvé, utilisé massivement en production (AWS utilise KVM sous le capot)

Ce que vous perdez

• vMotion en live : la migration à chaud existe sur Proxmox mais elle est moins mature que vMotion
• Écosystème partenaire : moins de solutions tierces certifiées Proxmox que VMware
• Support entreprise : le support Proxmox existe, mais il n'a pas la profondeur de VMware GSS (Global Support Services)
• DRS/HA avancé : le placement automatique de VMs est plus basique sur Proxmox

Pour une PME ou une ETI avec 10 à 200 VMs, le ratio bénéfice/risque penche largement en faveur de Proxmox. Pour un grand compte avec 5 000 VMs et des workflows vSAN critiques, la discussion est plus nuancée.

Phase 1 : inventaire et audit (2 à 4 semaines)

Avant de toucher quoi que ce soit, vous devez savoir exactement ce que vous avez. C''est la phase la plus sous-estimée et la plus importante.

Ce qu''il faut documenter :

• Liste complète des VMs avec OS, vCPU, RAM, stockage
• Dépendances inter-VMs (qui parle à qui, sur quels ports)
• Configurations réseau (VLANs, trunk, règles firewall)
• Snapshots et politiques de sauvegarde existantes
• Licences logicielles liées à VMware (Veeam, Zerto, etc.)

# Export de l'inventaire VMware via PowerCLI
Get-VM | Select-Object Name, PowerState, NumCpu, MemoryGB,
  @{N='DiskGB';E={(Get-HardDisk -VM $_ | Measure-Object CapacityGB -Sum).Sum}},
  @{N='OS';E={$_.Guest.OSFullName}} |
  Export-Csv -Path vm-inventory.csv -NoTypeInformation

Classez vos VMs en trois catégories :

1. Simples : serveurs Linux standards, applications stateless
2. Moyennes : serveurs Windows, bases de données, applications avec état
3. Critiques : VMs avec des dépendances matérielles (GPU passthrough, USB), clusters applicatifs

Phase 2 : POC sur environnement de test (2 à 3 semaines)

Ne migrez jamais directement en production. Montez un cluster Proxmox de test avec au minimum 2 noeuds et validez :

• L''import de VMs VMware via l''Import Wizard de Proxmox
• La connectivité réseau (VLANs, SDN si nécessaire)
• Les performances disque (comparez avec vos benchmarks VMware)
• La compatibilité des drivers VirtIO avec vos OS

# Installer Proxmox VE sur un serveur de test
# Puis importer une VM depuis ESXi
qm importovf 100 /path/to/exported-vm.ovf local-lvm

Depuis Proxmox VE 8.2, l'Import Wizard dans l'interface web simplifie considérablement cette étape. Il gère la conversion de stockage, la configuration réseau et l'installation des drivers VirtIO automatiquement.

Phase 3 : préparation de l'infrastructure Proxmox (2 à 4 semaines)

Une fois le POC validé, préparez votre infrastructure cible.

Réseau :

• Reproduisez votre topologie VLAN existante
• Configurez les bridges Linux (vmbr0, vmbr1, etc.)
• Si vous utilisez vDS (vSphere Distributed Switch), étudiez le SDN natif de Proxmox

Stockage :

• Pour remplacer vSAN : Ceph intégré à Proxmox ou stockage partagé (NFS, iSCSI)
• Pour les performances : ZFS local avec réplication entre nœuds
• Dimensionnez le stockage avec 20 % de marge minimum

Haute disponibilité :

• Configurez le cluster Proxmox HA (basé sur Corosync)
• Définissez les groupes HA et les priorités de redémarrage
• Testez le failover en simulant une panne de noeud

Sauvegarde :

• Déployez Proxmox Backup Server pour remplacer votre solution de sauvegarde VMware
• Configurez les jobs de sauvegarde incrémentale
• Validez les restaurations

Phase 4 : migration par vagues (4 à 8 semaines)

La réalité du terrain : on ne migre pas tout d''un coup. On procède par vagues, en commençant par les VMs les moins critiques.

Vague 1 : VMs simples (semaines 1 et 2)

• Serveurs de développement et de test
• Serveurs de monitoring
• Serveurs web statiques

Vague 2 : VMs moyennes (semaines 3 à 5)

• Serveurs applicatifs
• Serveurs de base de données non critiques
• Serveurs de fichiers

Vague 3 : VMs critiques (semaines 6 à 8)

• Bases de données de production
• Applications métier critiques
• VMs avec passthrough matériel (GPU, USB)

Pour chaque VM migrée :

# Méthode 1 : Import Wizard (recommandé)
# Via l'interface web : Datacenter > Storage > Add > ESXi
# Puis : VM > Import Disk > Convert

# Méthode 2 : Export OVF + Import CLI
# Sur VMware :
ovftool vi://root@esxi/vm-name /export/vm-name.ovf

# Sur Proxmox :
qm importovf 200 /export/vm-name.ovf local-lvm --format qcow2
qm set 200 --net0 virtio,bridge=vmbr0
qm set 200 --boot c --bootdisk scsi0

Point critique : les drivers VirtIO

Pour les VMs Windows, installez les drivers VirtIO avant la migration si possible (depuis VMware). Sinon, la VM ne verra pas ses disques au premier boot sur Proxmox. Pour Linux, le noyau inclut nativement les drivers VirtIO, pas de souci.

Phase 5 : validation et bascule (1 à 2 semaines)

• Validez les performances de chaque VM migrée
• Comparez les métriques avec les baselines VMware
• Mettez à jour le monitoring et les alertes
• Documentez la nouvelle architecture
• Formez les équipes ops sur l'interface Proxmox

Après avoir accompagné plusieurs migrations chez SHPV, voici les erreurs qu''on voit le plus souvent :

1. Sous-estimer la formation des équipes

Proxmox n''est pas VMware. L''interface est différente, la logique de stockage est différente, la gestion réseau est différente. Prévoyez au minimum 3 jours de formation pour vos administrateurs.

2. Négliger les tests de reprise

Migrer c'est bien. Pouvoir restaurer, c'est mieux. Testez vos sauvegardes Proxmox Backup Server avant de décommissionner VMware. Un plan de reprise d'activité testé vaut plus que mille promesses.

3. Oublier les dépendances VMware Tools

VMware Tools (ou open-vm-tools) doit être remplacé par QEMU Guest Agent sur Proxmox. Sans lui, pas de freeze des filesystems pour les snapshots cohérents, pas d''arrêt propre depuis l''interface.

# Sur les VMs Linux migrées
apt remove open-vm-tools -y   # ou yum remove
apt install qemu-guest-agent -y
systemctl enable qemu-guest-agent
systemctl start qemu-guest-agent

4. Migrer trop vite

La pression du renouvellement VMware pousse à aller vite. Résistez. Une migration bâclée en 4 semaines coûtera plus cher en incidents qu'un renouvellement VMware d'un an le temps de faire les choses proprement. Comptez 3 à 6 mois pour une migration sérieuse de 50 à 200 VMs.

5. Ignorer le réseau

Le passage de vDS (vSphere Distributed Switch) aux bridges Linux est souvent le point de friction principal. Documentez chaque VLAN, chaque règle, chaque trunk avant de commencer.

En clair : comptez 3 à 5 mois. Pas 3 semaines. Quiconque vous promet une migration complète en un mois vous ment ou va bâcler le travail.

Chez SHPV, nous opérons des infrastructures Proxmox en production depuis des années, sur nos datacenters de Toulouse, Bordeaux et Lyon. Nous avons accompagné plusieurs clients dans leur migration VMware vers Proxmox, de l'audit initial jusqu'à la bascule finale.

Notre approche : pas de précipitation, pas de promesses irréalistes. On audite, on teste, on migre par vagues, et on reste présent après la bascule. Si vous êtes en pleine réflexion, notre équipe infogérance peut vous accompagner sur tout le parcours.

Le stockage est souvent le sujet qui inquiète le plus les DSI. VMware vSAN est un produit mature, et le quitter demande un minimum de réflexion.

Option 1 : Ceph intégré

Proxmox intègre nativement Ceph, un système de stockage distribué open source. Il offre la réplication, le self-healing et le scaling horizontal. C''est l''équivalent fonctionnel le plus proche de vSAN.

Prérequis minimum :

• 3 nœuds avec au moins 1 SSD dédié aux OSD (Object Storage Daemons)
• Un réseau dédié au trafic Ceph (10 Gbps minimum, 25 Gbps recommandé)
• Séparation physique du réseau de management et du réseau Ceph

# Installation de Ceph sur un cluster Proxmox (depuis l'interface web)
# Datacenter > Ceph > Install Ceph
# Puis création des OSD sur chaque noeud :
pveceph osd create /dev/sdb
pveceph osd create /dev/sdc

# Création d''un pool pour les VMs
pveceph pool create vm-pool --pg_num 128 --size 3

Option 2 : ZFS local avec réplication

Pour les clusters plus petits (2 à 4 nœuds), ZFS local avec réplication Proxmox est souvent plus simple et plus performant que Ceph :

• Snapshots instantanés et quasiment gratuits
• Réplication asynchrone entre noeuds (toutes les 15 minutes par défaut)
• Compression native (lz4 ou zstd)

# Création d''un pool ZFS
zpool create -f rpool mirror /dev/sda /dev/sdb
zfs set compression=lz4 rpool
zfs set atime=off rpool

Option 3 : stockage partagé classique

Si vous avez déjà une baie SAN ou un NAS, Proxmox supporte NFS, iSCSI, Fibre Channel et GlusterFS. C''est souvent la voie la plus rapide pour une migration car vous réutilisez l''infrastructure existante.

La réalité du terrain : pour une infra de 50 à 100 VMs, ZFS local avec réplication est le meilleur compromis simplicité/performance. Au-delà de 100 VMs ou si vous avez besoin de scaling horizontal, partez sur Ceph.

Peut-on migrer à chaud depuis VMware ?

Non. Il n''existe pas de migration live cross-hyperviseur. Chaque VM nécessite un arrêt (même bref) pour l''export et l''import. Pour les services critiques, prévoyez une fenêtre de maintenance ou mettez en place un load balancer qui bascule le trafic.

Les performances sont-elles comparables ?

Oui, et souvent meilleures. KVM/QEMU avec les drivers VirtIO offre des performances proches du bare-metal. Les benchmarks indiquent des performances proches du bare-metal avec les drivers VirtIO, souvent supérieures a vSphere sur les opérations disque. Le point d''attention reste le stockage : un Ceph mal configuré sera toujours plus lent qu''un vSAN bien tuné.

Proxmox est-il adapté a un environnement Windows Server ?

Oui, à condition d'installer les drivers VirtIO. Proxmox supporte Windows Server 2016 à 2025, y compris les fonctionnalités de clustering WSFC. Le point faible : pas d'équivalent natif à vSphere Fault Tolerance pour les VMs Windows critiques.

Que faire des sauvegardes Veeam existantes ?

Veeam supporte Proxmox VE depuis la version 12.2 (sortie en août 2024). Vous pouvez donc conserver votre solution de sauvegarde existante. Sinon, Proxmox Backup Server est une alternative gratuite et performante, avec sauvegarde incrémentale et déduplication.

Faut-il migrer le stockage en même temps ?

Idéalement non. Découpler la migration compute (VMs) de la migration stockage réduit les risques. Si vous avez du stockage partagé, gardez-le en phase 1 et migrez le stockage dans un second temps.

La migration VMware vers Proxmox n''est pas un projet technique anodin. C''est un changement d''écosystème qui impacte les équipes, les processus et les outils. Mais face aux tarifs de Broadcom, c''est souvent la décision la plus rationnelle sur le plan économique.

Les clés du succès :

1. Auditez avant de migrer
2. Testez sur un POC avant de toucher la production
3. Migrez par vagues, du moins critique au plus critique
4. Formez vos équipes
5. Gardez VMware actif en parallèle le temps de valider

La virtualisation open source a atteint un niveau de maturité qui la rend viable pour la majorité des infrastructures d''entreprise. Le mouvement post-Broadcom ne fait que confirmer ce que beaucoup savaient déjà : dépendre d''un seul éditeur propriétaire pour une brique aussi fondamentale que l''hyperviseur est un risque stratégique. Avec Proxmox VE et la haute disponibilité, ce risque disparaît.

• Proxmox Wiki : Migrate to Proxmox VE
• IT-Connect : Broadcom VMware, des hausses de tarifs de 800 % a 1 500 %
• Le Monde Informatique : Broadcom durcit sa politique sur les licences VMware