Convertir VMDK en QCOW2 pour Proxmox : commandes qemu-img, conseils de performance et erreurs courantes

Vous avez un VMDK exporté depuis VMware et un cluster Proxmox qui se fiche de votre nostalgie. La migration est « juste une conversion de disque », jusqu’à ce qu’elle ne le soit plus : la VM démarre sur un écran noir, la conversion rampe à 20 MB/s, ou qemu-img commence à réciter de la poésie sur « invalid VMDK descriptor ».

Ceci est le guide de terrain que j’aurais souhaité que plus de gens utilisent avant de lancer des conversions sur la seule copie d’un disque de production. Il est volontairement direct. Vous êtes ici pour déplacer des octets en toute sécurité, rapidement, et avec moins de surprises qu’une fenêtre de changement un lundi matin.

Le modèle mental : ce que vous convertissez réellement

« VMDK en QCOW2 » sonne comme une simple métamorphose de fichier unique. En pratique, vous traduisez un format de conteneur de stockage, sa stratégie d’allocation, et souvent son historique de snapshots en quelque chose que QEMU peut exécuter efficacement.

VMDK peut être :

• MonolithicSparse fichier unique (commun dans les exports et certaines sauvegardes).
• Deux parties : un petit fichier descriptor texte plus un gros fichier flat extent (commun sur les datastores ESXi).
• Découpé en morceaux de 2 Go (style ancien/portable).
• Chaînes de snapshots (disques delta) où « le disque » est une pile de fichiers qui n’a de sens que réunis.

QCOW2 n’est pas non plus « juste un fichier ». Il peut stocker des snapshots, la compression, le chiffrement, et il contient des métadonnées qui peuvent devenir une taxe de performance si vous le traitez comme un périphérique bloc brut. Sur Proxmox, vous avez aussi une seconde décision : stockage fichier (dir, NFS, CIFS) vs stockage bloc (LVM-thin, ZFS zvol, Ceph RBD). La bonne cible n’est souvent pas QCOW2 du tout — c’est raw sur un zvol ou LVM-thin. Mais parfois QCOW2 est exactement ce qu’il vous faut, surtout pour le stockage fichier et la portabilité.

Voici la règle d’opinion : convertir une fois, valider deux fois, puis importer. Si vous convertissez dans un répertoire aléatoire avec des sémantiques de système de fichiers inconnues et sans vérification, vous ne migrez pas — vous jouez.

Faits intéressants & contexte historique (la partie utile)

1. VMDK précède la pensée moderne des « images cloud ». Il a grandi à une époque où la virtualisation de bureau et les datastores ont façonné la conception plus que l’automatisation centrée API.
2. VMDK « descriptor + flat » est une fonctionnalité, pas un bug. Le petit fichier descriptor est essentiellement des métadonnées et des pointeurs ; le perdre et vous pouvez encore sauver le flat extent — si vous connaissez la géométrie et les détails du format.
3. QCOW (v1) est venu avant QCOW2. QCOW2 l’a remplacé pour améliorer des fonctionnalités comme les snapshots et la gestion des refcounts ; il est devenu la valeur par défaut depuis des années pour de bonnes raisons.
4. qemu-img est plus ancien que beaucoup de runbooks de production. C’est un outil tranchant ; il fera exactement ce que vous lui demandez, y compris des choix irréversibles.
5. « Thin provisioning » signifie des choses différentes selon les couches. Un VMDK thin peut devenir un QCOW2 thick si vous choisissez les mauvais flags ou convertissez via le mauvais chemin.
6. Les snapshots VMware ne sont pas des sauvegardes. Les chaînes de snapshots peuvent être fragiles ; les conversions qui ignorent la structure de la chaîne produisent souvent des disques qui démarrent mais sont subtilement incohérents.
7. La performance de QCOW2 s’est grandement améliorée avec le temps. QEMU moderne a de meilleures options de cache et d’aio, mais les métadonnées QCOW2 coûtent toujours des IOPS, surtout sur des charges d’écritures aléatoires.
8. Proxmox penche historiquement vers raw pour le stockage bloc. Sur ZFS et LVM-thin, les volumes raw sont généralement le choix pour la performance et la simplicité ; QCOW2 brille sur un stockage basé fichier.

Vérifications préalables : ne convertissez pas ce que vous ne comprenez pas

Avant de convertir, vous devez savoir ce que vous avez, où cela réside, et à quoi « correct » ressemble. La plupart des migrations échouées ne sont pas des bugs de conversion. Ce sont des contextes manquants.

Task 1: Identifier le type de VMDK et les fichiers de backing

cr0x@server:~$ ls -lah /mnt/incoming/vmware-export/
total 68G
drwxr-xr-x  2 root root 4.0K Dec 28 10:14 .
drwxr-xr-x 12 root root 4.0K Dec 28 10:10 ..
-rw-------  1 root root  512 Dec 28 10:12 disk.vmdk
-rw-------  1 root root   68G Dec 28 10:12 disk-flat.vmdk

Ce que cela signifie : C’est le classique descriptor + flat extent. Le petit disk.vmdk est le descriptor ; le gros fichier est les données. Si vous n’avez copié que le descriptor, vous avez copié l’étiquette, pas le disque.

Décision : Gardez les deux fichiers ensemble. Ne renommez pas l’un sans éditer le descriptor. Traitez-les par paire.

Task 2: Inspecter le fichier descriptor (lorsqu’il existe)

cr0x@server:~$ sed -n '1,120p' /mnt/incoming/vmware-export/disk.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 142606336 VMFS "disk-flat.vmdk"

# The Disk Data Base
ddb.virtualHWVersion = "13"
ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "8874"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.toolsInstallType = "4"

