Importer une VM ESXi dans Proxmox : Windows/Linux, pilotes VirtIO, mappage des NIC, corrections de démarrage

Faits et historique qui comptent vraiment

Un peu de contexte rend les modes de défaillance moins mystérieux et plus prévisibles. Voici les éléments qui m’ont souvent aidé lors de migrations réelles :

1. VMDK est plus ancien que la plupart des stratégies « cloud-first ». VMware a introduit VMDK au début des années 2000 ; il existe des variantes sparse/thick et toute une collection de sous-types que les outils de conversion ne gèrent pas toujours de la même manière.
2. KVM est intégré au noyau Linux depuis 2007. Proxmox repose sur cette base, ce qui signifie que les changements du noyau Linux (pilotes, nommage, initramfs) peuvent être plus pertinents que les « réglages Proxmox ».
3. VirtIO vient de l’écosystème KVM/QEMU pour éviter le surcoût d’émulation matérielle. Excellente performance, désastreux si votre OS invité n’a pas le pilote au démarrage.
4. UEFI vs BIOS n’est pas un simple commutateur cosmétique. Si ESXi a installé l’invité en mode UEFI et que vous le démarrez en BIOS (ou l’inverse), vous obtenez souvent une situation « le disque semble vide ».
5. Le SCSI paravirtualisé de VMware (PVSCSI) n’est pas VirtIO. Les deux semblent « paravirtual », mais les piles de pilotes sont différentes. Windows sanctionne particulièrement les hypothèses ici.
6. Les noms « predictibles » des NIC ont changé le modèle mental humain. Linux est passé de eth0/eth1 à des noms comme ens18/enp0s3 ; la migration rend ce changement douloureusement visible.
7. qcow2 n’est pas « juste un autre format de disque ». Il supporte les snapshots et la compression mais ajoute de l’indirection. Sur certains backends de stockage, raw est plus rapide et plus simple.
8. OVA est une archive tar, pas magique. Il contient généralement une description OVF plus un ou plusieurs VMDK. Traitez-le comme une archive que vous pouvez inspecter, pas comme un artefact sacré.
9. L’activation Windows et les identifiants matériels ont toujours été capricieux. Changer d’hyperviseur modifie suffisamment le matériel virtuel pour prévoir des demandes d’activation et des vérifications de conformité des licences.

Et une citation de fiabilité, parce que c’est toujours l’état d’esprit juste quand vous êtes sur le point de basculer une charge de production sur un matériel virtuel différent :

Werner Vogels (idée paraphrasée) : « Tout échoue, tout le temps — concevez et exploitez comme si c’était la norme. »

Arbre de décision : choisissez votre voie d’import

Il existe trois chemins courants. Choisissez-en un, engagez-vous, et évitez de mélanger des « bricolages rapides » en cours de route.

Voie A : Vous avez une exportation OVA/OVF

Idéal si vous pouvez exporter proprement depuis vCenter/ESXi et voulez un paquet portable. Vous extrayez les VMDK et convertissez avec qemu-img ou laissez Proxmox importer le disque.

Voie B : Vous avez les fichiers VMDK depuis un datastore

Idéal si vous pouvez SCP depuis ESXi ou parcourir le datastore. Vous copiez les VMDK et les convertissez/importez.

Voie C : Vous n’avez ni l’un ni l’autre, seulement une VM en marche que vous ne pouvez pas arrêter

Alors vous faites de la réplication, une restauration de sauvegarde, ou du mirroring bloc par bloc. Ce guide suppose que vous pouvez obtenir une exportation complète à froid ou au moins un snapshot cohérent. Si vous ne pouvez pas, votre « migration » est en réalité un événement de fiabilité déguisé.

Préparation sur ESXi : exporter proprement et capturer la vérité

Votre objectif sur ESXi est simple : figer les faits sur la VM avant de la déplacer. Quel contrôleur de disque ? BIOS ou UEFI ? Quel type de NIC ? Quelles VLAN ? Quelles IP ? Une fois sur Proxmox, ces détails deviennent des suppositions, et les suppositions sont la raison pour laquelle vous vous retrouvez avec une VM qui « démarre bien » mais qui ne peut parler à rien.

Tâche 1 : Enregistrer le firmware, les disques et les types de NIC de la VM (depuis le shell ESXi)

cr0x@server:~$ ssh root@esxi01 'vim-cmd vmsvc/getallvms | head'
Vmid   Name                 File                               Guest OS      Version   Annotation
1      dc01                 [datastore1] dc01/dc01.vmx          windows9Server64Guest   vmx-13
2      web01                [datastore1] web01/web01.vmx        ubuntu64Guest  vmx-14

Ce que signifie la sortie : vous avez des VMID et des chemins VMX. Vous utiliserez le VMX pour confirmer le firmware et les périphériques.

Décision : identifiez le VMID que vous migrez et notez son chemin VMX.

Tâche 2 : Récupérer le VMX et vérifier le firmware et le modèle de périphérique

cr0x@server:~$ ssh root@esxi01 'grep -E "firmware|scsi|nvme|ethernet.*virtualDev" /vmfs/volumes/datastore1/web01/web01.vmx'
firmware = "efi"
scsi0.virtualDev = "pvscsi"
ethernet0.virtualDev = "vmxnet3"

