Migrer des machines virtuelles VMware vers Proxmox VE : import ESXi et virt-v2v

1. Qualifier la VM avant de la convertir

Même discipline que pour toute migration d'hyperviseur : pour chaque VM, notez le système invité et sa version, le type de firmware (BIOS ou UEFI), le nombre et la taille des disques, la chaîne de snapshots, les interfaces réseau avec leurs MAC et IP fixes, et toute licence liée à des identifiants matériels. Proxmox ajoute une question spécifique : quel backend de stockage va héberger les disques (local-lvm, ZFS, ou Ceph RBD si le cluster est hyperconvergé), ce choix conditionnant quelle voie d'import est la plus rapide.

# Inventory with govc (read-only against vCenter or a standalone ESXi host)
export GOVC_URL='https://<VCENTER_OR_ESXI_HOST>' GOVC_USERNAME='<USER>' GOVC_INSECURE=1
govc vm.info -json <VM_NAME> | jq '.virtualMachines[0] | {guest: .config.guestFullName, firmware: .config.firmware, cpu: .config.hardware.numCPU, memMB: .config.hardware.memoryMB}'
govc device.info -vm <VM_NAME> disk-* ethernet-*
govc snapshot.tree -vm <VM_NAME>          # must be empty (or consolidated) before export

# On the Proxmox side: confirm target storage type and free space
pvesm status

2. Voie A : assistant d'import ESXi natif

Les versions récentes de Proxmox VE permettent d'enregistrer un hôte ESXi comme source de stockage et d'importer ses invités directement : les disques sont transférés et convertis à la volée vers le stockage cible choisi, sans export OVA manuel ni zone de transit. C'est la voie la plus rapide pour quelques VM ou un premier pilote, et elle se pilote depuis l'interface web.

2.1 Enregistrer l'hôte ESXi comme source d'import

# Datacenter → Storage → Add → ESXi, or from the CLI on a cluster node
pvesm add esxi esxi-src \
  --server <ESXI_HOST> --username <ESXI_USER> --password <ESXI_PASSWORD> \
  --skip-cert-verification 1

# List the guests Proxmox discovered on that ESXi host
pvesm list esxi-src

2.2 Importer via l'assistant

Ouvrez le nœud cible, sélectionnez le stockage esxi-src, puis Importer pour la VM à migrer. L'assistant permet de choisir le stockage cible (local-lvm, ZFS, Ceph RBD), le format de disque, le bridge de chaque interface réseau et le contrôleur VirtIO SCSI, puis crée la VM et convertit les disques en une seule opération. Pour des imports de masse scriptés sur de nombreuses VM, pilotez la même opération via l'API Proxmox plutôt que de cliquer VM par VM.

3. Voie B : virt-v2v / qemu-img et qm importdisk

virt-v2v n'a pas de sortie dédiée Proxmox : la voie se déroule en deux temps, convertir l'invité en image locale raw ou qcow2 (depuis vCenter directement, ou depuis un export OVA), puis attacher cette image à une coquille de VM Proxmox avec qm importdisk. Cette voie garde chaque artefact intermédiaire sous contrôle, fonctionne sans accès réseau de Proxmox vers vCenter, et se scripte proprement pour des migrations de masse.

3.1 Convertir l'invité avec virt-v2v

# Install virt-v2v and guestfs tools on a Linux conversion host (Debian/Ubuntu)
apt-get install virt-v2v libguestfs-tools -y

# Windows guests: virt-v2v needs the virtio-win drivers (ISO from the Fedora virtio-win project)
export VIRTIO_WIN=/opt/virtio-win.iso

# Power off the source VM first, then convert to a local raw image (-o local)
export LIBGUESTFS_BACKEND=direct
mkdir -p /tmp/converted
virt-v2v -ic 'vpx://<VCENTER_USER>@<VCENTER_HOST>/<DATACENTER>/<ESXI_HOST>' \
  -ip /root/vcenter-password <VM_NAME> \
  -o local -os /tmp/converted/ -of raw

