Conversion V2V ESXi vers Proxmox : méthodes recommandées et pièges

Faits intéressants et petite histoire (pour comprendre les décisions)

• L’OVF a été conçu pour la portabilité, pas pour la perfection. C’est une norme de paquetage (descripteur + disques), mais les fournisseurs aiment les « extensions », et c’est là que la portabilité meurt.
• Le VMDK précède la pensée moderne du « cloud ». Il a grandi dans un monde de disques épais soutenus par des SAN, donc les cas limites thin-provisioned sont souvent « ça marche jusqu’à ce que ça ne marche plus ».
• KVM est devenu un module du noyau Linux en 2007. Ce changement (virtualisation assistée matériel dans le noyau) explique pourquoi Proxmox n’est pas un projet expérimental.
• Virtio est un contrat de performance. Ce n’est pas juste « un pilote », c’est une interface paravirtualisée qui échange compatibilité contre vitesse — excellente une fois les pilotes disponibles, douloureuse avant.
• QCOW2 a été conçu pour les snapshots et la flexibilité. RAW est ultra-rapide ; QCOW2 est pratique opérationnellement. Choisissez selon le backend de stockage et les habitudes d’exploitation.
• Les snapshots VMware n’ont jamais été des sauvegardes. Ce sont des journaux de redirection ; les laisser s’accumuler crée une machine à latence qui finit par manquer d’espace.
• UEFI vs BIOS est une ligne de faille à l’ère des migrations. Beaucoup de VM plus anciennes sont BIOS/MBR ; les templates modernes sont UEFI/GPT. Convertir les disques est plus simple que convertir les hypothèses de démarrage.
• Les outils VMware cachent une certaine complexité d’identité des périphériques. Quand vous passez à KVM, les MAC, les modèles de NIC et les contrôleurs de stockage redeviennent importants.
• « qm importdisk » de Proxmox est opinionné. Il veut attacher les disques importés à une configuration VM et une cible de stockage ; ce n’est pas un convertisseur générique, c’est un outil de flux de travail.

Une idée paraphrasée de Gene Kim qui tient dans chaque migration : Améliorez le système de travail, pas les actes héroïques ; la fiabilité vient d’un flux reproductible. (idée paraphrasée)

Choisir votre méthode : OVF/OVA vs qemu-img vs Clonezilla

Ma règle de décision orientée

• Si vous pouvez arrêter la VM et accéder aux VMDK : utilisez qemu-img + import Proxmox. Vous obtiendrez du contrôle, des résultats prévisibles et moins de couches « magiques ».
• Si vous avez besoin d’un artefact portable façon fournisseur ou que vous êtes bloqué par des workflows vCenter : utilisez OVF/OVA, mais traitez-le comme un moyen de paquetage, pas une garantie.
• Si la VM est une appliance avec des chargeurs d’amorçage bizarres ou si vous ne faites pas confiance aux formats de disque : utilisez Clonezilla et clonez au niveau système de fichiers/bloc.

Compromis importants en production

• Temps d’arrêt : les trois méthodes préfèrent un arrêt. Des conversions en live existent ; elles sont aussi l’occasion d’apprendre de nouveaux sens du mot « incohérent ».
• Fidélité : Clonezilla peut offrir la plus grande fidélité pour « ce qui se trouve sur le disque », mais il est aveugle aux sémantiques de virtualisation (contrôleurs, type de NIC). OVF peut préserver plus de métadonnées, parfois.
• Vitesse : qemu-img vers RAW sur stockage local rapide est généralement le plus rapide. Les exportations OVF peuvent être lentes car elles reconditionnent et parfois compressent.
• Débogabilité : qemu-img et les fichiers raw sont faciles à inspecter. OVA est un tar avec un descripteur — correct, mais encore un emballage quand vous êtes déjà stressé.

Blague n°1 : La V2V c’est comme déménager d’appartement — faire les cartons est facile, trouver la boîte avec la cafetière est la véritable panne.

Pré-vol : inventaire, arrêt et décisions de conception

Ce que vous devez décider avant de toucher un seul disque

• Mode de démarrage : BIOS ou UEFI sur la VM de destination. Faites correspondre la source sauf si vous aimez l’archéologie du chargeur d’amorçage.
• Bus disque : VirtIO SCSI est généralement le bon choix sur Proxmox. SATA est le parachute de compatibilité. IDE, c’est pour les musées.
• Modèle de NIC : VirtIO pour la performance ; E1000 si vous avez besoin que « ça démarre sans pilotes ».
• Backend de stockage : ZFS, LVM-thin ou Ceph. Cela change si RAW vs QCOW2 est pertinent et modifie l’ajustement des performances.
• Mise en réseau : noms de bridge, marquage VLAN, MTU et si un changement de MAC déclenchera des licences ou des réservations DHCP.
• Plan de retour en arrière : gardez la VM ESXi arrêtée mais intacte jusqu’à ce que la VM Proxmox survive au moins un redémarrage et un cycle de sauvegarde.

Tâches pré-vol (avec commandes, sorties et décisions)

Task 1: Confirm Proxmox node virtualization support

cr0x@pve1:~$ egrep -m1 -o 'vmx|svm' /proc/cpuinfo
vmx

Ce que cela signifie : vmx (Intel VT-x) ou svm (AMD-V) doit être présent.