Ce que cela signifie : invité UEFI, SCSI paravirtualisé VMware et NIC vmxnet3.

Décision : prévoyez OVMF sur Proxmox et comprenez que l’invité dépend actuellement des pilotes PVSCSI et vmxnet3 — pas de VirtIO.

Tâche 3 : Éteindre proprement (ou prendre un snapshot justifiable)

cr0x@server:~$ ssh root@esxi01 'vim-cmd vmsvc/power.getstate 2'
Retrieved runtime info
Powered on

Décision : si vous pouvez planifier une fenêtre d’arrêt, éteignez. Sinon, prenez un snapshot quiescé seulement si vos outils invités et vos applications le supportent. Sinon, acceptez que vous exportez des données « peut-être cohérentes ».

cr0x@server:~$ ssh root@esxi01 'vim-cmd vmsvc/power.shutdown 2; sleep 5; vim-cmd vmsvc/power.getstate 2'
Retrieved runtime info
Powered off

Ce que cela signifie : arrêt propre réussi. C’est l’étalon-or pour la conversion de disque.

Tâche 4 : Exporter/copier les disques (exemple : scp depuis ESXi)

cr0x@server:~$ scp root@esxi01:/vmfs/volumes/datastore1/web01/web01.vmdk .
web01.vmdk                                      100%  512B   2.1KB/s   00:00

Ce que cela signifie : ce petit fichier est le descripteur. Les données sont généralement dans -flat.vmdk ou similaire.

Décision : copiez toujours le fichier flat/les extents aussi, ou utilisez une méthode d’export qui produit un flux unique (OVA) pour éviter des parties manquantes.

cr0x@server:~$ scp root@esxi01:/vmfs/volumes/datastore1/web01/web01-flat.vmdk .
web01-flat.vmdk                                 100%   40G  110.2MB/s   06:12

Préparation sur Proxmox : stockage, réseau et garde-fous

Côté Proxmox, les deux grands risques sont : (1) déposer de grandes images raw sur le mauvais stockage, puis découvrir que vous ne pouvez pas snapshot/replicator comme vous le pensiez, et (2) connecter la VM au mauvais bridge/VLAN et la « réussir » en l’isolant du réseau.

Tâche 5 : Vérifier les cibles de stockage et l’espace libre

cr0x@server:~$ pvesm status
Name            =reqtype  Status     Total     Used    Avail   %  Content
local             dir     active    98.0G    11.2G    81.6G  11  iso,vztmpl,backup
local-lvm         lvmthin active   900.0G   612.4G   287.6G  68  rootdir,images
zfspool           zfspool active     2.7T     1.1T     1.6T  40  images,rootdir

Ce que cela signifie : vous avez plusieurs destinations. Le pool ZFS a de la place et supporte les snapshots ; LVM-thin supporte aussi les snapshots mais se comporte différemment sous pression.

Décision : choisissez le backend de stockage intentionnellement. Si vous prévoyez beaucoup de snapshots/réplication, ZFS est souvent le moins surprenant.

Tâche 6 : Confirmer les bridges et la gestion VLAN

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:ec:ef:11:22:33
vmbr0            UP             3c:ec:ef:11:22:33
vmbr1            UP             3c:ec:ef:aa:bb:cc

Décision : assortissez votre portgroup/VLAN ESXi à un bridge Proxmox et un tag. Si vous ne pouvez pas décrire le réseau en une phrase, arrêtez-vous et cartographiez-le avant d’importer.

Tâche 7 : Vérifier la santé de l’hôte Proxmox avant d’accuser la VM

cr0x@server:~$ pveversion -v
proxmox-ve: 8.2.2 (running kernel: 6.8.12-4-pve)
pve-manager: 8.2.4 (running version: 8.2.4/2a1b7d2c)

Décision : un noyau moderne et une version récente de QEMU réduisent les bizarreries de compatibilité, surtout avec UEFI et le stockage. Si vous êtes sur du très ancien, attendez-vous à plus de frictions.

Blague #1 : La virtualisation, c’est juste faire semblant très fort, et d’une manière ou d’une autre la paie en dépend.

Convertir les disques : VMDK/OVA vers le stockage Proxmox

La conversion est l’endroit où vous pouvez ruiner silencieusement votre journée. Les règles sont simples :

• Confirmez que vous avez les véritables extents de données (flat/sesparse/etc.).
• Convertissez avec un outil qui comprend les sous-formats VMDK.
• Choisissez raw pour la simplicité/performance sur ZFS/LVM-thin sauf si vous avez une raison d’utiliser qcow2.
• Validez la taille de l’image résultante et l’intégrité de base avant de l’attacher.

Tâche 8 : Inspecter le descripteur VMDK (repérer les surprises multi-extent)

cr0x@server:~$ head -n 20 web01.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 83886080 VMFS "web01-flat.vmdk"

Ce que cela signifie : un seul fichier d’extent, secteurs ~40GiB. Bien. Si vous voyez plusieurs extents, vous devez copier toutes les parties et conserver les chemins relatifs.

