Migrer de VMware vers Proxmox VE : méthodes, pièges et check-list
Assistant d'import ESXi, import à chaud, OVF, conversion de disques : les méthodes pour migrer de VMware vers Proxmox VE, les pièges qui coûtent des heures et la check-list à suivre machine par machine.
Migrer de VMware vers Proxmox VE n'a jamais été aussi accessible : depuis la version 8.2, Proxmox VE intègre un assistant qui importe une machine directement depuis un hôte ESXi. L'import lui-même tient en quelques clics. Ce qui prend du temps, ce sont la préparation des machines, les cas particuliers et l'organisation des bascules.
Ce guide rassemble les méthodes disponibles, les pièges que nous avons rencontrés lors de nos essais (ESXi 8.0.3 vers Proxmox VE 9.2) et la check-list à suivre pour chaque machine.
Avant tout : l'inventaire
Une migration réussie commence par un inventaire précis, machine par machine. Les caractéristiques qui changent la méthode ou le temps nécessaire :
- le stockage : un disque sur vSAN ne s'importe pas avec l'assistant, il faut d'abord le déplacer vers un autre datastore ;
- le chiffrement : un disque chiffré, par exemple par une politique de stockage, ne s'importe pas tel quel ;
- les snapshots : ils ralentissent fortement l'import, mieux vaut les consolider avant ;
- le firmware : BIOS ou UEFI, et Secure Boot, conditionnent la configuration de la machine cible ;
- le vTPM : son état ne se migre pas vers Proxmox VE, ce qui touche notamment BitLocker ;
- le système d'exploitation : un Linux récent embarque déjà les pilotes VirtIO, Windows non ;
- les dépendances : une application répartie sur plusieurs machines doit basculer d'un bloc.
Les méthodes de migration
L'assistant d'import ESXi (recommandé)
On déclare l'hôte ESXi comme stockage de type « ESXi » dans Proxmox VE, puis on choisit la machine et on fait correspondre ses disques, ses cartes réseau et son stockage cible. Quelques règles issues de la documentation de Proxmox et de nos essais :
- connectez de préférence l'hôte ESXi plutôt que vCenter : passer par vCenter est possible, mais beaucoup plus lent ;
- arrêtez la machine source avant l'import, pour un état cohérent ;
- n'importez pas plus de quatre disques en parallèle : le service qui lit l'ESXi limite ses connexions simultanées ;
- évitez les noms de datastore contenant un « + ».
L'assistant ne dépend pas de VDDK, la bibliothèque de VMware dont le téléchargement public a disparu fin août 2026.
L'import à chaud
L'option d'import « live » démarre la machine sur Proxmox VE pendant que ses données sont copiées en arrière-plan. L'interruption est réduite, mais pas nulle : la machine reste éteinte côté ESXi. Les performances d'entrée-sortie sont dégradées au début, et si l'import échoue, tout ce qui a été écrit depuis son démarrage est perdu. À tester sur une machine de test avant de l'employer en production, et à éviter sur un réseau lent ou instable.
Les alternatives
- Export OVF ou OVA, puis import dans Proxmox VE (
qm importovf) : pratique pour une machine isolée ou un export déjà disponible. - Import de disque (
qm disk import) : on recrée la machine à la main et on importe ses disques. - Disque partagé puis déplacement : la machine démarre sur Proxmox VE à partir d'un partage réseau, et son disque est déplacé à chaud. L'interruption est minimale, mais la machine ne doit jamais tourner des deux côtés à la fois.
- Restauration depuis une sauvegarde, quand votre outil de sauvegarde sait restaurer vers Proxmox VE.
Les pièges qui coûtent des heures
Les VMware Tools. Retirez-les avant la migration. Une fois la machine sur Proxmox VE, leur programme de désinstallation sous Windows échoue souvent hors de VMware, et le retrait devient une opération manuelle.
Les pilotes VirtIO sous Windows. Installez-les avant de migrer. Sinon, faites démarrer la machine une première fois avec son disque en SATA, installez les pilotes depuis l'ISO VirtIO, puis basculez le disque système vers VirtIO SCSI.
Le firmware. Une machine qui démarre en BIOS se configure en SeaBIOS, une machine UEFI en OVMF, avec un disque EFI pour conserver ses réglages. Certains systèmes demandent d'ajouter une entrée de démarrage dans l'UEFI.
Le vTPM. Son état ne suit pas. Si la machine utilise BitLocker ou un chiffrement de disque lié au TPM, préparez les clés de récupération, ou suspendez ce chiffrement avant la bascule.
Le réseau. Le nom de la carte réseau change le plus souvent dans l'invité : la configuration IP est à refaire ou à adapter. Vérifiez aussi l'adresse MAC et les réservations DHCP qui en dépendent.
Le type de processeur. « host » donne les meilleures performances si tous les nœuds du cluster ont le même modèle de processeur. Sinon, un modèle générique de la famille « x86-64-v2 / v3 / v4 », choisi selon le plus ancien processeur du cluster, garde la migration à chaud possible entre nœuds.
L'ESXi sous licence gratuite. Il refuse les arrêts pilotés par l'API : la machine source s'éteint alors à la main avant l'import.
La check-list, machine par machine
Avant :
- disques hors vSAN et non chiffrés, snapshots consolidés ;
- VMware Tools retirés, pilotes VirtIO installés (Windows) ;
- configuration réseau, adresse MAC et réservations DHCP notées ;
- clés de récupération BitLocker à portée de main si un vTPM est présent ;
- sauvegarde récente et vérifiée ;
- accord du responsable de l'application et fenêtre de bascule validée.
Pendant :
- machine source arrêtée ;
- disques sur VirtIO SCSI single, avec discard et IO thread ;
- cartes réseau VirtIO, ballooning de la mémoire activé ;
- firmware conforme à celui de la source (SeaBIOS ou OVMF).
Après :
- démarrage vérifié, réseau reconfiguré ;
- agent invité QEMU installé ;
- sauvegarde de la nouvelle machine en place ;
- machine source gardée éteinte quelques jours, comme retour arrière.
Migrer par vagues, pas d'un bloc
Au-delà d'une dizaine de machines, la difficulté n'est plus technique : elle est d'organisation. Quelles machines partent ensemble ? Dans quelle fenêtre ? Combien en parallèle ? Qui valide ? Que fait-on si une bascule se passe mal ?
C'est ce que la fonction Migrations de NaoShift prend en charge, en bêta, ouverte société par société. Une équipe glisse une machine VMware vers sa destination Proxmox VE. L'assistant contrôle chaque machine (niveau de processeur, firmware, Secure Boot, vTPM, chiffrement, place libre, réseau) et lui donne un score d'effort. Les machines liées se regroupent, puis partent en vagues avec leur fenêtre et leur concurrence.
L'import reste natif : c'est Proxmox VE qui lit la machine chez VMware, et aucun disque ne transite par NaoShift. La machine source n'est jamais détruite, et chaque vague garde son retour arrière. Côté sécurité, le principe ne change pas : lecture seule par défaut, écriture activée par cible avec un compte dédié, tracée avant exécution.
Questions fréquentes
Combien de temps prend la migration d'une VM de VMware vers Proxmox VE ?
L'import dépend surtout du volume des disques et du débit entre l'hôte ESXi et Proxmox VE. Comptez aussi la préparation de l'invité (outils, pilotes, réseau), souvent plus longue que la copie elle-même pour une machine Windows.
Peut-on migrer une VM Windows de VMware vers Proxmox VE sans réinstaller ?
Oui. Il faut retirer les VMware Tools, installer les pilotes VirtIO, puis adapter le firmware et le contrôleur de disque. Prévoyez les clés BitLocker si la machine utilise un vTPM, dont l'état ne se migre pas.
Faut-il vCenter pour importer des VM dans Proxmox VE ?
Non. L'assistant de Proxmox VE se connecte de préférence directement à l'hôte ESXi, ce qui est aussi plus rapide que de passer par vCenter.
Pour aller plus loin
Pour savoir si Proxmox VE est la bonne cible, lisez notre comparatif Proxmox VE ou XCP-ng. Le dossier de sortie VMware chiffre un scénario sur votre parc. Pour inventorier vos machines et préparer vos vagues, vous pouvez démarrer gratuitement ou nous écrire.