Ce que cela signifie : La ligne extent vous indique la taille (en secteurs) et le fichier de backing. parentCID et CID indiquent des relations de snapshot. adapterType est important pour le démarrage après l’import (PVSCSI vs LSI vs SATA).

Décision : Si parentCID n’a pas l’air d’être ffffffff et que vous avez des deltas de snapshot, arrêtez-vous et localisez la chaîne. Convertir le mauvais maillon est la façon d’obtenir « démarre mais données manquantes ».

Task 3: Demandez à qemu-img ce qu’il pense du fichier

cr0x@server:~$ qemu-img info /mnt/incoming/vmware-export/disk.vmdk
image: /mnt/incoming/vmware-export/disk.vmdk
file format: vmdk
virtual size: 68 GiB (72980889600 bytes)
disk size: 68 GiB
cluster_size: 65536
Format specific information:
    cid: 4294967294
    parent cid: 4294967295
    create type: vmfs
    extents:
        [0]:
            virtual size: 68 GiB
            filename: /mnt/incoming/vmware-export/disk-flat.vmdk
            format: FLAT

Ce que cela signifie : qemu-img le voit comme VMDK et a trouvé le flat extent. Bien. S’il y a une erreur ici, votre conversion échouera aussi.

Décision : Si extents est manquant ou si le filename pointe ailleurs, corrigez d’abord les problèmes de chemin (souvent un flat file déplacé/renommé).

Task 4: Vérifier que vous ne traitez pas accidentellement une chaîne de snapshots

cr0x@server:~$ find /mnt/incoming/vmware-export -maxdepth 1 -type f -name "*.vmdk" -printf "%f\n" | sort
disk-flat.vmdk
disk.vmdk

Ce que cela signifie : Seulement deux fichiers. Probablement pas de chaîne de snapshots dans cet export. Dans une chaîne vous verriez des fichiers comme -000001.vmdk et compagnons.

Décision : Si vous voyez des disques delta, identifiez le descriptor actif « courant » et assurez-vous que tous les parents sont présents avant de convertir.

Task 5: Vérifier l’espace libre du système de fichiers où la conversion s’exécutera

cr0x@server:~$ df -h /mnt/convert
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       1.8T  1.1T  650G  63% /mnt/convert

Ce que cela signifie : Vous avez 650G de libre. Convertir un disque thin de 68G en un format thick peut s’étendre. Même QCOW2 peut gonfler pendant la conversion selon les options et la disposition source.

Décision : Assurez-vous de l’espace en pire cas. En cas de doute : convertissez en raw directement sur un stockage bloc (LVM-thin/ZFS) au lieu de créer un gros fichier intermédiaire.

Task 6: Baselinez les performances du stockage avant de blâmer qemu-img

cr0x@server:~$ fio --name=readtest --filename=/mnt/convert/.fiotest --size=2G --direct=1 --rw=read --bs=1M --iodepth=16 --numjobs=1 --runtime=30 --time_based --group_reporting
readtest: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=16
fio-3.33
Starting 1 process
readtest: Laying out IO file (1 file / 2048MiB)
Jobs: 1 (f=1): [R(1)][100.0%][r=965MiB/s][r=965 IOPS][eta 00m:00s]
read: IOPS=952, BW=952MiB/s (998MB/s)(27.9GiB/30001msec)
    clat (usec): min=402, max=10231, avg=1032.11, stdev=210.44

Ce que cela signifie : Vous avez ~950 MiB/s en lecture séquentielle. Si la conversion rampe à 40 MiB/s, le goulot n’est pas « le disque est lent » en général — c’est ailleurs (chemin d’écriture, CPU, comportement mono-thread, compression, réseau).

Décision : Enregistrez la lecture/écriture de référence. Vous en aurez besoin quand quelqu’un dira « Proxmox est lent ».

Blague #1 : Une chaîne de snapshots VMDK ressemble à un organigramme d’entreprise : elle semble stable jusqu’à ce que vous demandiez qui possède réellement les données.

Modèles de conversion principaux avec qemu-img (et pourquoi)

qemu-img est le cheval de trait pour les conversions de format. La partie critique est le choix de :

• Format de sortie : qcow2 ou raw (et parfois raw est le choix le plus judicieux).
• Comportement d’allocation : sparse vs préalloué.
• Caractéristiques d’E/S : cache et options aio qui peuvent accélérer la conversion sans mentir sur la durabilité.

Task 7: Faites une simulation de votre compréhension avec info sur la source et la sortie prévue

cr0x@server:~$ qemu-img info --output=json /mnt/incoming/vmware-export/disk.vmdk
{
    "virtual-size": 72980889600,
    "filename": "/mnt/incoming/vmware-export/disk.vmdk",
    "format": "vmdk",
    "actual-size": 72980889600,
    "format-specific": {
        "type": "vmfs",
        "cid": 4294967294,
        "parent-cid": 4294967295
    }
}

Ce que cela signifie : La sortie JSON est pratique pour les scripts et les contrôles de cohérence. virtual-size compte ; actual-size vous dit la taille actuelle du fichier (pour les flat extents elle peut correspondre à la taille virtuelle).

Décision : Décidez si vous gardez le comportement sparse (thin) ou si vous passez en thick. Pour la plupart des migrations, gardez-le thin sauf raison contraire.

Task 8: Convertir VMDK en QCOW2 (options par défaut sensées)

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 /mnt/incoming/vmware-export/disk.vmdk /mnt/convert/disk.qcow2
    (0.00/100%)
    (12.34/100%)
    (54.87/100%)
    (100.00/100%)

Ce que cela signifie : -p affiche la progression. C’est la base. Pas de flags de cache sophistiqués. Ce sera correct, mais peut ne pas être le plus rapide.