Décision : si c’est multi-extent et que vous n’avez pas toutes les pièces, arrêtez. Ré-exportez en OVA ou recopiez correctement.

Tâche 9 : Convertir VMDK en raw (préféré sur ZFS pour moins de couches)

cr0x@server:~$ qemu-img convert -p -f vmdk -O raw web01.vmdk web01.raw
    (0.00/100%)
    (12.50/100%)
    (25.00/100%)
    (37.50/100%)
    (50.00/100%)
    (62.50/100%)
    (75.00/100%)
    (87.50/100%)
    (100.00/100%)

Ce que cela signifie : conversion terminée. Pas d’erreurs. Bon début, pas une preuve suffisante.

Décision : si vous ciblez LVM-thin ou ZFS, raw convient. Si vous avez besoin de stockage fichier avec snapshots et n’avez pas ZFS/LVM-thin, qcow2 peut être utile.

Tâche 10 : Vérifier les infos de l’image (contrôle avant import)

cr0x@server:~$ qemu-img info web01.raw
image: web01.raw
file format: raw
virtual size: 40 GiB (42949672960 bytes)
disk size: 40 GiB

Ce que cela signifie : raw est entièrement alloué ; c’est attendu. Si vous attendiez du thin provisioning, vous ne le verrez qu’avec qcow2 ou avec le stockage cible (comme un ZVOL/LVM-thin) gérant la sparsitité.

Décision : si la taille du disque est complètement fausse (par ex. 4 GiB au lieu de 40 GiB), vous avez converti la mauvaise chose ou manqué des extents.

Tâche 11 : Importer le disque dans le stockage Proxmox avec qm importdisk

cr0x@server:~$ qm create 120 --name web01 --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0
create VM 120: success

cr0x@server:~$ qm importdisk 120 web01.raw zfspool
importing disk 'web01.raw' to VM 120 ...
transferred 40.0 GiB of 40.0 GiB (100.00%)
Successfully imported disk as 'zfspool:vm-120-disk-0'

Ce que cela signifie : le disque est maintenant un volume géré par Proxmox.

Décision : à partir d’ici, traitez le volume importé comme la source de vérité ; conservez le VMDK/raw original dans un endroit sûr jusqu’à ce que la VM soit stable et sauvegardée.

Créer la VM dans Proxmox : contrôleurs, firmware, CPU et RAM

C’est ici que la plupart des « ça démarre sur ESXi » se prennent une claque. Les matériels virtuels par défaut d’ESXi ne sont pas les mêmes que ceux de Proxmox. Votre travail est de reproduire ce qui compte pour le démarrage, puis d’améliorer la performance une fois stable.

Attacher correctement le disque importé

Après qm importdisk, vous devez encore attacher le disque à un contrôleur et définir l’ordre de démarrage.

Tâche 12 : Attacher le disque en SATA d’abord (approche stabilité d’abord)

cr0x@server:~$ qm set 120 --sata0 zfspool:vm-120-disk-0
update VM 120: -sata0 zfspool:vm-120-disk-0

Ce que cela signifie : le disque est attaché à un contrôleur SATA. Presque tous les OS peuvent démarrer depuis SATA sans pilotes supplémentaires.

Décision : utilisez SATA (ou IDE pour les OS anciens) pour le premier démarrage réussi. Passez à VirtIO SCSI plus tard pour la performance.

Tâche 13 : Faire correspondre le mode firmware (UEFI vs BIOS)

cr0x@server:~$ qm set 120 --bios ovmf --efidisk0 zfspool:0,pre-enrolled-keys=1
update VM 120: -bios ovmf -efidisk0 zfspool:vm-120-disk-1,pre-enrolled-keys=1

Ce que cela signifie : vous avez activé OVMF (UEFI) et créé un disque de variables EFI. Si le VMX d’ESXi indiquait firmware="efi", c’est la correspondance.

Décision : si l’invité était en BIOS sur ESXi, n’activez pas OVMF. Si vous ne savez pas, vérifiez le VMX et le partitionnement (EFI System Partition vs MBR).

Tâche 14 : Définir explicitement l’ordre de démarrage

cr0x@server:~$ qm set 120 --boot order=sata0
update VM 120: -boot order=sata0

Décision : ne faites pas confiance aux valeurs par défaut. Faites démarrer la VM sur le disque que vous avez importé, pas sur un CD-ROM virtuel vide.

Tâche 15 : Démarrer et surveiller la sortie console (évitez les redémarrages à l’aveugle)

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

cr0x@server:~$ qm status 120
status: running

Décision : ouvrez la console Proxmox et observez. Si ça échoue, vous voulez l’erreur exacte. « Ça ne démarre pas » n’est pas un symptôme ; c’est une confession.

Importations Windows : pilotes VirtIO, corrections de démarrage et séquençage prudent

Windows ne vous en veut pas personnellement. Il s’attend simplement à ce que les contrôleurs de stockage et réseau restent cohérents entre les démarrages, et il s’attend à ce que les pilotes nécessaires existent avant qu’il tente de monter le volume de démarrage.

La séquence la plus sûre pour Windows est :

