Migrer VMware vers Proxmox : guide complet 2025-2026

Contexte post-Broadcom : pourquoi les migrations s'accelerent

Depuis le rachat de VMware par Broadcom fin 2023, le marche de la virtualisation a subi un bouleversement sans precedent. Les nouvelles politiques commerciales de Broadcom ont provoque une vague de migrations vers des alternatives open-source, Proxmox VE en tete.

Les entreprises font face a plusieurs changements majeurs :

• Hausse des prix x3 a x10 : les renouvellements de licence VMware affichent des augmentations de 200% a 1000% selon les configurations et la taille du parc
• Bundles VCF forces : Broadcom impose VMware Cloud Foundation, regroupant vSphere, vSAN, NSX et Aria dans un package unique, meme si vous n'utilisez qu'une partie de ces produits
• Fin des licences perpetuelles : passage force a un modele d'abonnement annuel, supprimant toute capitalisation sur les investissements passes
• Arret du programme partenaire : les petits revendeurs et integrateurs sont ecartes, reduisant le choix pour les clients
• Incertitude contractuelle : les conditions changent regulierement, rendant la planification budgetaire difficile

Pour une analyse detaillee du cout total de possession et des economies realisables, consultez notre comparatif TCO VMware vs Proxmox 2026.

Prerequis et preparation

Avant de commencer la migration, une preparation rigoureuse est essentielle. Voici les elements indispensables a valider.

Inventaire VMware complet

Commencez par documenter exhaustivement votre environnement VMware. Utilisez RVTools ou le vSphere Client pour exporter ces informations :

# Export de l'inventaire via PowerCLI (sur une station avec vSphere PowerCLI)
Connect-VIServer -Server vcenter.example.com
Get-VM | Select Name, PowerState, NumCpu, MemoryGB,
  @{N='UsedSpaceGB';E={[math]::Round($_.UsedSpaceGB,2)}},
  @{N='ProvisionedSpaceGB';E={[math]::Round($_.ProvisionedSpaceGB,2)}},
  Guest, Notes | Export-Csv -Path vm-inventory.csv -NoTypeInformation

# Lister les datastores et leur utilisation
Get-Datastore | Select Name, Type, CapacityGB, FreeSpaceGB |
  Export-Csv -Path datastores.csv -NoTypeInformation

# Lister les reseaux et port groups
Get-VirtualPortGroup | Select Name, VLanId, VirtualSwitch |
  Export-Csv -Path networks.csv -NoTypeInformation

Capacity planning Proxmox

Dimensionnez votre cluster Proxmox en fonction de l'inventaire collecte :

• Stockage : prevoyez 2x la taille totale des VMs (espace pour la migration + marge de croissance). Pour Ceph, prevoyez 3x (replication factor 3)
• RAM : conservez la meme allocation totale + 10-15% de marge pour l'hyperviseur et Ceph (si utilise)
• CPU : le ratio vCPU:pCPU peut rester identique. KVM/QEMU a un overhead comparable a ESXi
• Reseau : minimum 1 Gbps dedie a la migration, idealement 10 Gbps. Prevoyez un reseau de migration distinct du reseau de production

Infrastructure Proxmox cible

• Cluster Proxmox VE operationnel avec minimum 3 noeuds pour la haute disponibilite
• Acces reseau entre l'environnement VMware et Proxmox (direct ou VPN site-to-site)
• Stockage configure : Local-LVM, Ceph, ZFS ou NFS/iSCSI selon vos besoins
• Plan de rollback documente avec procedure de retour arriere testee
• Proxmox Backup Server (PBS) installe et configure pour les sauvegardes post-migration

Pour externaliser vos sauvegardes PBS post-migration, decouvrez la sauvegarde Proxmox PBS avec NimbusBackup : replication off-site, chiffrement et deduplication inclus.

Preparation du cluster Proxmox

Configurez votre environnement Proxmox pour accueillir les VMs migrees.

Configuration reseau

Reproduisez la topologie reseau VMware sur Proxmox. Chaque VLAN VMware correspond a un bridge Linux ou un VLAN sur un bridge VLAN-aware :

# /etc/network/interfaces sur chaque noeud Proxmox

# Bridge principal VLAN-aware (remplace le vSwitch VMware)
auto vmbr0
iface vmbr0 inet static
    address 10.0.0.10/24
    gateway 10.0.0.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes

# Bridge dedie au stockage Ceph (reseau 10 Gbps)
auto vmbr1
iface vmbr1 inet static
    address 10.10.0.10/24
    bridge-ports eno2
    bridge-stp off
    bridge-fd 0

# Bridge dedie a la migration (reseau 10 Gbps)
auto vmbr2
iface vmbr2 inet manual
    bridge-ports eno3
    bridge-stp off
    bridge-fd 0

# Exemple VLAN tagge sur vmbr0 (equivalent du port group VMware)
# Les VMs selectionnent le VLAN tag directement dans leur config

Configuration stockage

Plusieurs options selon vos besoins (voir la documentation Proxmox Storage) :