# Output is named <VM_NAME>-sda, -sdb, and so on in /tmp/converted/

3.2 Créer la coquille de VM et importer les disques

# Create an empty VM with the target hardware profile
qm create 9001 --name <VM_NAME>_migrated --memory 8192 --cores 4 --sockets 1 \
  --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-single --ostype l26

# Import each converted disk into the chosen storage (returns the new volume as unused disk)
qm importdisk 9001 /tmp/converted/<VM_NAME>-sda local-lvm --format qcow2
qm importdisk 9001 /tmp/converted/<VM_NAME>-sdb local-lvm --format qcow2

# Attach the imported disk and set the boot order
qm set 9001 --scsi0 local-lvm:vm-9001-disk-0
qm set 9001 --scsi1 local-lvm:vm-9001-disk-1
qm set 9001 --boot order=scsi0
qm set 9001 --agent enabled=1

3.3 Gros disques : flux direct vers Ceph RBD

# Skip local staging for multi-terabyte disks: convert directly into the Ceph pool
qemu-img convert -p -f raw -O raw /tmp/converted/<VM_NAME>-sda rbd:<CEPH_POOL>/vm-9001-disk-0

# Then attach the existing RBD image to the VM
qm set 9001 --scsi0 <CEPH_STORAGE_ID>:vm-9001-disk-0

4. Quelle voie pour quel parc

5. Les pièges neutralisés avant qu'ils ne surviennent

• ■Pilotes VirtIO Windows : sans pilotes de stockage VirtIO injectés avant le premier démarrage, les invités Windows plantent ou font un écran bleu au boot. virt-v2v les injecte automatiquement ; via l'assistant d'import ESXi, injectez les pilotes virtio-win avant de basculer le contrôleur du disque de boot vers VirtIO.
• ■Le QEMU Guest Agent n'est pas installé automatiquement : cocher la case QEMU Agent dans l'onglet Options de la VM indique seulement à Proxmox de s'attendre à sa présence. Il faut installer qemu-guest-agent à l'intérieur de l'invité soi-même et démarrer le service, sinon Proxmox continue de ne remonter aucune adresse IP et ne peut pas demander un arrêt propre de l'invité.
• ■UEFI ou BIOS : un invité UEFI démarré avec le SeaBIOS par défaut échoue. Configurez bios: ovmf et ajoutez un efidisk0 sur le stockage cible avant le premier démarrage ; inventoriez le type de firmware par VM en amont.
• ■Contrôleur SCSI et modèle réseau : une VM créée avec le contrôleur LSI par défaut et une carte e1000 démarre mais perd l'essentiel du gain de performance. Utilisez virtio-scsi-single pour le contrôleur et virtio pour l'interface réseau une fois les pilotes invités en place.
• ■Conservation des IP et MAC : licences applicatives, règles de pare-feu et configurations en dur dépendent des adresses. Fixez explicitement le macaddr de net0 et conservez la configuration IP statique de l'invité quand la continuité l'exige.
• ■Snapshots et chaînes CBT : des chaînes de snapshots non consolidées corrompent ou alourdissent aussi bien l'import ESXi que l'export OVA. Consolidez les snapshots et suspendez les intégrations de sauvegarde avant toute sortie de disque de vSphere.

6. Recette et retour arrière

La VM source reste éteinte mais intacte sur vSphere jusqu'à la signature de la recette. Le retour arrière est un runbook documenté et testé : rallumer la source, rebrancher les flux, journaliser l'écart et le réinjecter dans la matrice d'éligibilité. Ce n'est qu'ensuite que la VM vSphere est supprimée et son stockage récupéré.

# Post-migration checks on the Proxmox side
qm status 9001
qm config 9001
qm terminal 9001            # serial console; or use the noVNC console from the web UI

# Rollback (vSphere side): the source VM was never deleted
govc vm.power -on <VM_NAME>