Décision : Si manquant, stoppez. Vous ne pouvez pas faire KVM correctement ; vous aurez l’émulation QEMU TCG et la tristesse associée.

Task 2: Check Proxmox storage types and free space

cr0x@pve1:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        196473240        5123456       185678912        2.61%
local-zfs         zfspool active       1889785616      934281216       955504400       49.44%

Ce que cela signifie : Vous avez un stockage de type répertoire (local) et un pool ZFS (local-zfs) avec environ 955 Go libres.

Décision : Choisissez la cible. Pour ZFS, RAW convient car ZFS gère déjà le copy-on-write et les snapshots.

Task 3: Inventory source VM hardware in ESXi (from exported config)

cr0x@jump:~$ grep -E 'firmware|scsi|ethernet|nvram|virtualHW' vm1/vm1.vmx
virtualHW.version = "14"
firmware = "efi"
scsi0.virtualDev = "pvscsi"
ethernet0.virtualDev = "vmxnet3"
nvram = "vm1.nvram"

Ce que cela signifie : Firmware UEFI, contrôleur PVSCSI, NIC vmxnet3.

Décision : Sur Proxmox, prévoyez OVMF pour l’UEFI et VirtIO SCSI + VirtIO net (ou E1000 temporairement pour Windows si les pilotes ne sont pas prêts).

Task 4: Detect ESXi snapshots before exporting

cr0x@esxi1:~$ vim-cmd vmsvc/getallvms | grep -i vm1
12   vm1   [datastore1] vm1/vm1.vmx   ubuntu64Guest   vmx-14

cr0x@esxi1:~$ vim-cmd vmsvc/snapshot.get 12
Get Snapshot:
|--ROOT
   |--Snapshot Name        : pre-upgrade
   |--Snapshot Id          : 1
   |--Snapshot Created On  : 2025-12-01
   |--Snapshot State       : powered off

Ce que cela signifie : Des snapshots existent. Les exports peuvent capturer des chaînes delta ou consolider implicitement.

Décision : Consolidez les snapshots avant conversion à moins d’avoir une raison très spécifique de ne pas le faire.

Task 5: Confirm VM is shut down (consistency over heroics)

cr0x@esxi1:~$ vim-cmd vmsvc/power.getstate 12
Retrieved runtime info
Powered off

Ce que cela signifie : Éteinte. C’est l’état propre souhaité pour une conversion au niveau disque.

Décision : Procédez. Si elle est allumée, planifiez une fenêtre d’indisponibilité ou utilisez la quiescence au niveau invité et acceptez plus de risque.

Méthode 1 : export OVF/OVA + import Proxmox

Quand OVF/OVA est la bonne option

• Vous disposez de workflows vCenter et d’auditeurs qui veulent « un artefact d’export ».
• Vous déplacez un petit nombre de VM et la commodité compte plus que la vitesse maximale.
• Vous voulez un seul fichier (OVA) que vous pouvez archiver, hasher et remettre à une autre équipe.

Où OVF/OVA pose problème

• Les métadonnées NIC/contrôleur ne se mappent pas proprement aux périphériques KVM.
• Certaines exportations produisent des VMDK « streamOptimized », valides mais qui ajoutent une étape de conversion.
• Les descripteurs OVF peuvent inclure des sections spécifiques à VMware ; Proxmox en ignore la plupart.

Tâches pratiques OVF/OVA

Task 6: Inspect an OVA before you trust it

cr0x@pve1:~$ tar -tf vm1.ova | head
vm1.ovf
vm1.mf
vm1-disk1.vmdk

Ce que cela signifie : L’OVA est un tar contenant un descripteur OVF, un manifeste et un disque.

Décision : Si des disques manquent ou si vous voyez plusieurs disques inattendus, arrêtez et vérifiez la disposition de la VM source.

Task 7: Validate the OVF manifest checksums

cr0x@pve1:~$ sha1sum -c vm1.mf
vm1.ovf: OK
vm1-disk1.vmdk: OK

Ce que cela signifie : Les contrôles d’intégrité passent. Si ça échoue, n’« essayez pas quand même ». Réexportez ou retransférez.

Décision : Procédez seulement quand les checksums sont OK ; la corruption ici vous fera perdre des heures plus tard.

Task 8: Create an empty VM shell in Proxmox that matches boot mode

cr0x@pve1:~$ qm create 120 --name vm1 --memory 8192 --cores 4 --machine q35 --bios ovmf --net0 virtio,bridge=vmbr0
create VM 120: success

Ce que cela signifie : La VM 120 existe, firmware UEFI, VirtIO net.

Décision : Si la source était BIOS, utilisez --bios seabios à la place. Ne « mettez pas à niveau » le firmware durant la migration à moins que ce soit planifié.

Task 9: Convert the OVA VMDK to RAW or QCOW2 and import

cr0x@pve1:~$ qemu-img info vm1-disk1.vmdk
image: vm1-disk1.vmdk
file format: vmdk
virtual size: 80G (85899345920 bytes)
disk size: 22G
cluster_size: 65536
Format specific information:
    cid: 2155942229
    parent cid: 4294967295
    create type: streamOptimized

cr0x@pve1:~$ qemu-img convert -p -f vmdk -O raw vm1-disk1.vmdk /var/lib/vz/images/120/vm-120-disk-0.raw
    (progress output omitted)