• • Local-LVM : stockage local performant, ideal pour les tests et les petits deployements
• • Ceph : stockage distribue pour la haute disponibilite (remplace vSAN)
• • NFS/iSCSI : pour reutiliser un SAN existant (NetApp, Pure, etc.)
• • ZFS : pour beneficier de la deduplication, compression et snapshots natifs

# Exemple : creer un pool Ceph pour accueillir les VMs migrees
pveceph pool create vmware-migration --pg_num 128 --size 3
# size 3 = replication sur 3 OSD (equivalent a une politique vSAN FTT=1)

# Ajouter le pool comme stockage Proxmox
pvesm add rbd ceph-migration --pool vmware-migration --content images,rootdir

# Verifier l'espace disponible
ceph df

Les 4 methodes de migration VMware vers Proxmox

Proxmox propose plusieurs approches de migration V2V (Virtual-to-Virtual). Le choix depend de votre contexte : nombre de VMs, tolerance au downtime, bande passante disponible et competences de l'equipe.

Methode 1 : Import Wizard Proxmox 8.x (recommande)

Depuis Proxmox VE 8.1, l' Import Wizard permet d'importer directement depuis vCenter ou ESXi. C'est la methode la plus simple et la plus fiable pour la majorite des cas.

Methode 2 : Conversion manuelle avec qemu-img

Pour plus de controle, des VMs hors-ligne, ou si l'Import Wizard n'est pas compatible (anciennes versions ESXi, VMs avec des disques specifiques), utilisez qemu-img.

# === ETAPE 1 : Exporter depuis VMware ===

# Option A : Exporter en OVA depuis vCenter (interface web)
# VM > Actions > Export OVF Template

# Option B : Exporter directement le VMDK via SCP depuis l'ESXi
scp root@esxi:/vmfs/volumes/datastore1/myvm/myvm-flat.vmdk /tmp/

# Option C : Utiliser ovftool (VMware CLI)
ovftool vi://root@esxi/myvm /tmp/myvm.ova

# === ETAPE 2 : Convertir le disque ===

# Convertir VMDK vers qcow2 (recommande : supporte les snapshots)
qemu-img convert -f vmdk -O qcow2 myvm-flat.vmdk myvm.qcow2

# Avec compression (reduit le temps de transfert)
qemu-img convert -f vmdk -O qcow2 -c myvm-flat.vmdk myvm.qcow2

# Convertir vers raw (meilleures performances I/O, pas de snapshots qcow2)
qemu-img convert -f vmdk -O raw myvm-flat.vmdk myvm.raw

# Pour les VMDK sparse (thin provisioning), preciser le format
qemu-img convert -f vmdk -O qcow2 -p myvm.vmdk myvm.qcow2
# -p affiche la progression

# Verifier l'integrite du fichier converti
qemu-img check myvm.qcow2
qemu-img info myvm.qcow2

# === ETAPE 3 : Creer la VM sur Proxmox ===

# Creer une VM vide avec la bonne config
qm create 100 --name myvm --memory 4096 --cores 4 \
  --net0 virtio,bridge=vmbr0,tag=100 \
  --ostype l26 --bios seabios --scsihw virtio-scsi-single

# Importer le disque converti
qm importdisk 100 myvm.qcow2 local-lvm

# Attacher le disque importe a la VM
qm set 100 --scsi0 local-lvm:vm-100-disk-0,discard=on,ssd=1

# Definir le disque de boot
qm set 100 --boot order=scsi0

# Pour une VM UEFI, ajouter un disque EFI
qm set 100 --bios ovmf --efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=1

Methode 3 : Migration V2V live (Veeam / Zerto)

Pour les environnements critiques necessitant un RPO proche de zero et un downtime minimal, utilisez un outil de replication continue :

• • Veeam Backup & Replication : supporte la replication VMware vers KVM/Proxmox via Instant VM Recovery puis export
• • Zerto : replication continue avec RPO de quelques secondes, orchestration de basculement automatique
• • Carbonite Migrate : migration live avec synchronisation au niveau bloc, support multi-hyperviseur

Methode 4 : Migration CBT incrementale (grandes VMs)

Pour les VMs de grande taille (500 Go a plusieurs To), une migration complete peut prendre des heures. La methode CBT (Changed Block Tracking) permet de reduire considerablement le temps de transfert et le downtime :

# Activer le CBT sur la VM VMware (via PowerCLI)
$vm = Get-VM -Name "big-database-server"
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.changeTrackingEnabled = $true
$vm.ExtensionData.ReconfigVM($spec)

# Creer un snapshot pour initialiser le CBT
New-Snapshot -VM $vm -Name "CBT-init" -Description "Enable CBT tracking"

# Utiliser un outil comme libguestfs ou nbdkit pour lire les deltas CBT
# et les appliquer sur le disque cible Proxmox

# Premiere copie complete (en arriere-plan)
qemu-img convert -f vmdk -O qcow2 -p \
  "https://esxi/folder/big-db/big-db-flat.vmdk?dcPath=DC&dsName=DS1" \
  /tmp/big-db.qcow2