1. Démarrer sur un contrôleur « universel » (SATA) et un modèle de NIC « universel » (E1000) si besoin.
2. Installer les pilotes VirtIO à l’intérieur de Windows.
3. Passer le contrôleur de disque à VirtIO SCSI (ou VirtIO Block) et la NIC à VirtIO.
4. Redémarrer et valider.

Stratégie de pilotes VirtIO qui fonctionne vraiment

Montez l’ISO des pilotes VirtIO dans Proxmox, puis installez les pilotes depuis le Gestionnaire de périphériques ou lancez l’installateur si disponible. L’essentiel : le pilote de stockage doit être présent et activé au démarrage.

Tâche 16 : Ajouter l’ISO des pilotes VirtIO (exemple suppose que l’ISO est déjà uploadé)

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

Décision : si Windows démarre mais n’a pas de réseau, ce n’est pas grave. Ne paniquez pas et n’« optimisez » rien pour l’instant. Installez d’abord les pilotes.

Tâche 17 : Basculer la NIC vers un modèle de compatibilité temporairement (si nécessaire)

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

Ce que cela signifie : vous utilisez une NIC Intel émulée. Plus lente, mais Windows la reconnaît sans pilotes supplémentaires.

Décision : si vous ne pouvez pas accéder à la machine pour installer VirtIO, utilisez E1000 pour récupérer temporairement le réseau et terminer l’installation des pilotes.

Après les pilotes : passer à VirtIO SCSI

VirtIO SCSI est le point idéal pour la plupart des charges. Il gère mieux TRIM/UNMAP dans de nombreux setups et est largement testé.

Tâche 18 : Ajouter le contrôleur VirtIO SCSI et déplacer le disque

cr0x@server:~$ qm set 120 --scsihw virtio-scsi-single
update VM 120: -scsihw virtio-scsi-single

cr0x@server:~$ qm set 120 --scsi0 zfspool:vm-120-disk-0
update VM 120: -scsi0 zfspool:vm-120-disk-0

cr0x@server:~$ qm set 120 --delete sata0
update VM 120: delete sata0

Décision : ne supprimez l’attachement SATA qu’après que les pilotes VirtIO soient installés et que vous soyez sûr que le prochain démarrage trouvera le disque.

Tâche 19 : Passer la NIC en VirtIO après que Windows ait le pilote

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

Ce que cela signifie : Windows verra une nouvelle NIC. Votre configuration IP pourrait ne pas suivre automatiquement si elle était liée à l’ancien adaptateur.

Décision : prévoyez une reconfiguration IP ou des scripts. Pour les serveurs à IP statique, attendez-vous à une courte fenêtre « où est passée mon IP ? »

Erreurs de démarrage Windows que vous verrez réellement

• INACCESSIBLE_BOOT_DEVICE (BSOD) : incompatibilité du pilote de stockage. Démarré sur SATA, cassé après passage à VirtIO avant l’installation des pilotes.
• Bloqué sur les points qui tournent : parfois un problème de pilote, parfois un mauvais mode firmware, parfois un BCD corrompu après conversion.
• Aucun périphérique de démarrage : mauvaise ordre de démarrage ou incompatibilité UEFI/BIOS.

Blague #2 : Les pilotes Windows sont comme des parapluies — vous réalisez que vous en aviez besoin seulement une fois que vous êtes déjà trempé.

Importations Linux : initramfs, noms de NIC et pièges des UUID de systèmes de fichiers

Les migrations Linux sont généralement plus simples que Windows, jusqu’au moment où elles ne le sont pas. Les points de rupture courants sont :

• l’initramfs n’inclut pas le pilote pour le nouveau contrôleur de disque (VirtIO) donc le système racine n’apparaît jamais.
• le nom de l’interface réseau change (ens160 sur VMware devient ens18 sur Proxmox) et votre configuration réseau pointe vers un périphérique fantôme.
• les entrées du chargeur d’amorçage référencent des UUID anciens, ou la conversion a changé quelque chose rendant la ligne de commande du noyau incapable de trouver root.

Tâche 20 : Obtenir la table de partitions du disque de la VM depuis l’hôte Proxmox (sans démarrer)

cr0x@server:~$ ls -l /dev/zvol/zfspool/vm-120-disk-0
lrwxrwxrwx 1 root root 13 Dec 28 10:12 /dev/zvol/zfspool/vm-120-disk-0 -> ../../zd0

cr0x@server:~$ partprobe /dev/zd0 && lsblk -f /dev/zd0
NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
zd0
├─zd0p1 vfat   FAT32       1A2B-3C4D
└─zd0p2 ext4   1.0         11111111-2222-3333-4444-555555555555

Ce que cela signifie : probablement UEFI (ESP vfat) plus root ext4. Cela confirme votre décision précédente sur le firmware.

Décision : si vous attendiez BIOS/MBR mais voyez une ESP, passez la VM à OVMF et ajoutez un efidisk.

Tâche 21 : Si Linux démarre mais n’a pas de réseau, identifier le nouveau nom de NIC

cr0x@server:~$ qm guest exec 120 -- ip -br a
{
  "exitcode": 0,
  "out-data": "lo               UNKNOWN        127.0.0.1/8 ::1/128\nens18            DOWN           \n",
  "err-data": ""
}