Ce que cela signifie : C’est un VMDK streamOptimized. La conversion est requise ; Proxmox ne peut pas « l’exécuter » directement.

Décision : Utilisez RAW pour les backends ZFS/LVM-thin sauf si vous voulez explicitement les fonctionnalités QCOW2 sur un stockage de type dir.

Task 10: Attach the imported disk and set boot order

cr0x@pve1:~$ qm set 120 --scsihw virtio-scsi-pci --scsi0 local-zfs:vm-120-disk-0
update VM 120: -scsihw virtio-scsi-pci -scsi0 local-zfs:vm-120-disk-0

cr0x@pve1:~$ qm set 120 --boot order=scsi0
update VM 120: -boot order=scsi0

Ce que cela signifie : Disque attaché en VirtIO SCSI et utilisé comme périphérique de démarrage.

Décision : Si Windows ne démarre pas, attachez temporairement en SATA et corrigez les pilotes, puis repassez en arrière.

Méthode 2 : VMDK → QCOW2/RAW avec qemu-img (ma valeur par défaut)

Pourquoi cette méthode gagne la plupart du temps

Si vous pouvez récupérer le(s) VMDK(s) depuis le datastore (ou y accéder via NFS/SSH depuis un shell ESXi), qemu-img vous donne
de la déterminisme. Vous contrôlez les formats, vous pouvez inspecter la chaîne, choisir des cibles sparses ou entièrement allouées, et exécuter la
conversion sur le nœud Proxmox juste à côté du stockage de destination.

Les deux conversions que vous voulez réellement

• VMDK → RAW : idéal quand le stockage cible gère déjà les snapshots/COW (ZFS, Ceph RBD). Rapide, simple, moins de couches.
• VMDK → QCOW2 : utile sur un stockage en répertoire quand vous voulez des snapshots au niveau VM (et acceptez l’overhead), ou pour la portabilité.

Tâches pratiques qemu-img

Task 11: Confirm the VMDK isn’t a snapshot chain you forgot about

cr0x@pve1:~$ qemu-img info -U vm1-flat.vmdk
image: vm1-flat.vmdk
file format: raw
virtual size: 80G (85899345920 bytes)
disk size: 80G

Ce que cela signifie : Celui-ci est un extent « flat » raw, pas une chaîne delta. C’est ce que vous voulez.

Décision : Si vous voyez une relation parent/enfant (backing file), arrêtez et consolidez sur ESXi d’abord.

Task 12: Convert with progress and reasonable defaults

cr0x@pve1:~$ qemu-img convert -p -f vmdk -O raw vm1.vmdk /tank/images/120/vm-120-disk-0.raw
    (progress output omitted)

Ce que cela signifie : La conversion disque s’exécute. Le temps dépend de la taille du disque, des blocs réellement utilisés et de la vitesse du stockage.

Décision : Si la conversion est lente, ne devinez pas. Utilisez le playbook de diagnostic rapide ci-dessous pour identifier si vous êtes limité par le CPU, le réseau ou le disque.

Task 13: Import disk into Proxmox storage properly (qm importdisk)

cr0x@pve1:~$ qm importdisk 120 /tank/images/120/vm-120-disk-0.raw local-zfs
importing disk '/tank/images/120/vm-120-disk-0.raw' to VM 120 ...
transferred 0.0 B of 80.0 GiB (0.00%)
transferred 80.0 GiB of 80.0 GiB (100.00%)
Successfully imported disk as 'local-zfs:vm-120-disk-0'

Ce que cela signifie : Proxmox a importé le disque dans le stockage cible et créé une référence de volume.

Décision : Préférez qm importdisk quand c’est possible ; cela garde la tenue de compte du stockage propre.

Task 14: Confirm the VM config references the right disk and controller

cr0x@pve1:~$ qm config 120
bios: ovmf
boot: order=scsi0
cores: 4
memory: 8192
name: vm1
net0: virtio=DE:AD:BE:EF:12:20,bridge=vmbr0
scsi0: local-zfs:vm-120-disk-0
scsihw: virtio-scsi-pci

Ce que cela signifie : Le disque est sur scsi0 avec VirtIO SCSI. L’UEFI est activé.

Décision : Si le disque de démarrage n’est pas sur le contrôleur attendu, corrigez-le maintenant avant le premier démarrage.

Méthode 3 : Clonezilla (quand vous avez besoin de « simple mais fiable »)

Quand Clonezilla est l’outil adapté

• VM appliance avec partitionnement étrange, chargeurs d’amorçage personnalisés ou noyaux fournisseur que vous ne voulez pas toucher.
• Situations où les formats de disque sont désordonnés (chaînes de snapshots, exports streamOptimized, variantes VMDK inconnues).
• Quand vous devez migrer entre mises en page de stockage entièrement différentes et préférez des copies de blocs utilisés au niveau fichier.

Ce que Clonezilla ne fera pas pour vous

• Il ne réparera pas les pilotes VirtIO sous Windows.
• Il ne fera pas la correspondance du modèle de NIC VMware aux sémantiques Proxmox.
• Il ne fera pas correspondre votre mode de démarrage ; vous devez toujours configurer BIOS/UEFI correctement.