# Les passes incrementales utilisent le CBT pour identifier les blocs modifies
# et ne copier que les deltas, reduisant le downtime final a quelques minutes

Strategie pour minimiser l'interruption

Pour minimiser l'impact sur vos utilisateurs, adoptez l'approche suivante :

1. Migrez par lots : commencez par les VMs non critiques (dev, test, staging), puis les services secondaires, et enfin les services critiques
2. Migration parallele : faites tourner les deux environnements simultanement pendant la phase de transition
3. Replication des donnees : synchronisez les donnees en temps reel avec CBT ou un outil de replication
4. Tests progressifs : validez chaque lot avant de passer au suivant (checklist ci-dessous)
5. DNS / Load Balancer : redirigez progressivement le trafic vers Proxmox (TTL DNS bas)
6. Rollback ready : conservez l'environnement VMware fonctionnel pendant 2 a 4 semaines apres le dernier basculement

Pieges courants et solutions

Voici les problemes les plus frequents rencontres lors des migrations VMware vers Proxmox, et comment les resoudre :

Durees reelles de migration

Voici des benchmarks reels de migration par taille de VM, mesures sur nos projets clients. Les temps incluent la conversion de format (VMDK vers qcow2) et le transfert reseau.

Post-migration : validation et optimisation

Installation des drivers et agents

Apres la migration, optimisez les performances en installant les drivers virtio et le QEMU Guest Agent :

# === LINUX ===

# Installer le QEMU Guest Agent
apt install qemu-guest-agent    # Debian/Ubuntu
dnf install qemu-guest-agent    # RHEL 9 / Rocky / AlmaLinux
yum install qemu-guest-agent    # RHEL 7-8 / CentOS

# Activer et demarrer le service
systemctl enable --now qemu-guest-agent

# Verifier que les modules virtio sont charges
lsmod | grep virtio
# Attendu : virtio_blk, virtio_net, virtio_scsi, virtio_balloon

# Supprimer les VMware Tools
apt remove --purge open-vm-tools open-vm-tools-desktop  # Debian/Ubuntu
dnf remove open-vm-tools                                 # RHEL/Rocky

# Regenerer l'initramfs sans les modules VMware
update-initramfs -u    # Debian/Ubuntu
dracut --force         # RHEL/Rocky

# === WINDOWS ===

# 1. Monter l'ISO virtio-win comme CD-ROM dans Proxmox
#    (Telechargez depuis https://github.com/virtio-win/virtio-win-pkg-scripts)
# 2. Dans la VM Windows, installer :
#    - virtio-win-drivers (reseau, stockage, ballooning, serial)
#    - virtio-win-guest-tools (QEMU Guest Agent + drivers)
# 3. Desinstaller VMware Tools via Programmes et fonctionnalites
# 4. Reboot

Checklist de validation complete

Optimisation post-migration

Une fois les VMs migrees et validees, appliquez ces optimisations :

• • Activer le ballooning memoire : permet a Proxmox de recuperer la RAM inutilisee (virtio-balloon driver)
• • Activer le discard/TRIM : ajoutez discard=on sur les disques pour recuperer l'espace libere
• • CPU type host : utilisez --cpu host pour exposer toutes les instructions CPU a la VM
• • NUMA topology : pour les VMs avec beaucoup de RAM, activez --numa 1
• • IO thread : activez iothread=1 sur les disques virtio-scsi pour de meilleures performances I/O
• • Configurer le PRA : mettez en place un plan de reprise d'activite avec replication inter-site

Pour decouvrir nos offres VPS Proxmox infogere ou beneficier d'une infogerance post-migration VMware , consultez egalement notre etude de cas : migration 100 VMs VMware .

# Optimisations recommandees pour une VM migree (exemple VM 100)
qm set 100 --cpu host                           # CPU natif
qm set 100 --balloon 2048                        # Ballooning (min 2 Go)
qm set 100 --scsi0 local-lvm:vm-100-disk-0,discard=on,iothread=1,ssd=1
qm set 100 --numa 1                             # NUMA (si > 8 Go RAM)
qm set 100 --agent enabled=1,fstrim_clk_freq=1  # Guest Agent + TRIM auto

# Verifier la configuration finale
qm config 100

Nettoyage et decommissionnement VMware

Apres validation complete de toutes les VMs migrees (attendre 2 a 4 semaines de fonctionnement stable), procedez au decommissionnement de l'infrastructure VMware :

1. Verifiez qu'aucune VM ne tourne encore sur VMware (inventaire final)
2. Archivez les configurations vCenter (export des parametres, regles DRS, alarmes)
3. Supprimez les snapshots de migration restants sur Proxmox
4. Liberez les licences VMware (resiliation des abonnements Broadcom)
5. Reaffectez ou retirez le hardware des anciens hotes ESXi
6. Mettez a jour la documentation d'infrastructure (schema reseau, CMDB, procedures)

Documentation officielle

Pour approfondir les concepts abordes dans ce guide, consultez la documentation officielle :

Questions frequentes sur la migration VMware vers Proxmox