Décision : Utilisez ceci si vous faites une opération ponctuelle ou si vous ne pouvez pas vous permettre d’être trop astucieux. « Ennuyeux et correct » est une stratégie opérationnelle valide.

Task 9: Vérifier l’intégrité du résultat (vérification en lecture seule)

cr0x@server:~$ qemu-img check -r all /mnt/convert/disk.qcow2
No errors were found on the image.
443392/443392 = 100.00% allocated, 0.00% fragmented, 0.00% compressed clusters
Image end offset: 72985100288

Ce que cela signifie : qemu-img check valide la structure QCOW2. « No errors » est ce que vous voulez. Si vous voyez des erreurs de refcount, c’est un drapeau rouge.

Décision : Si la vérification signale de la corruption, n’importez pas. Reconvertissez depuis la source. Si la corruption persiste, suspectez des problèmes sur la chaîne source ou le stockage.

Task 10: Inspecter les métadonnées QCOW2 pour voir ce que vous avez réellement obtenu

cr0x@server:~$ qemu-img info /mnt/convert/disk.qcow2
image: /mnt/convert/disk.qcow2
file format: qcow2
virtual size: 68 GiB (72980889600 bytes)
disk size: 12.4 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Ce que cela signifie : La taille virtuelle est 68 GiB, mais la taille du disque est 12.4 GiB : résultat sparse/thin. Parfait pour économiser de l’espace ; pas toujours idéal pour la performance d’écriture séquentielle si votre charge va immédiatement remplir le disque.

Décision : Si la charge est une base de données qui allouera beaucoup au premier démarrage, envisagez des stratégies de préallocation ou du raw sur stockage bloc.

Task 11: Conversion plus rapide en utilisant des réglages de cache plus sûrs

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 -t none -T none /mnt/incoming/vmware-export/disk.vmdk /mnt/convert/disk-fast.qcow2
    (0.00/100%)
    (33.21/100%)
    (71.09/100%)
    (100.00/100%)

Ce que cela signifie : -t est le mode de cache source ; -T est le mode de cache destination. none évite typiquement le double-caching et peut réduire la surcharge. Cela ne rend pas le stockage lent rapide ; ça réduit juste le buffering inutile.

Décision : Utilisez ceci quand vous contrôlez l’hôte et faites confiance à la pile de stockage. Si vous écrivez sur un stockage réseau instable, vous préférerez peut-être un cache plus sûr au prix de la vitesse.

Task 12: Convertir en raw (souvent mieux pour Proxmox sur ZFS/LVM-thin)

cr0x@server:~$ qemu-img convert -p -f vmdk -O raw -t none -T none /mnt/incoming/vmware-export/disk.vmdk /mnt/convert/disk.raw
    (0.00/100%)
    (25.00/100%)
    (62.50/100%)
    (100.00/100%)

Ce que cela signifie : Raw est simple. Pas de tables de métadonnées. Surcharge minimale. Sur un stockage bloc back-end Proxmox, raw gagne souvent en latence et prévisibilité.

Décision : Si votre cible Proxmox est ZFS zvol ou LVM-thin, envisagez fortement d’importer en raw dans ces backends plutôt que de garder un fichier QCOW2.

Task 13: Convertir avec un sous-format explicite quand qemu-img se trompe

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 -o subformat=qcow2 /mnt/incoming/vmware-export/disk.vmdk /mnt/convert/disk.qcow2
qemu-img: warning: -o subformat=qcow2 is not supported for output format qcow2

Ce que cela signifie : C’est un exemple délibéré de « ne fais pas ça ». qemu-img vous dira quand vous essayez des options sans sens. Les gens copient-collent des flags aléatoires depuis de vieux billets de blog ; l’outil n’est pas sentimental.

Décision : Si vous ne savez pas ce qu’une option fait, ne l’utilisez pas pendant une fenêtre de migration. Restez sur des flags que vous pouvez expliquer sous pression.

Importer dans Proxmox la façon que Proxmox préfère

La conversion n’est qu’une moitié du travail. Vous devez encore attacher le disque correctement : bon bus, ordre de démarrage correct, type de stockage approprié, et un OS invité qui peut trouver son périphérique racine.

Task 14: Inspecter les types de stockage Proxmox et choisir la bonne cible

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        100.0G           22.3G           72.6G   22.30%
local-lvm     lvmthin     active        800.0G          312.0G          488.0G   39.00%
zfspool          zfs     active          1.7T           840.0G          860.0G   49.41%

Ce que cela signifie : Les stockages dir comme local peuvent contenir des fichiers QCOW2. lvmthin et zfs veulent typiquement des volumes raw (bien que Proxmox puisse stocker qcow2 sur certains backends ; vous le regretterez généralement sur le stockage bloc).

Décision : Si vous importez vers local-lvm ou zfspool, prévoyez un import en raw ou laissez Proxmox convertir pendant l’import.

Task 15: Créer une coquille de VM (sans disque encore), puis importer le disque

cr0x@server:~$ qm create 120 --name vm-imported --memory 8192 --cores 4 --net0 virtio,bridge=vmbr0
created VM 120

Ce que cela signifie : Vous avez maintenant une configuration VM pour attacher le disque.

Décision : Choisissez VirtIO pour la NIC sauf si l’OS invité manque de pilotes. Si c’est Windows sans pilotes VirtIO, planifiez l’injection des pilotes ou commencez avec e1000 et migrez ensuite.

Task 16: Importer un fichier QCOW2 dans le stockage Proxmox

cr0x@server:~$ qm importdisk 120 /mnt/convert/disk.qcow2 local-lvm
importing disk 'unused0:local-lvm:vm-120-disk-0'...
transferred 0.0 B of 68.0 GiB (0.00%)
transferred 10.2 GiB of 68.0 GiB (15.00%)
transferred 68.0 GiB of 68.0 GiB (100.00%)
Successfully imported disk as 'unused0:local-lvm:vm-120-disk-0'

