Migrer de VMware vers Proxmox : guide pratique

Avec les changements de politique tarifaire imposés par Broadcom depuis le rachat de VMware, de nombreuses entreprises envisagent une migration vers Proxmox VE. C'est un projet réaliste et bien documenté, mais qui nécessite une planification rigoureuse pour éviter les pièges.

Ce guide détaille les étapes concrètes d'une migration, de l'audit initial à la mise en production, en passant par la conversion des machines virtuelles.

Pourquoi migrer maintenant ?

Plusieurs facteurs poussent les entreprises à quitter VMware :

• Explosion des coûts — le passage au modèle d'abonnement Broadcom multiplie les coûts par 2 à 5 selon les configurations
• Fin des licences perpétuelles — même si vous avez payé une licence, vous devrez passer à l'abonnement pour continuer à recevoir les mises à jour
• Bundling forcé — impossible d'acheter uniquement ESXi, il faut prendre le bundle VMware Cloud Foundation ou VMware vSphere Foundation
• Incertitude stratégique — la roadmap produit sous Broadcom reste floue, et les équipes historiques de VMware ont été largement restructurées

Étape 1 : Auditer l'existant

Avant de toucher à quoi que ce soit, faites un inventaire complet de votre environnement VMware :

Utilisez les commandes PowerCLI pour extraire l'inventaire si vous avez beaucoup de VMs :

# Lister toutes les VMs avec leurs ressources
Get-VM | Select-Object Name, PowerState, NumCPU, MemoryGB,
    @{N='DiskGB';E={(Get-HardDisk -VM $_ | Measure-Object -Sum CapacityGB).Sum}} |
    Export-Csv -Path vm-inventory.csv -NoTypeInformation

Étape 2 : Préparer l'infrastructure Proxmox