Ce que cela signifie : la VM voit ens18 mais il est down/non configuré.

Décision : mettez à jour votre netplan/systemd-networkd/scripts ifcfg pour référencer le nouveau nom d’interface, ou utilisez un appariement basé sur l’adresse MAC.

Tâche 22 : Valider que la VM voit le disque en VirtIO après le changement de contrôleur

cr0x@server:~$ qm guest exec 120 -- lsblk
{
  "exitcode": 0,
  "out-data": "NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS\nvda    252:0    0   40G  0 disk \nvda1   252:1    0  512M  0 part /boot/efi\nvda2   252:2    0 39.5G  0 part /\n",
  "err-data": ""
}

Ce que cela signifie : le disque apparaît comme /dev/vda (VirtIO). Bien.

Décision : si votre /etc/fstab référence /dev/sda2 au lieu des UUID, corrigez-le avant le prochain reboot.

Tâche 23 : Vérifier que l’initramfs inclut les modules VirtIO (dans l’invité)

cr0x@server:~$ qm guest exec 120 -- bash -lc 'lsinitramfs /boot/initrd.img-$(uname -r) | grep -E "virtio|vda|scsi" | head'
{
  "exitcode": 0,
  "out-data": "usr/lib/modules/6.5.0-28-generic/kernel/drivers/block/virtio_blk.ko\nusr/lib/modules/6.5.0-28-generic/kernel/drivers/scsi/virtio_scsi.ko\n",
  "err-data": ""
}

Décision : si les modules VirtIO sont absents, reconstruisez l’initramfs avant de changer définitivement de contrôleur (update-initramfs -u sur Debian/Ubuntu, dracut -f sur RHEL-like).

Mappage des NIC : des vSwitches aux bridges Linux

Le réseau ESXi se construit autour de portgroups sur des vSwitches (standard ou distribué). Le réseau Proxmox utilise des bridges Linux (souvent vmbr0) et un éventuel tagging VLAN. Le piège est de penser que « même VLAN ID » équivaut à « même connectivité ». Ce n’est pas le cas si le trunk en amont ou la gestion VLAN du bridge diffèrent.

Cartographiez-le délibérément

• Portgroup ESXi VLAN 0/none → bridge Proxmox non taggé sur le même réseau physique.
• Portgroup ESXi VLAN X → NIC VM Proxmox taggée VLAN X (tag=X) sur un bridge VLAN-aware, ou utilisez une interface/bridge VLAN dédiée.
• Plusieurs NIC → mappez chacune au bridge correct, ne « mettez pas tout sur vmbr0 » sauf si vous voulez un mouvement latéral accidentel.

Tâche 24 : Afficher la gestion VLAN du bridge Proxmox (côté hôte)

cr0x@server:~$ grep -A4 -B2 -n "vmbr0" /etc/network/interfaces
7:auto vmbr0
8:iface vmbr0 inet static
9:        address 10.10.10.5/24
10:       gateway 10.10.10.1
11:       bridge-ports eno1
12:       bridge-stp off
13:       bridge-fd 0
14:       bridge-vlan-aware yes

Ce que cela signifie : bridge VLAN-aware. Vous pouvez tagger les NIC des VM sans interfaces VLAN Linux supplémentaires.

Décision : si bridge-vlan-aware n’est pas activé mais que vous avez besoin de tags, soit activez-le (prudemment) soit construisez une alternative. Ne faites pas ça à l’arrache sur un hôte de production en heures ouvrables.

Tâche 25 : Définir un VLAN taggé sur une NIC VM

cr0x@server:~$ qm set 120 --net0 virtio,bridge=vmbr0,tag=30
update VM 120: -net0 virtio,bridge=vmbr0,tag=30

Décision : si l’invité ne peut toujours pas atteindre sa passerelle, confirmez que le switch en amont trunke la VLAN 30 et que le bridge hôte est sur la bonne interface physique.

Mode d’emploi de diagnostic rapide

Quand la VM importée « ne fonctionne pas », vous devez trouver le goulet d’étranglement rapidement. Voici l’ordre qui fait gagner du temps.

Premier point : Est-ce qu’elle démarre, et quelle est la défaillance exacte ?

• Aucun périphérique de démarrage / chute dans le shell UEFI → mauvais mode firmware ou ordre de démarrage, ou disque non attaché.
• GRUB rescue / panic du noyau : impossible de monter root → incompatibilité contrôleur/pilote ou UUID fstab/root erroné.
• Windows BSOD INACCESSIBLE_BOOT_DEVICE → le pilote de stockage n’est pas présent pour le contrôleur sélectionné.

Second point : Le disque est-il présent et où ?

Vérifiez sur l’hôte Proxmox : le disque a-t-il bien été importé et est-il attaché à la VM sur le bus prévu ?

cr0x@server:~$ qm config 120 | egrep "boot|bios|efidisk|scsi|sata|ide"
bios: ovmf
boot: order=scsi0
efidisk0: zfspool:vm-120-disk-1,pre-enrolled-keys=1,size=4M
ide2: local:iso/virtio-win.iso,media=cdrom
scsi0: zfspool:vm-120-disk-0
scsihw: virtio-scsi-single