Tâches pratiques Clonezilla (et l’angle opérationnel)

Task 15: Create the destination VM with conservative devices for first boot

cr0x@pve1:~$ qm create 130 --name vm1-clone --memory 8192 --cores 4 --machine q35 --bios seabios --net0 e1000,bridge=vmbr0 --sata0 local-zfs:80
create VM 130: success

Ce que cela signifie : Une VM BIOS avec une NIC E1000 et un disque SATA. Des valeurs par défaut conservatrices et compatibles.

Décision : Utilisez ceci si vous n’êtes pas sûr des pilotes invités. Une fois stable, passez à VirtIO pour la performance.

Task 16: Confirm the new disk exists and is the right size before cloning

cr0x@pve1:~$ lsblk -o NAME,SIZE,TYPE,MODEL | grep -E 'zd|sd'
sda   447.1G disk  Samsung_SSD
zd0    80G   disk

Ce que cela signifie : Proxmox a créé un disque virtuel (un zvol ZFS apparaît comme zd0).

Décision : Si la taille est incorrecte, supprimez et recréez. Cloner dans une mauvaise taille est une excellente façon de rencontrer votre futur vous d’astreinte.

Avec Clonezilla, vous démarrez typiquement source et destination de manière contrôlée (boot ISO, partage réseau pour images, etc.).
Les commandes sont moins du type « tapez ceci » et plus « choisissez cet élément de menu », donc la tâche opérationnelle consiste à choisir d’abord du matériel virtuel conservateur.
Une fois que l’invité démarre, vous pouvez itérer sur les périphériques et les pilotes.

Particularités des systèmes invités : Windows, Linux, appliances

Windows : pilotes et démarrage sont tout

Les migrations Windows échouent pour deux raisons : les pilotes du contrôleur de stockage et le mauvais mode de démarrage. Tout le reste est secondaire.
Si votre VM Windows utilisait VMware PVSCSI et vmxnet3, elle n’aura pas automatiquement les pilotes VirtIO de stockage et de réseau installés.
Vous pouvez toujours démarrer si vous choisissez d’abord des périphériques compatibles (SATA + E1000), installez les pilotes VirtIO, puis changez de contrôleurs.

Task 17: Add VirtIO driver ISO and a “safe NIC” for first boot

cr0x@pve1:~$ qm set 120 --ide2 local:iso/virtio-win.iso,media=cdrom
update VM 120: -ide2 local:iso/virtio-win.iso,media=cdrom

cr0x@pve1:~$ qm set 120 --net0 e1000,bridge=vmbr0
update VM 120: -net0 e1000,bridge=vmbr0

Ce que cela signifie : Les pilotes VirtIO sont disponibles pour l’invité ; la NIC est réglée sur E1000 pour la compatibilité.

Décision : Démarrez, installez les pilotes VirtIO, puis basculez net0 de nouveau sur VirtIO.

Task 18: After driver install, switch disk to VirtIO SCSI (maintenance window)

cr0x@pve1:~$ qm set 120 --scsihw virtio-scsi-pci
update VM 120: -scsihw virtio-scsi-pci

Ce que cela signifie : Type de contrôleur défini. Vous devrez peut-être aussi déplacer le disque de SATA vers SCSI dans la config si vous avez utilisé SATA comme pont.

Décision : Changez une classe de périphérique à la fois : d’abord la NIC, puis le stockage. Ne cumulez pas l’incertitude.

Linux : en général ça va, sauf quand ça ne va pas

Les noyaux Linux modernes incluent les pilotes VirtIO. Le mode d’échec courant est un initramfs qui n’inclut pas le bon pilote de stockage si la VM est ancienne,
ou le changement de nom d’interface réseau (noms prévisibles) et votre configuration statique pointe vers une interface inexistante.

Task 19: If Linux boots but networking is dead, confirm link state from Proxmox

cr0x@pve1:~$ qm monitor 120
Enter QEMU Monitor for VM 120 - type 'help' for help
(qemu) info network
hub 0
  netdev net0, peer=(null)
    virtio-net-pci.0: mac=DE:AD:BE:EF:12:20
    link=up
(qemu) quit

Ce que cela signifie : Du point de vue de QEMU, le lien est up. Si l’invité n’a pas de réseau, c’est probablement la configuration à l’intérieur de l’invité.

Décision : Vérifiez les changements udev/noms prévisibles, les configurations IP statiques et les règles de pare-feu à l’intérieur de l’invité.

Appliances : traitez-les comme des boîtes noires

Les appliances fournisseurs verrouillent souvent des modules noyau sur des ID de périphérique spécifiques. La meilleure stratégie est : matériel virtuel conservateur d’abord (SATA, E1000),
démarrez, confirmez les services, puis tentez VirtIO seulement si le fournisseur le prend en charge.

Stockage sur Proxmox : ZFS/LVM-thin/Ceph et pourquoi c’est important

ZFS : excellents choix par défaut, mais coins tranchants

ZFS est fantastique pour Proxmox car les snapshots et la réplication sont natifs, et les scrubs vous disent la vérité sur vos disques.
Mais ZFS est aussi très honest : si vous surallouez la RAM, privez l’ARC ou choisissez un mauvais recordsize/volblocksize pour les zvols, vous le ressentirez.