Installez Proxmox VE sur vos nouveaux serveurs (ou sur les mêmes serveurs après désinstallation d'ESXi, si vous procédez par phases). Points importants :

• Version — utilisez la dernière version stable de Proxmox VE (8.x au moment de la rédaction)
• Réseau — configurez les bridges Linux et les VLANs pour correspondre à votre topologie VMware
• Stockage — décidez entre stockage local (ZFS, LVM), NFS/iSCSI, ou Ceph distribué
• Cluster — si vous avez plusieurs nœuds, créez le cluster Proxmox avant de commencer les imports

Choix du stockage

Si vous veniez de vSAN, Ceph est l'équivalent naturel : stockage distribué, réplication automatique, pas de dépendance matérielle spécifique. La configuration de Ceph est intégrée à l'interface web de Proxmox.

Étape 3 : Exporter les VMs depuis VMware

L'export se fait au format OVF/OVA (Open Virtualization Format) depuis vSphere Client ou en ligne de commande avec ovftool.

Via vSphere Client

1. Éteignez la VM (ou prenez un snapshot si elle doit rester en ligne)
2. Clic droit sur la VM → Export OVF Template
3. Choisissez le répertoire de destination
4. L'export génère un fichier .ovf (descripteur) et un ou plusieurs fichiers .vmdk (disques)

Via ovftool (ligne de commande)

# Export d'une VM depuis vCenter
ovftool \
    'vi://admin@vsphere.local@vcenter.example.com/Datacenter/vm/MyVM' \
    /export/MyVM.ova

# Export depuis un hôte ESXi directement
ovftool \
    'vi://root@esxi01.example.com/MyVM' \
    /export/MyVM.ova

Étape 4 : Convertir les disques

Proxmox utilise le format qcow2 (QEMU Copy On Write) ou raw pour ses disques virtuels. Les fichiers VMDK de VMware doivent être convertis.

L'outil qemu-img, installé par défaut sur Proxmox, gère cette conversion :

# Conversion VMDK vers qcow2
qemu-img convert -f vmdk -O qcow2 MyVM-disk1.vmdk MyVM-disk1.qcow2

# Conversion VMDK vers raw (recommandé pour Ceph/ZFS)
qemu-img convert -f vmdk -O raw MyVM-disk1.vmdk MyVM-disk1.raw

# Vérifier l'image convertie
qemu-img info MyVM-disk1.qcow2

Quel format choisir ?

Pour du stockage Ceph ou ZFS, privilégiez le format raw : ces systèmes de fichiers gèrent eux-mêmes les snapshots et le thin provisioning, rendant les fonctionnalités de qcow2 redondantes (et pénalisantes en performances).

Étape 5 : Importer dans Proxmox

Proxmox VE 8.x intègre désormais un outil d'import direct depuis l'interface web et en ligne de commande.

Méthode 1 : Import OVA/OVF via l'interface web

Depuis Proxmox VE 8.2, l'interface web permet d'importer directement un fichier OVA ou un ensemble OVF+VMDK. L'assistant crée la VM avec les paramètres détectés (CPU, RAM, disques) et effectue la conversion automatiquement.

Méthode 2 : Import manuel en ligne de commande

# 1. Créer une VM vide avec les bons paramètres
qm create 100 \
    --name MyVM \
    --memory 4096 \
    --cores 4 \
    --net0 virtio,bridge=vmbr0 \
    --ostype l26 \
    --scsihw virtio-scsi-single

# 2. Importer le disque converti
qm importdisk 100 MyVM-disk1.qcow2 local-lvm

# 3. Attacher le disque importé à la VM
qm set 100 --scsi0 local-lvm:vm-100-disk-0

# 4. Configurer le boot sur ce disque
qm set 100 --boot order=scsi0

# 5. Ajouter un affichage et démarrer
qm set 100 --vga qxl
qm start 100

Méthode 3 : Import direct depuis ESXi

# Import direct depuis un hôte ESXi (Proxmox 8.2+)
# Ajoutez d'abord l'hôte ESXi comme source de stockage dans l'interface
# puis utilisez l'assistant d'import intégré

# Ou via qm importovf
qm importovf 100 /path/to/MyVM.ovf local-lvm

Étape 6 : Adapter la configuration

Après l'import, certains ajustements sont nécessaires :

Pilotes VirtIO (crucial pour les performances)

VMware utilise des pilotes PVSCSI et VMXNET3. Proxmox fonctionne mieux avec les pilotes VirtIO (paravirtualisés). Pour les VMs Linux, les pilotes VirtIO sont généralement déjà dans le noyau. Pour Windows, il faut installer les VirtIO Windows drivers.

Réseau

• Remplacez les interfaces VMXNET3 par des interfaces VirtIO (virtio-net)
• Vérifiez que les VLANs sont correctement configurés sur les bridges Proxmox
• Mettez à jour les fichiers de configuration réseau dans la VM (/etc/network/interfaces ou NetworkManager) si les noms d'interfaces changent

VMware Tools

• Linux : désinstallez VMware Tools et installez qemu-guest-agent
• Windows : désinstallez VMware Tools et installez le QEMU Guest Agent depuis l'ISO VirtIO

# Sur une VM Linux (Debian/Ubuntu)
apt remove open-vm-tools open-vm-tools-desktop
apt install qemu-guest-agent
systemctl enable qemu-guest-agent
systemctl start qemu-guest-agent

Étape 7 : Tester et valider

Ne mettez jamais en production sans une phase de tests rigoureuse :

• Démarrage et accès — la VM démarre-t-elle correctement ? L'OS se charge-t-il ?
• Réseau — la VM est-elle joignable ? Les règles de pare-feu fonctionnent-elles ?
• Performances I/O — testez les performances disque avec fio ou dd
• Applications — tous les services (web, BDD, mail) fonctionnent-ils normalement ?
• Sauvegardes — Proxmox Backup Server sauvegarde-t-il correctement la VM ?
• HA — si vous avez un cluster, testez le failover en simulant une panne de nœud

Pièges courants et solutions

Planning type d'une migration

Pour une infrastructure de taille moyenne (10 à 50 VMs), voici un planning réaliste :

Datacampus vous accompagne

Chez Datacampus, nous avons l'expérience des migrations d'hyperviseur. Notre équipe peut vous accompagner à chaque étape :

• Audit — analyse de votre environnement VMware existant et recommandations d'architecture Proxmox
• Migration — export, conversion et import de vos VMs avec validation complète
• Infogérance — gestion au quotidien de votre infrastructure Proxmox (supervision, mises à jour, sauvegardes)
• Hébergement — si vous souhaitez externaliser, nous hébergeons vos VMs sur notre infrastructure Proxmox + Ceph en France

La migration de VMware vers Proxmox n'est pas un saut dans l'inconnu. C'est un projet technique maîtrisé, avec un écosystème mature et une communauté en pleine croissance. Et les économies réalisées sur les licences financent largement l'investissement dans la migration.

Datacampus — Infrastructure open source, hébergée en France, avec un vrai support humain.