Décision : si le disque est sur le mauvais bus (par ex. vous vouliez SATA pour le premier boot), corrigez cela avant de toucher quoi que ce soit dans l’invité.

Troisième point : Le réseau est-il cassé, ou seulement l’identité de la NIC changée ?

• L’invité démarre mais pas de ping → probablement un mauvais mapping VLAN/bridge, pilotes manquants ou renommage NIC.
• Ping OK mais services indisponibles → problème applicatif, pare-feu, ou configuration IP modifiée.

Quatrième point : La performance est-elle le « problème » ou l’hôte est-il saturé ?

N’ajustez pas la VM avant de savoir si l’hôte est le goulot.

cr0x@server:~$ pvesh get /nodes/$(hostname)/status | egrep '"cpu"|mem|swap'
  "cpu": 0.23,
  "memory": {
    "free": 5826394112,
    "total": 34359738368,
    "used": 28533344256
  },
  "swap": {
    "free": 8589934592,
    "total": 8589934592,
    "used": 0
  }

Décision : si la mémoire est tendue ou le CPU saturé, la « VM lente » peut être un hôte surchargé. Réparez la plateforme d’abord.

Erreurs fréquentes : symptôme → cause racine → correction

1) Symptom : « No bootable device » après import

Cause racine : incompatibilité de firmware (UEFI vs BIOS) ou mauvais ordre de démarrage, ou disque non attaché à aucun bus.

Correction : confirmez le firmware dans le VMX, puis faites correspondre dans Proxmox (--bios seabios ou --bios ovmf + efidisk). Définissez l’ordre de démarrage explicitement.

2) Symptom : Windows BSOD INACCESSIBLE_BOOT_DEVICE

Cause racine : vous avez attaché le disque sur VirtIO SCSI/Block avant que Windows ait le pilote de stockage activé.

Correction : revenez au bus SATA, démarrez, installez les pilotes VirtIO, puis repassez à VirtIO SCSI.

3) Symptom : Linux tombe dans initramfs ou kernel panic « unable to mount root »

Cause racine : l’initramfs n’inclut pas les modules VirtIO, ou root= référence un nom de périphérique changé (sda → vda), ou fstab utilise des chemins de périphérique.

Correction : démarrez via SATA temporairement, reconstruisez l’initramfs, mettez /etc/fstab à jour avec des UUID, puis passez à VirtIO.

4) Symptom : la VM démarre mais n’a pas de réseau

Cause racine : modèle de NIC changé et pilote manquant (Windows) ou renommage d’interface (Linux), ou tag VLAN/bridge incorrect.

Correction : utilisez temporairement E1000 sur Windows pour récupérer l’accès ; sur Linux, mettez à jour la configuration réseau pour le nouveau nom de NIC. Validez le bridge et le tagging VLAN sur l’hôte.

5) Symptom : le réseau fonctionne mais les services sont inaccessibles depuis l’extérieur

Cause racine : profil de pare-feu modifié, Windows pense être sur un réseau « Public », ou l’IP est liée à un ancien adaptateur invisible.

Correction : rattachez l’IP à l’adaptateur actif, vérifiez le profil du pare-feu Windows, confirmez routes et sockets en écoute.

6) Symptom : performance disque catastrophique après import

Cause racine : vous avez conservé un contrôleur émulé (IDE/SATA) ou utilisé qcow2 sur un stockage qui fait déjà du copy-on-write de façon inefficace, ou l’hôte est I/O bound.

Correction : passez à VirtIO SCSI et activez iothreads si pertinent ; préférez raw sur ZFS/LVM-thin ; vérifiez la latence hôte et la santé du stockage d’abord.

7) Symptom : dérive horaire ou sauts de l’horloge

Cause racine : changements des outils VM (VMware tools retiré, QEMU guest agent non installé), mauvaise source de synchronisation, ou service temporel Windows réévaluant le matériel.

Correction : installez et activez le QEMU guest agent ; configurez NTP/chrony/systemd-timesyncd ; vérifiez le service temps Windows et la hiérarchie temporelle du domaine.

8) Symptom : la VM ne démarre pas, Proxmox signale un lock ou des erreurs de config

Cause racine : lock résiduel, stockage indisponible, mauvais ID de volume, ou mauvaises éditions de config.

Correction : inspectez qm config, vérifiez l’état du stockage, déverrouillez seulement quand vous êtes sûr qu’il n’y a rien en cours.

cr0x@server:~$ qm unlock 120
unlock VM 120

Checklists / plan étape par étape

Checklist A : Avant de toucher quoi que ce soit

• Confirmez fenêtre de maintenance et plan de rollback (conservez la VM d’origine éteinte mais intacte).
• Enregistrez le VMX ESXi : firmware, contrôleur de disque, modèle de NIC, nombre de disques et adresses MAC.
• Enregistrez les IP, routes et exigences VLAN.
• Confirmez que la cible de stockage Proxmox a de l’espace et supporte les fonctionnalités nécessaires (snapshots/réplication).

Checklist B : Export et conversion des disques

1. Éteindre la VM (préféré).
2. Copier le descripteur VMDK et les extents (ou exporter en OVA).
3. Inspecter le descripteur : mono vs multi-extent, notes sur le type d’adaptateur.
4. Convertir avec qemu-img en raw (ou qcow2 si stockage fichier requis).
5. Vérifier avec qemu-img info.

