Migrer une machine virtuelle VMware ESXi vers Proxmox VE ne consiste pas seulement à convertir un fichier VMDK. Il faut préserver la cohérence applicative, préparer les pilotes invités, recréer la topologie réseau et valider le démarrage sur un matériel virtuel différent. Ce guide décrit une méthode reproductible, adaptée à une migration ponctuelle comme à une série de bascules planifiées.

La procédure ci-dessous vise principalement les VM Windows et Linux exécutées sur ESXi, avec import dans Proxmox VE via qm importdisk. Elle privilégie une fenêtre d’arrêt contrôlée afin d’éviter tout écart de données entre le disque source et la VM migrée.

Préparer la migration et inventorier la VM source

Avant toute conversion, relevez la configuration complète de la VM dans vSphere ou directement sur l’hôte ESXi :

Arrêtez proprement la VM avant la copie finale. Pour une migration avec indisponibilité maîtrisée, la séquence recommandée est la suivante :

  1. Réaliser une première copie des fichiers VMDK pendant que la VM fonctionne, si le volume est important.
  2. Planifier la bascule.
  3. Arrêter les services applicatifs.
  4. Arrêter le système invité.
  5. Copier une dernière fois les disques VMDK.
  6. Convertir, importer et démarrer dans Proxmox VE.

Sur ESXi, les disques sont généralement stockés dans un datastore. Une copie via SSH peut suffire pour une VM modeste, mais évitez de copier un VMDK alors que des snapshots VMware sont actifs ou que la VM continue à écrire dessus.

Exemple de copie depuis un hôte Proxmox vers ESXi :

mkdir -p /var/lib/vz/import/esxi-vm01
scp root@esxi01:/vmfs/volumes/datastore1/VM01/VM01.vmdk \
  /var/lib/vz/import/esxi-vm01/

Dans la pratique, il est souvent plus fiable de lancer la copie depuis ESXi vers un partage NFS, SMB ou un serveur intermédiaire, puis de transférer les fichiers vers le nœud Proxmox.

Vérifiez également la nature du VMDK. Un disque VMware peut être composé de plusieurs fichiers, notamment un petit fichier descripteur et un fichier de données -flat.vmdk. Le fichier descripteur est celui qu’il faut fournir aux outils de conversion.

ls -lh /var/lib/vz/import/esxi-vm01/

Exemple de résultat attendu :

VM01.vmdk
VM01-flat.vmdk

Ne convertissez pas directement le fichier VM01-flat.vmdk si le fichier VM01.vmdk existe : le descripteur contient les informations de géométrie et de format nécessaires.

Préparer les systèmes invités, surtout Windows

Le principal échec de démarrage après migration concerne Windows qui ne dispose pas du pilote du contrôleur de stockage VirtIO. Si vous importez le disque puis attachez immédiatement celui-ci en VirtIO Block ou VirtIO SCSI, Windows peut afficher un écran bleu INACCESSIBLE_BOOT_DEVICE.

La solution la plus sûre consiste à installer les pilotes VirtIO avant l’arrêt de la VM source. Téléchargez l’ISO virtio-win depuis le dépôt Fedora VirtIO, montez-la dans la VM VMware et installez au minimum : Pour aller plus loin, consultez l’état de l’art de Proxmox VE.

Pour Windows Server, l’installation peut être réalisée via le gestionnaire de périphériques ou depuis l’invite de commande élevée. Exemple d’installation forcée des pilotes depuis le média VirtIO monté en D: :

pnputil /add-driver D:\vioscsi\2k22\amd64\vioscsi.inf /install
pnputil /add-driver D:\NetKVM\2k22\amd64\netkvm.inf /install

Adaptez le chemin au système concerné : 2k19, 2k22, w10, w11, etc. Vérifiez ensuite dans le gestionnaire de périphériques que les pilotes sont présents dans le magasin de pilotes Windows.

Pour les distributions Linux courantes, les pilotes VirtIO sont généralement inclus dans le noyau. Vérifiez néanmoins que l’initramfs contient les modules requis :

La conversion d'une VM VMware vers Proxmox suit un processus balisé.
La conversion d'une VM VMware vers Proxmox suit un processus balisé.
lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'virtio|virtio_blk|virtio_scsi'

Sur Debian ou Ubuntu, regénérez l’initramfs si nécessaire :

update-initramfs -u -k all

Sur les systèmes utilisant LVM, UUID, multipath ou des règles udev spécifiques, documentez les dépendances avant migration. Un changement d’interface réseau ou de chemin de disque peut modifier certains identifiants visibles par le système.

Créer la VM cible dans Proxmox VE

Créez d’abord une VM vide dans Proxmox VE. Le numéro d’identifiant utilisé dans cet exemple est 101, le stockage cible est local-lvm, et le bridge réseau est vmbr0.

Pour une VM Linux utilisant le firmware BIOS et un disque importé en SCSI VirtIO :