Task 20: Check ZFS pool health before importing large disks

cr0x@pve1:~$ zpool status -x
all pools are healthy

Ce que cela signifie : Pas d’erreurs connues. Importer sur un pool dégradé transforme la migration en récupération de données.

Décision : Si ce n’est pas sain, réparez le matériel/le pool d’abord.

Task 21: Watch ZFS write amplification symptoms during conversion

cr0x@pve1:~$ zpool iostat -v 2
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        890G   890G     12    420   3.1M   210M
  mirror    890G   890G     12    420   3.1M   210M
    sda        -      -      6    210   1.6M   105M
    sdb        -      -      6    210   1.5M   105M

Ce que cela signifie : Les écritures dominent pendant la conversion. C’est normal ; les conversions sont intensives en écriture.

Décision : Si la bande passante est bien inférieure aux attentes, vous êtes probablement limité par la compression, les paramètres sync ou les disques sous-jacents.

LVM-thin : simple et rapide, moins de fonctionnalités

LVM-thin est simple et performant pour de nombreuses charges. Les snapshots existent mais n’offrent pas la même expérience opérationnelle que ZFS.
Les images RAW sur LVM-thin sont typiques ; QCOW2 ajoute de l’overhead sans offrir beaucoup en retour.

Ceph : excellent à l’échelle, impitoyable quand mal dimensionné

Ceph RBD préfère RAW. De plus, Ceph grossit les petites erreurs : mauvais réseau, mauvais MTU, mauvaises hypothèses de réplication, et votre « migration simple »
devient un séminaire sur la latence du stockage. Si vous migrez vers Ceph, mesurez et validez d’abord.

Blague n°2 : Ceph, c’est comme un travail de groupe — quand ça marche, c’est beau, et quand ça ne marche pas, tout le monde blâme le réseau.

Migration réseau : bridges, VLAN, MAC et pare-feu surprises

Mapping des bridges : vmbr0 n’est pas une constante universelle

Sur ESXi, les port groups abstractisent beaucoup. Sur Proxmox, les bridges Linux et les bridges VLAN-aware sont explicites. C’est une bonne chose. C’est aussi là que les erreurs deviennent visibles.
Une VM peut être « en marche » et pourtant sur la mauvaise île L2.

Task 22: Confirm bridge and VLAN-aware settings on Proxmox

cr0x@pve1:~$ cat /etc/network/interfaces | sed -n '1,120p'
auto lo
iface lo inet loopback

auto enp3s0
iface enp3s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 10.10.10.11/24
        gateway 10.10.10.1
        bridge-ports enp3s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes

Ce que cela signifie : vmbr0 est VLAN-aware. C’est le réglage courant « le faire une fois, le faire bien ».

Décision : Si vous avez besoin de VLAN taggés par VM, gardez VLAN-aware et définissez des tags sur les NIC VM.

Task 23: Confirm VM NIC tag and MAC in config

cr0x@pve1:~$ qm config 120 | grep -E '^net0'
net0: virtio=DE:AD:BE:EF:12:20,bridge=vmbr0,tag=120

Ce que cela signifie : La VM est sur le VLAN 120 via un tag.

Décision : Si l’invité ne peut pas atteindre la passerelle, confirmez le trunking upstream et la présence du VLAN. Ne supposez pas que l’équipe réseau « l’a déjà fait ».

Task 24: See if the host is dropping packets due to firewall

cr0x@pve1:~$ pve-firewall status
Status: enabled/running

cr0x@pve1:~$ pve-firewall localnet
allow 10.0.0.0/8
allow 192.168.0.0/16

Ce que cela signifie : Le pare-feu est activé. Des règles localnet existent ; les règles de trafic VM sont séparées, mais l’état du pare-feu hôte compte pendant le débogage.

Décision : Si vous déboguez la connectivité, désactivez temporairement le pare-feu VM sur la NIC pour isoler les variables, puis réactivez avec les règles correctes.

Playbook de diagnostic rapide (trouver le goulet d’étranglement vite)

Quand une conversion est lente ou que la VM démarre mais fonctionne comme si elle tournait sur un grille-pain, ne commencez pas à « tuner ».
Commencez à mesurer. L’objectif est de décider si vous êtes limité par le disque, le CPU, le réseau ou les pilotes invités.

Première étape : la conversion/le démarrage est-il bloqué par le stockage ?

• Vérifiez la santé ZFS/LVM/Ceph et l’I/O en cours.
• Cherchez de petites écritures aléatoires causées par QCOW2 sur un stockage COW.
• Vérifiez si vous convertissez accidentellement un disque sparse en un disque entièrement alloué sur un stockage lent.

Task 25: Identify storage latency and saturation (host-level)