Checklist C : Premier démarrage dans Proxmox (stabilité d’abord)

1. Créer la VM avec des paramètres conservateurs (disque SATA, NIC E1000 si Windows).
2. Faire correspondre le firmware (OVMF vs SeaBIOS).
3. Définir l’ordre de démarrage explicitement.
4. Démarrer et confirmer que l’OS se charge.
5. Corriger le réseau dans l’invité si le nom/modèle de NIC a changé.

Checklist D : Passe performance (après démarrage propre)

1. Installer le QEMU guest agent.
2. Installer les pilotes VirtIO (Windows).
3. Basculer le disque sur VirtIO SCSI et la NIC sur VirtIO.
4. Redémarrer et valider disque + réseau + application.
5. Faire une sauvegarde Proxmox et/ou un snapshot seulement après validation.

Tâche 26 : Activer le QEMU guest agent dans la configuration Proxmox

cr0x@server:~$ qm set 120 --agent enabled=1
update VM 120: -agent enabled=1

Décision : si vous comptez sur des arrêts propres, le reporting IP et des actions scriptées, activez l’agent et installez-le dans l’invité.

Tâche 27 : Confirmer que l’agent invité répond

cr0x@server:~$ qm guest ping 120
qemu-agent is running

Décision : s’il ne tourne pas, n’accusez pas Proxmox — installez/démarrez le service agent dans l’invité et vérifiez les pare-feux/SELinux si applicable.

Tâche 28 : Faire une sauvegarde après validation

cr0x@server:~$ vzdump 120 --storage local --mode snapshot --compress zstd
INFO: starting new backup job: vzdump 120 --storage local --mode snapshot --compress zstd
INFO: VM 120: starting backup
INFO: VM 120: backup finished
INFO: Finished Backup of VM 120 (00:02:41)

Ce que cela signifie : vous avez maintenant une sauvegarde native Proxmox que vous pouvez restaurer rapidement si la prochaine modification casse le démarrage.

Décision : faites cela avant de commencer les « réglages ». Les sauvegardes coûtent moins que les exploits de dernière minute.

Trois micro-récits d’entreprise depuis le terrain

Micro-récit 1 : L’incident causé par une mauvaise hypothèse

Ils ont migré un serveur de fichiers Windows d’ESXi vers Proxmox pendant un rafraîchissement d’hyperviseur. L’ingénieur qui faisait le travail avait déjà réussi une demi-douzaine de migrations Linux et a supposé que Windows se comporterait pareil : « Attache le disque en VirtIO, c’est plus rapide, on installera les pilotes après. » Cette hypothèse a un code BSOD très spécifique.

La VM a démarré, a rencontré INACCESSIBLE_BOOT_DEVICE, puis est restée coincée dans des boucles de réparation automatique. L’équipe a tenté la boîte à outils habituelle : changer le type de CPU, basculer le type de machine, même « peut-être que c’est Secure Boot ». Chaque redémarrage rendait la situation plus bruyante, pas meilleure. Entre-temps, un service envoyait des captures d’écran de lecteurs partagés manquants comme si c’était une nouvelle œuvre d’art.

La correction a été douloureusement simple. Ils ont remis le disque en SATA, démarré avec succès, installé les pilotes de stockage et réseau VirtIO depuis l’ISO, puis basculé seulement ensuite vers VirtIO SCSI. Windows a récupéré immédiatement parce que rien n’était corrompu ; il manquait juste le pilote au démarrage.

Le postmortem n’a pas conclu « VirtIO est mauvais ». Il a conclu : ne changez pas le matériel critique de démarrage avant que l’invité puisse le piloter. Une migration est déjà un grand changement ; vous n’avez pas besoin d’empiler l’optimisation de performance au premier démarrage.

Micro-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre équipe a décidé d’être maligne sur le stockage : tout importer en qcow2 parce que « les snapshots sont plus faciles », puis stocker ces qcow2 sur un backend copy-on-write. Ce n’est pas intrinsèquement faux — jusqu’à ce que vous le fassiez à grande échelle avec des charges écriture-intensives et que personne ne modélise l’amplification.

En quelques jours, le symptôme était « Proxmox est lent ». La latence disque des VM a explosé. Les sauvegardes ont pris plus de temps et ont commencé à se chevaucher les heures ouvrables. Les gens ont commencé à blâmer le réseau parce que c’est toujours à la mode de blâmer le réseau.

Le vrai problème était le comportement emboîté du copy-on-write dans un environnement qui avait déjà des snapshots et du churn. Les écritures aléatoires se sont transformées en une petite fête de taxes. La surcharge métadonnée a grimpé. Les hôtes n’étaient pas cassés ; l’architecture l’était.

Ils ont corrigé en convertissant les volumes à fort churn en raw sur un backend plus approprié et en gardant qcow2 seulement là où il apportait un bénéfice opérationnel clair. La performance est revenue, et tout le monde a cessé de deviner.

L’optimisation, c’est bien. Ne pas optimiser deux couches à la fois puis s’étonner quand la physique s’en mêle.