qm create 101 \
  --name vm01-migree \
  --memory 8192 \
  --cores 4 \
  --cpu host \
  --scsihw virtio-scsi-single \
  --net0 virtio,bridge=vmbr0 \
  --ostype l26

Pour une VM Windows récente utilisant UEFI, ajoutez une partition EFI et choisissez la machine Q35 :

qm create 101 \
  --name win01-migree \
  --memory 8192 \
  --cores 4 \
  --cpu host \
  --machine q35 \
  --bios ovmf \
  --efidisk0 local-lvm:0,efitype=4m,pre-enrolled-keys=1 \
  --scsihw virtio-scsi-single \
  --net0 virtio,bridge=vmbr0 \
  --ostype win11

Le firmware doit correspondre à celui de la VM VMware. Une VM installée en BIOS hérité ne démarrera pas automatiquement en UEFI, et inversement. Si vous ne connaissez pas le type de firmware d’origine, vérifiez les paramètres de la VM dans vSphere avant la création.

Pour réduire les risques sur une migration Windows, vous pouvez démarrer une première fois avec un contrôleur SATA ou avec une interface disque émulée plus universelle, puis basculer vers VirtIO après validation. Cela a toutefois un coût de performance et ne remplace pas l’installation préalable des pilotes.

Convertir et importer les disques VMDK

Deux approches sont pertinentes :

La première est généralement la plus simple. La seconde est utile lorsque vous voulez inspecter le disque, imposer un format ou transférer un fichier déjà converti.

Import direct avec qm importdisk

La syntaxe de base est :

qm importdisk <VMID> <source-vmdk> <storage> --format <raw|qcow2>

Exemple d’import au format raw vers un stockage LVM-thin :

qm importdisk 101 \
  /var/lib/vz/import/esxi-vm01/VM01.vmdk \
  local-lvm \
  --format raw

Le format raw est généralement recommandé sur local-lvm, ZFS, Ceph RBD ou tout stockage bloc gérant déjà ses propres mécanismes de snapshots et de thin provisioning.

Après l’import, vérifiez la configuration :

qm config 101

Vous verrez typiquement un disque non utilisé :

unused0: local-lvm:vm-101-disk-0

Attachez-le ensuite au contrôleur SCSI VirtIO :

qm set 101 \
  --scsihw virtio-scsi-single \
  --scsi0 local-lvm:vm-101-disk-0 \
  --boot order=scsi0

Pour un disque système Windows dont le pilote VirtIO n’a pas été préparé, utilisez provisoirement SATA :

qm set 101 \
  --sata0 local-lvm:vm-101-disk-0 \
  --boot order=sata0

Une fois Windows démarré, installez le pilote VirtIO, éteignez la VM, puis rattachez le disque en SCSI VirtIO. Faites cette manipulation dans une fenêtre de maintenance : le nom de périphérique et l’ordre de boot changent.

Pour un stockage de type répertoire, par exemple local, importez plutôt au format qcow2 :

qm importdisk 101 \
  /var/lib/vz/import/esxi-vm01/VM01.vmdk \
  local \
  --format qcow2

Le format qcow2 est utile pour les snapshots QEMU sur stockage fichier. Il ajoute cependant une couche de métadonnées et peut être moins performant qu’un volume raw dans certains scénarios intensifs en I/O. Pour aller plus loin, consultez notre dossier sur les alternatives à VMware.

Conversion avec qemu-img convert

Avant une conversion, inspectez le disque :

qemu-img info /var/lib/vz/import/esxi-vm01/VM01.vmdk

Conversion VMDK vers qcow2 :

qemu-img convert -p -f vmdk -O qcow2 \
  /var/lib/vz/import/esxi-vm01/VM01.vmdk \
  /var/lib/vz/import/esxi-vm01/VM01.qcow2

Conversion VMDK vers raw :

qemu-img convert -p -f vmdk -O raw \
  /var/lib/vz/import/esxi-vm01/VM01.vmdk \
  /var/lib/vz/import/esxi-vm01/VM01.raw

L’option -p affiche la progression. L’option -f vmdk force le format source et évite une détection ambiguë. Après conversion, vérifiez le fichier produit :

qemu-img info /var/lib/vz/import/esxi-vm01/VM01.qcow2

Importez ensuite le résultat :

qm importdisk 101 \
  /var/lib/vz/import/esxi-vm01/VM01.qcow2 \
  local \
  --format qcow2

Ou, pour un fichier raw importé dans local-lvm :

qm importdisk 101 \
  /var/lib/vz/import/esxi-vm01/VM01.raw \
  local-lvm \
  --format raw

Pour une VM possédant plusieurs disques, répétez l’opération pour chaque VMDK et respectez l’ordre logique des volumes. Par exemple, si scsi0 correspond au système et scsi1 aux données :