cr0x@pve1:~$ iostat -xm 2 3
Linux 6.8.12-4-pve (pve1) 	12/28/2025 	_x86_64_	(16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  %util
sda              2.1   210.5    92.4  105432.0   998.3     2.41   11.5   92.3
sdb              2.0   209.8    88.7  105120.4   995.1     2.38   11.3   91.9

Ce que cela signifie : ~92% d’utilisation et ~11ms d’attente. Le stockage est occupé ; la conversion sera limitée par le disque.

Décision : Limitez la concurrence (une conversion à la fois), convertissez d’abord sur NVMe local rapide, ou planifiez pendant les fenêtres de faible I/O.

Deuxième : êtes-vous lié par le CPU durant la conversion (compression, checksums, chiffrement) ?

Task 26: Check CPU saturation during qemu-img convert

cr0x@pve1:~$ mpstat -P ALL 2 2
Linux 6.8.12-4-pve (pve1) 	12/28/2025 	_x86_64_	(16 CPU)

12:02:10 PM  CPU   %usr  %nice  %sys  %iowait  %irq  %soft  %idle
12:02:12 PM  all   42.1   0.0   8.3    18.7    0.0   0.7   30.2

Ce que cela signifie : Iowait significatif ; pas purement lié au CPU. Le CPU a de la marge mais le stockage bride.

Décision : Concentrez-vous sur le chemin de stockage, pas sur le réglage CPU.

Troisième : si la VM tourne mal, est-ce les pilotes (VirtIO) ou la disposition du stockage ?

• Windows sans pilotes VirtIO va traîner sur IDE/SATA et E1000, et vous penserez que Proxmox est lent. Ce n’est pas le cas. Vous l’êtes.
• Linux avec un mauvais ordonnanceur IO ou sans TRIM sur un stockage SSD thin peut se dégrader avec le temps.

Task 27: Confirm the VM is using the intended disk cache and discard settings

cr0x@pve1:~$ qm config 120 | grep -E 'scsi0|sata0|cache|discard|iothread'
scsi0: local-zfs:vm-120-disk-0

Ce que cela signifie : Aucune configuration explicite cache/discard affichée ; les valeurs par défaut s’appliquent.

Décision : Pour un stockage SSD avec thin provisioning, envisagez d’activer discard=on et un IO thread pour les disques lourds après avoir confirmé le support TRIM dans l’invité.

Erreurs courantes : symptômes → cause racine → correction

1) La VM ne démarre pas : « Aucun périphérique amorçable »

Symptôme : La console Proxmox affiche un shell UEFI ou un échec de BIOS au démarrage.

Cause racine : Mismatch BIOS/UEFI (la source était BIOS, la destination est OVMF, ou inversement). Ou l’ordre de démarrage pointe vers le mauvais disque.

Correction : Faites correspondre le firmware à la source. Réglez l’ordre de démarrage correct. Si besoin, ajoutez un disque EFI pour les invités UEFI et vérifiez l’entrée de démarrage.

2) Windows plante tôt (INACCESSIBLE_BOOT_DEVICE)

Symptôme : BSOD Windows juste après le logo de démarrage.

Cause racine : Le contrôleur de stockage a changé pour VirtIO sans pilotes présents.

Correction : Revenez temporairement en SATA, démarrez, installez le pilote de stockage VirtIO depuis l’ISO, puis passez à VirtIO SCSI.

3) La VM démarre mais le réseau est mort

Symptôme : L’invité n’a pas d’IP, ne ping pas la passerelle, ou le DHCP ne répond pas.

Cause racine : Tag VLAN manquant/mauvais, mismatch de bridge, MAC changé et réservations DHCP refusent, ou l’OS invité a renommé l’interface (Linux).

Correction : Confirmez bridge et tag dans qm config. Vérifiez le trunking upstream et la présence du VLAN. Conservez le même MAC si la licence/DHCP l’attend. Corrigez la config réseau de l’invité.

4) La conversion est terriblement lente

Symptôme : qemu-img convert rampe, l’hôte est lent.

Cause racine : Goulet de stockage, conversion en RAW entièrement alloué sur des disques lents, ou I/O concurrente (autres VM, scrub, sauvegardes).

Correction : Exécutez une conversion à la fois ; déplacez la charge de conversion vers un SSD/NVMe local rapide ; évitez QCOW2 sur ZFS si vous n’en avez pas besoin.

5) La VM est rapide un jour, puis les performances se dégradent

Symptôme : La latence augmente, surtout sur des charges écriture-intensives.

Cause racine : Provisionnement thin sans discard/TRIM, snapshots qui s’accumulent, ou cache d’écriture invité interagissant mal avec les paramètres de sync du stockage.

Correction : Activez discard si approprié, maintenez une hygiène des snapshots, et alignez la politique de cache avec votre modèle de durabilité de stockage.

6) Le disque apparaît « plus grand » ou « plus petit » que prévu

Symptôme : L’invité voit une capacité incorrecte ou des erreurs système de fichiers.

Cause racine : Mauvais disque choisi dans une VM multi-disques, conversion d’un delta au lieu de la base, ou tailles de secteur/géométrie incompatibles dans des OS anciens.

Correction : Vérifiez le mapping de chaque VMDK vers chaque disque Proxmox. Consolidez les snapshots. Pour des invités anciens, préférez Clonezilla ou conservez des contrôleurs conservateurs.

7) Le disque importé consomme toute la taille sur ZFS alors qu’il était thin sur ESXi

Symptôme : Un disque thin de 2 To devient une allocation effrayante.

Cause racine : Vous avez converti en RAW d’une manière qui a écrit des blocs zéro auparavant sparses, ou vous avez importé sur un type de stockage qui n’a pas préservé la sparseness comme vous le supposiez.

Correction : Utilisez des conversions conscientes de la sparseness et vérifiez les blocs réellement utilisés. Pour de grands disques sparses, envisagez QCOW2 sur stockage dir ou un import RAW soigneux dans des zvols thin-provisioned.