Ce que cela signifie : Proxmox a importé dans local-lvm et a probablement converti en volume raw en interne. Le disque apparaît comme unused0 jusqu’à ce que vous l’attachiez.

Décision : Attachez-le au contrôleur correct (VirtIO SCSI pour Linux/Windows modernes avec pilotes ; SATA/IDE uniquement pour compatibilité).

Task 17: Attacher le disque importé et définir l’ordre de démarrage

cr0x@server:~$ qm set 120 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-120-disk-0 --boot order=scsi0
update VM 120: -scsihw virtio-scsi-pci -scsi0 local-lvm:vm-120-disk-0 -boot order=scsi0

Ce que cela signifie : Le disque est maintenant le périphérique de démarrage sur un contrôleur VirtIO SCSI, un bon choix par défaut pour la performance et les fonctionnalités (discard, queueing).

Décision : Si l’invité ne démarre pas et utilisait auparavant LSI Logic dans VMware, essayez --scsihw lsi temporairement pour le démarrer, puis migrez vers VirtIO plus tard.

Task 18: Vérifier la config VM, y compris le type de machine et BIOS/UEFI

cr0x@server:~$ qm config 120
boot: order=scsi0
cores: 4
memory: 8192
name: vm-imported
net0: virtio=BC:24:11:8A:19:FE,bridge=vmbr0
scsi0: local-lvm:vm-120-disk-0,iothread=1
scsihw: virtio-scsi-pci

Ce que cela signifie : Cherchez bios / efidisk0 manquant si la VM d’origine utilisait UEFI. Si elle était UEFI sur VMware et que vous démarrez avec SeaBIOS ici, attendez-vous à des problèmes.

Décision : Alignez le firmware : si UEFI, définissez --bios ovmf et ajoutez un disque EFI. Si legacy, gardez SeaBIOS.

Task 19: Convertir à la volée avec Proxmox si vous voulez moins d’étapes

cr0x@server:~$ qm importdisk 120 /mnt/incoming/vmware-export/disk.vmdk zfspool
importing disk 'unused0:zfspool:vm-120-disk-0'...
transferred 0.0 B of 68.0 GiB (0.00%)
transferred 68.0 GiB of 68.0 GiB (100.00%)
Successfully imported disk as 'unused0:zfspool:vm-120-disk-0'

Ce que cela signifie : Proxmox peut importer directement depuis VMDK vers le stockage choisi, en convertissant au besoin. Cela réduit les fichiers intermédiaires et le risque d’oublier de nettoyer. Cela concentre aussi le risque sur le nœud Proxmox qui réalise l’opération.

Décision : Si vous faites cela, exécutez-le sur un nœud avec des marges et un stockage stable. Ne lancez pas de grosses conversions sur le nœud déjà sollicité par la production.

Tuning des performances : rapidité sans saboter

La vitesse de conversion est façonnée par quelques contraintes ennuyeuses : bande passante lecture, bande passante écriture, CPU (pour checksums/métadonnées), et la disposition du format source. QCOW2 ajoute une surcharge de métadonnées ; les chaînes de snapshots VMDK ajoutent des lectures aléatoires. Et le stockage réseau ajoute une latence qui transforme des écritures séquentielles en documentaire au ralenti.

Sachez ce que vous optimisez

• Temps de conversion rapide : minimiser la surcharge CPU, éviter le double-caching, écrire séquentiellement sur un stockage local rapide, puis déplacer.
• Performance en runtime VM : choisissez le format final et le backend adéquats ; raw sur stockage bloc est difficile à battre.
• Efficacité d’espace : QCOW2 sparse est bien ; la compression peut aider mais ajoute du CPU et peut nuire à la latence plus tard.

Task 20: Mesurer le CPU comme goulot pendant la conversion

cr0x@server:~$ pidstat -dru -p $(pgrep -n qemu-img) 1
Linux 6.8.12 (server)  12/28/2025  _x86_64_  (32 CPU)

11:04:12      UID       PID    %usr %system  %CPU   CPU  kB_rd/s kB_wr/s  Command
11:04:13        0     44122   85.00   10.00 95.00     7  980000.00 420000.00 qemu-img

Ce que cela signifie : Si %CPU est saturé et les débits I/O sont inférieurs à ce que le stockage peut faire, vous êtes CPU-bound — souvent à cause de la gestion des métadonnées QCOW2 ou de la complexité du format source.

Décision : Si CPU-bound, envisagez de convertir en raw, ou de convertir sur un nœud plus puissant, ou d’éviter compression/chiffrement. N’espérez pas que des flags de cache résolvent un plafond CPU.

Task 21: Confirmer l’attente I/O quand la conversion est « lente »

cr0x@server:~$ iostat -xm 1 3
Linux 6.8.12 (server)  12/28/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.20    0.00    6.11   52.40    0.00   23.29

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
nvme0n1         220.0  880000.0     0.0   0.00    1.10  4000.0    160.0  640000.0     0.0   0.00    2.80  4000.0    0.70  78.00

Ce que cela signifie : Un %iowait élevé plus une util de périphérique élevée signifie que votre stockage est le goulot. Si l’util est faible mais iowait élevé, suspectez le stockage réseau ou des verrous système de fichiers/latence.

Décision : Déplacez la conversion vers un stockage scratch local plus rapide puis importez. Ou, si la destination est la partie lente, choisissez un meilleur backend (local-lvm/zfs sur SSD) pour l’import.

Task 22: Utiliser un chemin scratch local pour éviter d’écrire QCOW2 sur NFS