Micro-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation avait un runbook de migration péniblement conservateur. Chaque VM importée démarrait d’abord sur SATA et une NIC de compatibilité si l’OS était inconnu. Ils prenaient une sauvegarde immédiatement après le premier démarrage réussi, puis procédaient à l’installation des pilotes et à la conversion VirtIO en phase deux.

C’était lent. Ce n’était pas glamour. Et ça a évité une panne quand une appliance Linux legacy a démarré sur SATA mais a échoué sur VirtIO parce que son initramfs manquait de modules et l’image fournisseur était verrouillée. S’ils avaient commencé par VirtIO, ils auraient eu une VM morte et une loterie de tickets support.

Parce qu’ils avaient une sauvegarde prise au point « connu bon », ils pouvaient revenir rapidement en arrière pendant qu’ils expérimentaient les types de contrôleurs. Ils ont finalement laissé cette appliance sur SATA en permanence, acceptant la perte de performance parce que la charge ne justifiait pas le risque.

C’est la vraie attitude adulte : choisir la fiabilité ennuyeuse plutôt que le débit théorique quand l’impact business ne paie pas le risque.

FAQ

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

Pour ZFS ou LVM-thin, je choisis généralement raw. C’est plus simple et souvent plus rapide. Choisissez qcow2 quand vous avez besoin spécifiquement de snapshots/fonctionnalités fichier sur un stockage en répertoire.

2) Proxmox peut-il importer un OVA directement ?

Proxmox peut travailler avec les disques contenus dans un OVA, mais vous finirez souvent par extraire l’OVA (c’est une archive tar) et convertir les VMDK vous-même. Cela vous donne plus de contrôle et moins de surprises.

3) Ma VM utilisait VMware PVSCSI. Que choisir sur Proxmox ?

Utilisez SATA pour le premier démarrage si vous êtes prudent, puis migrez vers VirtIO SCSI après l’installation des pilotes. PVSCSI est spécifique à VMware ; il n’existe pas d’équivalent direct à basculer.

4) Windows démarre sur SATA mais échoue sur VirtIO SCSI. Pourquoi ?

Le pilote VirtIO n’est pas installé/activé assez tôt pour le démarrage. Démarrez sur SATA, installez les pilotes VirtIO, puis changez le contrôleur et redémarrez.

5) Linux démarre mais le nom de NIC a changé et le réseau est down. Quelle est la correction propre ?

Mettez à jour votre configuration réseau pour correspondre au nouveau nom d’interface, ou utilisez des règles d’appariement basées sur l’adresse MAC. Évitez de coder en dur des hypothèses eth0 ; ce navire est parti il y a des années.

6) Quelle est l’erreur UEFI/BIOS la plus fréquente ?

Importer un invité installé en UEFI et le démarrer avec SeaBIOS (ou l’inverse). Confirmez avec le VMX ESXi et/ou la présence d’une EFI System Partition.

7) Ai-je besoin du QEMU guest agent ?

Besoin ? Non. Vouloir ? Oui. Il améliore le comportement d’arrêt, le reporting IP et l’automatisation, et réduit le nombre d’arguments « pourquoi Proxmox ment ».

8) Ma VM Windows importée a perdu son IP statique. Où est-elle passée ?

Windows traite la nouvelle NIC comme un adaptateur différent. L’ancien adaptateur peut toujours « posséder » la configuration IP mais être caché/déconnecté. Réaffectez l’IP à l’adaptateur actif et nettoyez les NIC obsolètes si nécessaire.

9) Puis-je laisser la VM sur SATA indéfiniment ?

Oui. Pour des charges légères, le surcoût SATA peut être négligeable. Pour de l’I/O intensif, VirtIO SCSI vaut le coup une fois la stabilité prouvée.

10) Comment savoir si le goulot est le stockage de l’hôte Proxmox ou l’invité ?

Commencez par les métriques hôte et la santé du stockage. Si l’hôte swappe, le CPU est saturé ou la latence stockage est élevée, changer le type de contrôleur invité ne vous aidera pas.

Conclusion : prochaines étapes réalisables aujourd’hui

Si vous voulez que la migration soit ennuyeuse (le plus grand compliment en ops), faites-la en deux phases : démarrabilité d’abord, performance ensuite. Faites correspondre le firmware. Attachez le disque sur un contrôleur conservateur. Faites-le démarrer. Ensuite installez les pilotes VirtIO, changez de bus et ne célébrez qu’après.

Étapes concrètes :

1. Choisissez une VM et exécutez le workflow « stabilité d’abord » : importer le disque, démarrer sur SATA, valider les services.
2. Installer le QEMU guest agent et faire une sauvegarde Proxmox au premier point « connu bon ».
3. Pour Windows : montez l’ISO VirtIO, installez les pilotes stockage + réseau, puis migrez vers VirtIO SCSI + NIC VirtIO.
4. Pour Linux : vérifiez que l’initramfs contient les modules VirtIO, convertissez fstab pour utiliser les UUID si nécessaire, puis changez les contrôleurs.
5. Une fois réussi : standardisez des templates et documentez votre mappage NIC/VLAN pour que la prochaine migration ne soit pas de l’archéologie.