Chaque étape de migration doit être vérifiée avant la suivante.
Chaque étape de migration doit être vérifiée avant la suivante.
qm set 101 --scsi0 local-lvm:vm-101-disk-0
qm set 101 --scsi1 local-lvm:vm-101-disk-1
qm set 101 --boot order=scsi0

Reproduire la connectivité réseau sans créer de conflit

La configuration réseau VMware ne migre pas automatiquement. Dans Proxmox VE, il faut associer la carte virtuelle à un bridge, puis reproduire le VLAN si nécessaire.

Exemple de carte VirtIO connectée au bridge vmbr0 avec VLAN 120 :

qm set 101 --net0 virtio,bridge=vmbr0,tag=120

Si le bridge Proxmox transporte les VLAN en trunk, vérifiez que celui-ci est configuré avec vlan-aware yes dans 0 :

auto vmbr0
iface vmbr0 inet static
    address 192.0.2.10/24
    gateway 192.0.2.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes

Dans le système invité, l’interface réseau sera probablement détectée comme une nouvelle carte. Sous Windows, cela peut créer une interface Ethernet supplémentaire et laisser l’ancienne configuration IP attachée à une carte VMware fantôme. Sous Linux, le nom de l’interface peut changer, par exemple de ens192 à ens18.

Ne reconnectez pas immédiatement la VM migrée au réseau de production si l’ancienne VM est encore active. Vous éviteriez les conflits d’adresse IP, d’ARP, de nom DNS ou de service applicatif.

Une méthode prudente consiste à utiliser temporairement un VLAN isolé ou à déconnecter l’interface :

qm set 101 --net0 virtio,bridge=vmbr0,link_down=1

Après un premier démarrage et les contrôles locaux, réactivez l’interface :

qm set 101 --net0 virtio,bridge=vmbr0,tag=120,link_down=0

Si l’adresse MAC est référencée dans des réservations DHCP ou des listes de contrôle d’accès, vous pouvez définir une MAC précise :

qm set 101 --net0 virtio=BC:24:11:AA:BB:CC,bridge=vmbr0,tag=120

Démarrer, vérifier et finaliser la bascule

Avant le premier démarrage, ajoutez le média VirtIO à la VM Windows si les pilotes doivent encore être installés :

qm set 101 --ide2 local:iso/virtio-win.iso,media=cdrom

Activez également l’agent invité QEMU lorsque celui-ci est installé dans l’OS :

qm set 101 --agent enabled=1

Démarrez la VM :

qm start 101

Suivez la console depuis l’interface Proxmox VE ou ouvrez une console série si elle a été configurée. Après démarrage, réalisez au minimum les vérifications suivantes :

Sous Linux :

ip addr
ip route
lsblk
systemctl --failed
journalctl -p err -b

Sous Windows PowerShell :

Get-NetAdapter
Get-NetIPAddress
Get-Service | Where-Object {$_.Status -ne 'Running'}
Get-WinEvent -LogName System -MaxEvents 100

Une fois la VM validée, installez ou mettez à jour les composants spécifiques à Proxmox :

Ne supprimez pas immédiatement la VM source dans ESXi. Conservez-la arrêtée pendant une période définie par votre procédure de changement, idéalement jusqu’à la validation fonctionnelle par les équipes applicatives et après une sauvegarde réussie sur la plateforme Proxmox.

Prévoir un rollback réaliste

Le rollback le plus simple est organisationnel : l’ancienne VM ESXi reste intacte et arrêtée. En cas d’échec de démarrage, d’erreur applicative ou de performance non acceptable, inversez la bascule en évitant toute exécution simultanée des deux instances sur le même réseau. Pour aller plus loin, consultez vCenter contre l’interface native Proxmox.

Plan de rollback recommandé :

  1. Arrêter la VM migrée dans Proxmox VE.
  2. Vérifier qu’elle n’écrit plus sur des services partagés.
  3. Désactiver ou isoler son interface réseau.
  4. Démarrer la VM source dans ESXi.
  5. Vérifier la reprise des services, du réseau et des traitements.
  6. Documenter précisément le point d’échec avant toute nouvelle tentative.

Commandes Proxmox associées :

qm shutdown 101 --timeout 120
qm stop 101
qm set 101 --net0 virtio,bridge=vmbr0,link_down=1

Le rollback devient plus complexe dès que la VM migrée accepte des écritures en production, notamment pour une base de données. Dans ce cas, redémarrer simplement la VM ESXi d’origine peut provoquer une perte des transactions réalisées après la bascule. Pour les charges critiques, prévoyez une stratégie applicative : arrêt des écritures, réplication native, sauvegarde transactionnelle ou mécanisme de haute disponibilité adapté.

La conversion de disque n’est donc qu’une partie de l’opération. La réussite dépend surtout de la préparation des pilotes, de la reproduction contrôlée du réseau, de la validation applicative et du maintien d’une source de retour arrière utilisable jusqu’à la fin de la recette.