cr0x@server:~$ mount | grep -E 'nfs|cifs'
nas01:/exports/vm-migrations on /mnt/incoming type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)

Ce que cela signifie : La source est sur NFS. La lecture est souvent acceptable ; écrire la sortie QCOW2 sur NFS pendant la conversion est là où la performance prend sa retraite prématurément.

Décision : Copiez la source localement d’abord, convertissez localement, puis importez. Oui, c’est des étapes en plus. Non, vous ne le regretterez pas.

Task 23: Copier le VMDK localement en préservant la sparseness (lorsque applicable)

cr0x@server:~$ rsync -aH --sparse --info=progress2 /mnt/incoming/vmware-export/ /mnt/local-scratch/vmware-export/
         68,000,000,000 100%  720.00MB/s    0:01:30 (xfr#2, to-chk=0/3)

Ce que cela signifie : --sparse peut préserver les trous sur des systèmes de fichiers qui les supportent, ce qui compte quand vous préparez des images thin.

Décision : Si la source est vraiment flat/thick, sparse n’aide pas. Mais ça ne nuit pas beaucoup non plus ; gardez-le dans votre mémoire musculaire de migration standard.

Task 24: Préallouer la sortie quand vous tenez à une performance d’écriture régulière plus tard

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 -o preallocation=metadata /mnt/local-scratch/vmware-export/disk.vmdk /mnt/convert/disk-prealloc.qcow2
    (0.00/100%)
    (49.00/100%)
    (100.00/100%)

Ce que cela signifie : preallocation=metadata alloue les métadonnées QCOW2 à l’avance, réduisant certains remaniements d’allocation ultérieurs sans préallouer entièrement tous les clusters de données.

Décision : Utilisez ceci quand l’invité fera beaucoup d’écritures aléatoires au démarrage (bases de données, serveurs applicatifs chargés). Si l’espace de stockage est serré, évitez la préallocation complète.

Task 25: Vérifier que vous n’avez pas accidentellement créé un QCOW2 épais gigantesque

cr0x@server:~$ du -h /mnt/convert/disk-prealloc.qcow2
13G	/mnt/convert/disk-prealloc.qcow2

Ce que cela signifie : Toujours relativement petit : bien. S’il égale la taille virtuelle, vous l’avez rendu thick.

Décision : Si vous avez épaissi involontairement, reconvertissez avec les options adéquates ou envisagez raw sur stockage bloc à la place.

Task 26: Confirmer les attentes sur discard/TRIM (pour les backends thin)

cr0x@server:~$ qm set 120 --scsi0 local-lvm:vm-120-disk-0,discard=on
update VM 120: -scsi0 local-lvm:vm-120-disk-0,discard=on

Ce que cela signifie : Active le discard invité (là où c’est supporté). Sur les backends thin-provisioned, cela peut retourner des blocs libérés. Sur certaines piles ça ne fait rien ; sur d’autres ça aide à garder le pool sain.

Décision : Activez-le pour les invités Linux avec fstrim et noyaux modernes. Pour certains environnements Windows, validez le comportement avant de l’assumer.

Blague #2 : Activer tous les flags « performance » à la fois, c’est comme ajouter huit ailerons à une berline — techniquement modifiée, toujours lente, désormais plus bruyante.

Méthode de diagnostic rapide (trouver le goulot en minutes)

Voici l’ordre que j’utilise quand la conversion ou les performances de premier démarrage semblent mauvaises. Cela évite les terriers de lapin et vous amène à une réponse concrète « c’est le CPU / c’est le stockage / c’est le réseau / c’est la config invité » rapidement.

Première étape : prouver que l’image source est cohérente

1. qemu-img info sur le VMDK. S’il échoue, arrêtez ; corrigez descriptor/extent/snapshots.
2. Listez le répertoire pour des fichiers delta manquants ou des extents renommés.
3. Si une chaîne de snapshots existe, identifiez le descriptor actif (celui utilisé par la VM) et assurez-vous que tous les parents existent.

Deuxième étape : localiser la limite de débit

1. Mesurez la vitesse d’écriture de destination avec fio ou au moins regardez iostat -xm.
2. Vérifiez si la conversion est CPU-bound avec pidstat.
3. Si la source est sur stockage réseau, copiez localement et retentez la conversion pour séparer le réseau de la surcharge de conversion.

Troisième étape : valider la sortie et l’attachement Proxmox

1. qemu-img check sur le QCOW2 (ou vérifiez la taille raw et les sommes de contrôle si possible).
2. qm config : contrôleur correct, ordre de démarrage, BIOS/UEFI correspondants.
3. Pilotes invités : pilotes VirtIO stockage/NIC présents ? Sinon, attendez-vous à des échecs de démarrage ou à des NICs manquantes.

Task 27: Confirmer si vous êtes CPU-bound ou I/O-bound en un coup d’œil

cr0x@server:~$ top -b -n 1 | head -n 15
top - 11:06:01 up 10 days,  2:14,  2 users,  load average: 9.12, 8.44, 7.90
Tasks: 412 total,   2 running, 410 sleeping,   0 stopped,   0 zombie
%Cpu(s): 61.3 us,  7.2 sy,  0.0 ni,  8.4 id, 23.1 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem : 128000.0 total,  24000.0 free,  12000.0 used,  92000.0 buff/cache
MiB Swap:  16000.0 total,  15950.0 free,     50.0 used. 108000.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
44122 root      20   0  221668  29384   6120 R  298.0   0.0   1:22.19 qemu-img

Ce que cela signifie : CPU élevé (qemu-img utilisant plusieurs cœurs) plus un wa élevé signifie que vous êtes limité sur les deux ; ajouter des flags à qemu-img ne résoudra pas un disque lent.

Décision : Déplacez le travail vers un stockage plus rapide ou planifiez-le quand le stockage est calme. Si impossible, convertissez en raw et laissez le backend gérer l’allocation.

Erreurs courantes : symptômes → cause racine → correction

Cette section est écrite dans le langage de l’astreinte : ce que vous voyez, ce que cela signifie habituellement, et ce qui marche réellement.

1) qemu-img : « Could not open ‘…’: invalid VMDK descriptor »