Listes de vérification / plan étape par étape

Plan A (recommandé) : conversion qemu-img avec changements matériels contrôlés

1. Inventoriez la VM source : firmware (BIOS/UEFI), disques, contrôleurs, type de NIC, snapshots.
2. Consolidez les snapshots : ne migrez pas de chaînes delta sauf si vous aimez l’ambiguïté.
3. Éteignez la VM : la consistance prime sur l’ingéniosité.
4. Copiez les VMDK vers l’hôte de conversion : idéalement le nœud Proxmox ou une machine de staging proche.
5. Inspectez avec qemu-img : confirmez le format et détectez les backing files.
6. Convertissez en RAW (ZFS/Ceph) ou QCOW2 (dir) : choisissez le format selon le backend, pas l’intuition.
7. Créez la VM shell dans Proxmox : faites correspondre le firmware, commencez avec des périphériques compatibles si Windows.
8. Importez le disque : qm importdisk quand possible ; attachez comme bus voulu.
9. Premier démarrage en hardware « safe » : E1000 + SATA si les pilotes sont inconnus.
10. Installez les pilotes VirtIO : puis basculez la NIC en VirtIO, ensuite le disque en VirtIO SCSI.
11. Validation : test de redémarrage, santé des services, vérifications d’application, exécution d’une sauvegarde.
12. Basculement : changements DNS/IP, mise à jour du monitoring, mise hors service seulement après stabilité.

Plan B : OVF/OVA quand vous avez besoin d’un artefact portable

1. Exportez OVA/OVF depuis vCenter/ESXi.
2. Vérifiez les checksums dans le fichier manifeste.
3. Extrayez les disques et inspectez avec qemu-img info.
4. Convertissez en RAW/QCOW2 ; n’essayez pas de « juste attacher » des VMDK streamOptimized.
5. Créez la VM Proxmox avec firmware correspondant, attachez le disque, corrigez périphériques et pilotes.

Plan C : Clonezilla pour appliances et bizarreries

1. Créez la VM de destination avec des périphériques conservateurs (BIOS + SATA + E1000).
2. Démarrez Clonezilla et clonez depuis l’image/partage source vers le disque de destination.
3. Démarrez la destination, validez la santé applicative.
4. Ensuite seulement, tentez d’améliorations VirtIO si supportées.

Trois mini-histoires d’entreprise issues du terrain

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une équipe proche des finances a migré quelques serveurs applicatifs Windows d’ESXi vers Proxmox. Ils ont fait ce qui semblait raisonnable :
convertir les disques, créer les VM et « moderniser » en passant tout en VirtIO immédiatement. Le premier démarrage n’a pas fonctionné, donc ils ont basculé quelques réglages,
réessayé, et ont finalement réussi à démarrer un serveur. Ils ont déclaré victoire et planifié le reste.

La nuit du basculement est arrivée. Trois VM ont bouclé leur démarrage avec INACCESSIBLE_BOOT_DEVICE. Celle qui avait démarré n’avait pas de réseau parce qu’ils avaient aussi basculé les NIC en VirtIO,
et l’OS n’avait pas le pilote. Leur hypothèse était simple : « Windows découvrira les pilotes comme Linux le fait. » Ce n’est pas le cas.

La correction immédiate a été sale mais efficace : revenir le stockage en SATA pour le boot, attacher l’ISO des pilotes VirtIO, installer les pilotes dans l’invité, puis migrer
les contrôleurs un par un. La correction plus large fut culturelle : traiter les changements de périphérique comme des migrations de schéma. Les préparer, les vérifier, puis passer à l’étape suivante.

Le postmortem fut court et utile : ils n’avaient pas de « profile matériel premier démarrage » standard. Après cela, chaque V2V Windows commença par SATA + E1000,
puis passa à VirtIO une fois les pilotes confirmés. C’était plus lent. C’était aussi reproductible. La production aime la reproductibilité.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a voulu être astucieuse au sujet du stockage. Elle migrait une flotte de VM Linux et a décidé QCOW2 partout parce que « les snapshots, c’est bien ».
Leur stockage Proxmox était ZFS. Ils avaient empilé copy-on-write sur copy-on-write. Ça fonctionnait en test, parce que les tests furent courts et polis.
La production, elle, ne l’était pas.

Le premier signe fut une latence d’écriture élevée pendant les heures de pointe. Les bases de données se plaignirent. Les runners CI ralentirent. Puis les fenêtres de sauvegarde commencèrent à déraper.
L’équipe répondit avec plus de tuning : modes de cache, profondeurs de queue, et une poignée de modifications sysctl. Certaines aidèrent brièvement, surtout en déplaçant la douleur.

Finalement, ils firent la mesure ennuyeuse : iostat hôte, zpool iostat, latence au niveau VM. Le schéma était clair — amplification d’écriture aléatoire et churn métadonnées.
QCOW2 faisait son travail ; ZFS faisait le sien ; ensemble ils faisaient trop de travail.