Symptômes : qemu-img info ou convert échoue immédiatement avec des erreurs de parsing du descriptor.

Cause racine : Le descriptor est corrompu, édité incorrectement, problèmes de newline/encodage, ou il référence un extent manquant/renommé.

Correction :

• Ouvrez le descriptor et vérifiez que le nom du fichier extent correspond à ce qui est sur le disque.
• Assurez-vous que le flat extent existe et est lisible.
• Si le descriptor a disparu mais que vous avez *-flat.vmdk, reconstruisez un descriptor (avec précaution) ou réexportez depuis VMware.

2) La conversion « réussit » mais la VM démarre sur initramfs / ne trouve pas le device root

Symptômes : Linux tombe dans un shell d’urgence ; device root manquant après import.

Cause racine : Le contrôleur disque a changé (ex. VMware LSI Logic vers Proxmox VirtIO SCSI) et initramfs manque les pilotes, ou fstab utilise des noms de device qui ont changé (sda vs vda).

Correction :

• Basculez temporairement le contrôleur vers un plus compatible (ex. LSI) pour démarrer, puis installez les pilotes VirtIO et reconstruisez initramfs.
• Utilisez les UUIDs dans fstab et la configuration du chargeur de démarrage si possible.

3) Windows fait un blue-screen après import (INACCESSIBLE_BOOT_DEVICE)

Symptômes : BSOD au démarrage juste après l’import Proxmox.

Cause racine : Windows n’a pas le pilote du contrôleur de stockage pour le nouveau contrôleur virtuel (VirtIO SCSI), ou mismatch du mode de démarrage (UEFI vs BIOS).

Correction :

• Démarrez avec un contrôleur supporté par Windows (SATA, LSI) d’abord.
• Installez les pilotes VirtIO dans Windows, puis basculez sur VirtIO.
• Alignez le mode firmware et assurez l’ordre de démarrage correct.

4) La conversion est douloureusement lente sur NFS/CIFS

Symptômes : Conversion à quelques dizaines de MB/s malgré des disques locaux rapides.

Cause racine : Écriture de la sortie sur un stockage réseau avec haute latence ; les mises à jour de métadonnées QCOW2 amplifient les petites écritures.

Correction : Stagiez localement (scratch NVMe), convertissez localement, puis importez vers le backend final. Si vous devez écrire sur le réseau, préférez raw et des I/O plus larges, en acceptant que ce soit peut-être lent.

5) Le disque importé est « unused0 » et la VM ne démarre pas

Symptômes : Le disque existe dans le stockage Proxmox mais n’est pas attaché comme périphérique de boot.

Cause racine : qm importdisk importe mais n’attache pas ; ordre de boot non défini.

Correction : Attachez le disque avec qm set et définissez --boot order=....

6) La taille du disque semble incorrecte après conversion

Symptômes : Le fichier QCOW2 a une taille égale à la taille virtuelle alors que vous attendiez thin, ou inversement.

Cause racine : Options de préallocation, source était un flat thick, ou le chemin de conversion a étendu les données (blocs nuls écrits comme alloués).

Correction : Reconvertissez avec les options désirées ; pour des cibles thin assurez-vous d’utiliser des méthodes de copie compatibles sparse et évitez les outils qui désparsifient (certaines copies naïves le font).

7) « Failed to get write lock » / « image is in use » pendant la conversion

Symptômes : qemu-img refuse d’écrire ou Proxmox ne peut pas démarrer la VM.

Cause racine : Le disque est ouvert par un autre processus (job de sauvegarde, autre conversion, une VM référence encore le fichier).

Correction : Identifiez le processus qui tient le fichier/volume et arrêtez-le ; évitez de convertir in place sur un datastore actif.

Task 28: Trouver qui a un fichier disque ouvert (classique « pourquoi est-ce verrouillé ? »)

cr0x@server:~$ lsof /mnt/convert/disk.qcow2 | head
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
qemu-img 44122 root    3u   REG   8,17 13314398624 131073 /mnt/convert/disk.qcow2

Ce que cela signifie : Le fichier est ouvert activement par qemu-img. Si vous voyez qemu-system-x86_64, une VM l’utilise.

Décision : Ne forcez pas les verrous. Arrêtez proprement le consommateur, puis poursuivez.

Trois mini-histoires d’entreprise (parce que le disque n’a pas d’émotions)

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

L’équipe avait un export VMware : un joli server.vmdk dans un dossier partagé. Quelqu’un a copié juste ce fichier vers le nœud Proxmox et a lancé qemu-img convert. qemu-img s’est plaint d’extents manquants. Ils ont haussé les épaules, réexporté, obtenu la même chose, puis décidé que l’outil était « pointilleux ».

L’hypothèse erronée était simple : ils pensaient qu’un VMDK est toujours autonome. Dans leur environnement, ESXi stockait un fichier descriptor plus un énorme flat file, et leur workflow d’export avait préservé les deux — mais seul le descriptor avait l’air « important ». Le grand -flat.vmdk était à côté comme un complice silencieux.

Ils ont finalement copié aussi le flat extent, et la conversion a marché. Mais la VM a démarré avec des erreurs de système de fichiers. Le vrai dommage est arrivé plus tôt : lors de la première tentative, ils ont essayé de « réparer » le descriptor en éditant la taille d’extent et le nom de fichier en se basant sur des suppositions, puis ont converti à partir d’un descriptor décalé pointant vers un flat file d’un export antérieur. La conversion était correcte — correcte par rapport à la mauvaise source.

La correction n’a pas été héroïque. Ils ont repris depuis l’export original, vérifié la référence d’extent dans le descriptor, vérifié les checksums des deux fichiers, et seulement ensuite lancé la conversion. Le downtime a été plus long que nécessaire, et la leçon était embarrassante mais peu coûteuse : n’éditez jamais les métadonnées d’une image sauf si vous pouvez prouver ce que vous faites.

Mini-histoire 2 : L’optimisation qui a mal tourné

Un autre groupe exécutait des migrations nocturnes pour un rafraîchissement de labo. Ils voulaient de la vitesse. Ils ont trouvé une poignée de flags en ligne et ont construit un wrapper « turbo convert » : modes de cache agressifs, jobs parallèles, et écriture directe vers un partage réseau pour « éviter une copie supplémentaire ».

C’était rapide — jusqu’à ce que ça ne le soit plus. Certaines conversions ont produit des images QCOW2 qui passaient un qemu-img info superficiel mais échouaient ensuite en charge avec des avertissements de corruption. D’autres ont démarré mais avaient des erreurs applicatives subtiles qui passaient pour des bugs logiciels. Les migrations sont devenues un cauchemar de support : chaque VM importée était suspecte.

Le retour de bâton venait surtout des sémantiques de durabilité. Ils ont mélangé options de cache et comportement du stockage réseau et traité « conversion terminée » comme « octets définitivement écrits ». Des accrocs réseau et le caching côté serveur signifiaient que le job pouvait se terminer alors que le stockage n’avait pas vraiment engagé tout ce que l’équipe supposait.

Ils ont abandonné le wrapper. Le nouveau processus semblait plus lent sur le papier mais finissait plus vite en bout de chaîne parce qu’il arrêtait de produire des artefacts cassés : stage local, convert local avec cache conservateur, valider avec qemu-img check, puis importer. La meilleure optimisation a été d’éliminer le retravail.

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

Un système lié aux finances migrait de VMware vers Proxmox sous une fenêtre serrée. L’équipe a fait quelque chose de profondément peu à la mode : ils ont écrit une checklist et l’ont suivie. Pas une checklist « sympathique ». Une checklist de passage qui refusait d’avancer tant que chaque étape n’avait pas produit la sortie attendue.

Ils ont capturé le JSON de qemu-img info pour chaque source, l’ont stocké avec le ticket de migration, et ont enregistré la config Proxmox après l’import. Ils ont aussi exécuté qemu-img check sur chaque artefact QCOW2 et conservé le log. C’était fastidieux, comme souvent les bonnes opérations.

Pendant le cutover, une VM n’a pas démarré. Pas de panique. Ils ont comparé le type d’adaptateur VMware d’origine dans le descriptor (lsilogic) à la config Proxmox (VirtIO SCSI). Ils ont basculé le contrôleur sur LSI, démarré, installé les pilotes VirtIO, basculé de nouveau, et poursuivi. La checklist n’a pas empêché l’incident, mais elle a évité l’agitation.

Ce qui a sauvé la mise n’était pas une commande astucieuse. C’était de l’observabilité disciplinée : chaque étape laissait une preuve. Quand quelque chose a cassé, ils n’ont pas deviné — ils ont comparé.

Listes de contrôle / plan étape par étape

Utilisez l’un de ces plans selon votre backend de stockage et votre appétit pour les fichiers intermédiaires.

Plan A : Sûr et portable (VMDK → QCOW2 fichier → import)

1. Inventoriez les fichiers : assurez-vous d’avoir descriptor + flat extent (ou un VMDK monolithique).
2. Exécutez qemu-img info sur la source ; confirmez la taille virtuelle et les extents.
3. Vérifiez l’espace libre sur le système de fichiers de conversion (planification pire cas).
4. Stagez localement si la source/destination est un stockage réseau.
5. Convertissez avec des flags conservateurs : qemu-img convert -p -f vmdk -O qcow2.
6. Exécutez qemu-img check -r all sur le QCOW2.
7. Créez la coquille VM dans Proxmox : qm create.
8. Importez le disque : qm importdisk vers le stockage choisi.
9. Attachez le disque et définissez l’ordre de boot : qm set.
10. Validation du premier démarrage : confirmez que l’OS voit le disque, la NIC fonctionne, la synchronisation temporelle et les services démarrent.

Plan B : Centré Proxmox (import direct depuis VMDK)

1. Vérifiez le VMDK source avec qemu-img info.
2. Créez la coquille VM avec l’attente firmware correcte (UEFI vs BIOS selon ce que vous savez).
3. Exécutez qm importdisk VMID disk.vmdk STORAGE.
4. Attachez le disque au contrôleur correct et définissez l’ordre de boot.
5. Démarrez, validez, puis ajustez les options de performance (iothread, discard, cache) avec précaution.

Le plan B est bien pour des migrations routinières quand vous faites confiance à l’état du nœud Proxmox et voulez moins d’artefacts à gérer. Le plan A est meilleur quand vous avez besoin d’un QCOW2 portable et d’une piste d’audit répétable.

Task 29: Capturer un « enregistrement de conversion » reproductible (piste d’audit bon marché)

cr0x@server:~$ qemu-img info --output=json /mnt/incoming/vmware-export/disk.vmdk | tee /mnt/convert/disk.vmdk.info.json
{
    "virtual-size": 72980889600,
    "filename": "/mnt/incoming/vmware-export/disk.vmdk",
    "format": "vmdk",
    "actual-size": 72980889600,
    "format-specific": {
        "type": "vmfs",
        "cid": 4294967294,
        "parent-cid": 4294967295
    }
}