Ils migrèrent les VM chaudes vers RAW sur zvols et réservèrent QCOW2 pour quelques cas où la portabilité comptait plus que la performance. La latence d’écriture se normalisa.
La leçon n’était pas « QCOW2 est mauvais ». La leçon : n’empilez pas des fonctionnalités à moins d’être prêt à en payer le coût en latence et complexité.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise dans le domaine de la santé a dû migrer un mélange de VM sous des fenêtres de changement serrées. Ils n’étaient pas glamour. Ils étaient disciplinés.
Chaque VM a eu la même checklist pré-vol : état des snapshots, vérification d’arrêt, validation du checksum d’export et étape de rollback documentée.
Chaque VM migrée devait passer « deux redémarrages et une sauvegarde » avant que la copie ESXi puisse être supprimée.

À mi-projet, un switch de stockage commença à laisser tomber des paquets intermittents sur le réseau de migration. Rien n’a complètement « craqué ».
Au lieu de cela, quelques transferts OVA arrivèrent corrompus. L’équipe ne le remarqua pas immédiatement — jusqu’à ce que la vérification du manifeste commence à échouer.
Cette étape ennuyeuse les empêcha d’importer des disques corrompus puis de déboguer des erreurs système fantômes.

Ils retransférèrent les exports affectés après avoir isolé le chemin réseau. Le planning de migration dérapa un peu, mais la production resta stable.
Personne n’a eu besoin d’inventer un nouveau rituel. Ils ont simplement suivi la checklist et l’ont laissée détecter le problème tôt.

Si vous cherchez la morale : les checksums coûtent moins cher que des ponts d’incident. Aussi, l’outil le plus « entreprise » dans la salle est souvent un fichier texte
où vous consignez de manière cohérente ce que vous avez fait.

FAQ

1) Proxmox peut-il importer directement un OVF et recréer le matériel de la VM ?

Pas comme vSphere. Vous créez généralement la VM shell vous-même et importez/convertissez les disques. Attendez-vous à mapper manuellement les périphériques.

2) Dois-je utiliser QCOW2 ou RAW sur Proxmox ?

RAW sur ZFS et Ceph est généralement le bon choix. QCOW2 est acceptable sur le stockage dir quand vous voulez des snapshots au niveau image ou de la portabilité.
N’empilez pas QCOW2 sur ZFS à moins de savoir pourquoi vous payez cet overhead.

3) Quel est le modèle de NIC le plus sûr pour le premier démarrage ?

E1000 est le choix de compatibilité courant, surtout pour Windows. Après installation des pilotes, passez à VirtIO pour la performance.

4) Quel est le contrôleur de disque le plus sûr pour le premier démarrage sur Windows ?

SATA. Démarrez avec SATA, installez les pilotes VirtIO, puis basculez le disque en VirtIO SCSI (un changement à la fois).

5) Ma VM ESXi utilisait UEFI. Que faire sur Proxmox ?

Utilisez OVMF (--bios ovmf) et ajoutez typiquement un disque EFI si nécessaire. Gardez le mode de démarrage cohérent ou vous atterrirez dans un shell EFI.

6) Puis-je migrer une VM avec des snapshots ?

Oui, mais vous ne devriez probablement pas. Consolidez d’abord les snapshots afin de convertir un disque cohérent unique. Les chaînes de snapshots sont où les conversions deviennent « créatives ».

7) Pourquoi mon disque importé consomme-t-il plus d’espace que le VMDK thin ?

Vous avez peut-être converti d’une manière qui a écrit des blocs auparavant sparses, ou votre stockage cible alloue différemment.
Vérifiez les attentes de sparseness et mesurez l’allocation réelle sur la destination.

8) Comment savoir si le goulet est réseau, disque ou CPU pendant la conversion ?

Mesurez sur le nœud Proxmox : iostat pour la saturation disque, mpstat pour iowait vs CPU, et des outils spécifiques au stockage (comme zpool iostat).
Ne « tunez » pas avant de savoir ce qui est saturé.

9) Les adresses MAC doivent-elles être conservées ?

Parfois. Les réservations DHCP, les systèmes de licence et les politiques de pare-feu peuvent se baser sur la MAC. Si vous ne savez pas, conservez les MAC et changez-les ensuite en connaissance de cause.

Prochaines étapes que vous pouvez réellement faire

1. Choisissez votre méthode par VM : par défaut qemu-img ; utilisez OVA quand vous avez besoin d’un artefact ; utilisez Clonezilla pour les appliances et les chargeurs d’amorçage bizarres.
2. Standardisez un « profil premier démarrage » : correspondance BIOS/UEFI, SATA + E1000 pour Windows si les pilotes ne sont pas prêts, puis migration graduelle vers VirtIO.
3. Rendez la conversion mesurable : exécutez iostat/mpstat/zpool iostat lors des premières conversions et notez ce que « normal » représente.
4. Exigez deux redémarrages et une sauvegarde avant de décommissionner l’original ESXi. Si vous sautez cette étape, l’univers vous apprendra pourquoi elle existe.
5. Documentez le mapping des périphériques (disk1 → scsi0, disk2 → scsi1, tags VLAN, MAC). Les échecs de migration adorent l’ambiguïté.

Si vous faites les parties ennuyeuses — hygiène des snapshots, correspondance de firmware, préparation des pilotes, vérification des checksums — la plupart des conversions V2V deviennent routinières.
Pas glamour. Prévisible. Ce qui est la meilleure chose à dire d’un changement en production.