Ce que cela signifie : Vous avez sauvegardé un enregistrement lisible par machine de ce que vous avez converti. C’est ainsi que vous évitez « qu’avons-nous importé déjà ? » deux semaines plus tard.

Décision : Conservez ces enregistrements avec les tickets de changement. C’est ennuyeux. Ça marche.

Task 30: Confirmer que le disque importé existe sur le stockage cible

cr0x@server:~$ pvesm list local-lvm | grep vm-120-disk-0
local-lvm:vm-120-disk-0  vm-120-disk-0  68.00G

Ce que cela signifie : Le volume est présent et correctement dimensionné.

Décision : Si la taille est incorrecte, arrêtez et enquêtez avant le démarrage. Une mauvaise taille peut indiquer que vous avez importé le mauvais fichier ou que les données sont tronquées.

Task 31: Démarrez la VM et surveillez le démarrage initial depuis l’hôte

cr0x@server:~$ qm start 120
started VM 120

Ce que cela signifie : La VM a été lancée. Vous avez maintenant besoin de visibilité console.

Décision : Si elle échoue immédiatement, vérifiez les logs de tâche Proxmox et les erreurs de stockage. Si elle démarre mais ne boote pas, vérifiez le mismatch firmware/contrôleur.

Une citation qui appartient à tout runbook de migration

L’espoir n’est pas une stratégie. — General Gordon R. Sullivan

FAQ

1) Dois-je convertir en QCOW2 ou en raw pour Proxmox ?

Si votre stockage cible est dir/NFS et que vous voulez un fichier portable, QCOW2 convient. Si votre cible est LVM-thin ou ZFS, raw est généralement plus rapide et plus simple. Si vous tenez à QCOW2 sur stockage bloc, vous payez une surcharge pour des fonctionnalités que vous n’utiliserez probablement pas.

2) Proxmox peut-il importer un VMDK directement ?

Oui, qm importdisk peut importer depuis VMDK vers une cible de stockage Proxmox en convertissant si nécessaire. C’est pratique, mais cela n’enlève pas le besoin de valider la source et d’attacher le disque correctement.

3) Pourquoi qemu-img dit « invalid VMDK descriptor » ?

Le plus souvent le descriptor référence un flat extent qui est manquant, renommé, ou à un chemin différent. Parfois le descriptor est corrompu ou édité incorrectement. Validez le nom du fichier extent et assurez-vous que le flat file est présent.

4) Mon disque converti démarre mais des données manquent. Comment ?

Vous avez probablement converti le mauvais maillon d’une chaîne de snapshots (un parent au lieu de l’enfant actif), ou vous n’avez pas inclus tous les fichiers delta. Les chaînes de snapshots VMware doivent être complètes et cohérentes pour que la conversion représente l’état courant.

5) Pourquoi la conversion est-elle plus lente que la copie du fichier ?

La conversion peut impliquer des mises à jour de métadonnées (QCOW2), des lectures aléatoires (chaînes de snapshots), ou l’amplification de latence réseau (écrire QCOW2 sur NFS). La copie est souvent séquentielle et plus simple.

6) Dois-je me préoccuper d’UEFI vs BIOS lors de l’import ?

Oui. Si la VM était en UEFI sur VMware et que vous la démarrez en BIOS legacy sur Proxmox, vous pouvez obtenir un système non amorçable qui ressemble à un « problème de disque » mais ne l’est pas. Alignez le firmware dès le départ.

7) Quelle est la vérification la plus sûre après conversion ?

Exécutez qemu-img check -r all pour l’intégrité structurelle QCOW2, puis faites un démarrage test sur un réseau isolé. Les vérifications d’intégrité ne détecteront pas toutes les incohérences au niveau système de fichiers, mais elles détectent la corruption au niveau image.

8) Puis-je accélérer la conversion en utilisant la compression QCOW2 ?

Vous pouvez, mais c’est un compromis. La compression coûte du CPU et peut nuire à la latence d’I/O aléatoire plus tard. Pour des VMs de production, je préfère acheter du stockage plutôt que d’acheter une latence mystérieuse.

9) Ma VM Windows ne démarre pas avec VirtIO. Quel est le chemin le moins douloureux ?

Démarrez avec un contrôleur supporté nativement par Windows (souvent SATA/LSI), installez les pilotes VirtIO, puis passez à VirtIO SCSI. Faites-le par étapes contrôlées, pas d’un seul coup.

10) Dois-je convertir sur le nœud Proxmox ou ailleurs ?

Convertissez là où vous avez des I/O stables et de la marge. Si les nœuds Proxmox sont occupés, utilisez un hôte dédié à la conversion puis importez. La meilleure migration est celle qui ne concurrence pas les workloads de production.

Prochaines étapes pratiques

Faites la migration comme vous feriez un changement de stockage en production : identifiez ce que vous avez, choisissez le format cible correct pour le backend, exécutez la conversion avec des flags que vous comprenez, et validez avant le démarrage. Évitez les « hacks de vitesse » tant que vous n’avez pas prouvé où est le goulot.

Prochaines étapes qui rapportent immédiatement :

• Exécutez qemu-img info sur chaque VMDK que vous prévoyez de migrer et sauvegardez la sortie JSON avec le ticket.
• Choisissez d’abord votre cible de stockage finale (dir vs LVM-thin vs ZFS), puis décidez QCOW2 vs raw en conséquence.
• Adoptez la méthode de diagnostic rapide : cohérence source → limite de débit → attachement Proxmox.
• Standardisez sur un modèle de conversion par backend et arrêtez d’improviser pendant les fenêtres de changement.