Migrer une VM ESXi vers Proxmox sans vCenter : export OVF/OVA, import et correctifs de pilotes

Faits et contexte intéressants (ce qui explique les bizarreries)

• OVF est une spécification d’emballage, pas de la magie. OVF décrit la VM (CPU, RAM, périphériques). Les disques sont généralement des fichiers VMDK séparés ou empaquetés dans une OVA (une archive tar).
• OVA n’est que du tar. Si vous ne pouvez pas importer une OVA, vous pouvez presque toujours l’extraire avec des outils standards et travailler directement avec le VMDK.
• Le VMDK a des variantes. ESXi utilise couramment « monolithicSparse » ou « streamOptimized » dans les exports. Certains convertisseurs et importeurs détestent certains sous-types. « Stream optimized » apparaît souvent dans les exports OVF/OVA.
• VMXNET3 et PVSCSI sont des périphériques spécifiques à VMware. Ils sont excellents sur ESXi, mais Proxmox/QEMU ne les émulera pas nativement. Vous passerez à VirtIO ou Intel E1000, et cela entraîne des conséquences côté pilotes.
• VirtIO est rapide car paravirtualisé. Le système invité a besoin de pilotes. Linux les a généralement déjà ; Windows souvent pas (sauf s’il est moderne et a déjà VirtIO installé).
• UEFI vs BIOS est l’assassin silencieux. Les VMs ESXi peuvent être en BIOS ou EFI ; Proxmox gère les deux, mais il faut correspondre. Démarrer un système installé en BIOS avec un firmware UEFI est une méthode rapide pour obtenir « aucun périphérique de démarrage ».
• Les snapshots compliquent les exports. Si la VM a des snapshots, le « disque courant » est une chaîne de fichiers delta. Les outils d’export consolident parfois ; parfois non. Vérifiez toujours ce que vous avez exporté.
• Thin vs thick affecte le temps et le stockage. Un VMDK « thin » peut se convertir en image raw « thick » si vous n’y prenez pas garde, gonflant stockage et durée de migration.
• Proxmox utilise des modèles de périphériques QEMU. La « même » VM sur un nouvel hyperviseur reste du matériel différent. Les systèmes d’exploitation sont pointilleux sur l’identité de leur contrôleur de disque.

Décisions importantes avant d’intervenir

1) Décidez si vous pouvez tolérer une indisponibilité

Si vous n’avez pas de stockage partagé en réplication ou d’outil de migration au niveau bloc, un export OVF/OVA est par défaut une migration froide. Vous pouvez faire une approche semi-chaude (fenêtre d’arrêt, exporter, importer, tester, et basculer), mais ne prétendez pas que c’est une migration à chaud. Vos parties prenantes interpréteront « migration » comme « zéro interruption », parce que l’optimisme coûte moins cher que l’ingénierie.

2) Décidez du format de disque cible : raw vs qcow2

Sur Proxmox, les disques atterrissent généralement sur :

• ZFS : raw zvol est courant ; qcow2 est possible mais souvent inutile. Raw est plus simple et plus rapide pour la plupart des charges.
• LVM-thin : raw est typique (thin-provisioned au niveau du stockage).
• Stockage en répertoire (ext4/xfs) : qcow2 est pratique (snapshots), raw est correct (simplicité).

Mon avis : si votre stockage Proxmox est ZFS ou LVM-thin, préférez le raw. Si c’est un répertoire et que vous avez besoin de snapshots, utilisez le qcow2. Ne choisissez pas qcow2 parce que ça « sonne virtuel ». Choisissez-le parce que cela correspond à vos besoins en snapshots et performance.

3) Décidez des modèles de périphériques : VirtIO quand c’est possible

Pour les invités Linux : VirtIO pour disque et NIC fonctionne presque toujours. Pour Windows : VirtIO reste la bonne option, mais vous devez planifier l’installation des pilotes. Si c’est une VM Windows critique et que vous voulez que la migration soit sans histoire, démarrez initialement avec SATA + E1000, puis passez à VirtIO après installation des pilotes.

4) Décidez BIOS vs UEFI maintenant

Alignez le firmware avec le mode d’installation du système invité. Si la VM ESXi démarre via EFI, configurez Proxmox avec OVMF (UEFI). Si c’est BIOS, utilisez SeaBIOS. Vous pouvez convertir plus tard, mais c’est un projet distinct avec de vrais modes d’échec.

Idée paraphrasée de Gene Kranz : « Être dur et compétent » est un choix que vous faites avant l’échec, pas pendant.

Règles de diagnostic rapide (trouver le goulot en minutes)

Voici ce que vous faites quand la VM importée ne démarre pas, ne voit pas son disque ou n’a pas de réseau. Ne paniquez pas. Remontez la pile.

Premier point : confirmez que la VM a bien un disque amorçable attaché

• Vérifiez le matériel VM dans Proxmox : disque présent, bus correct (SATA/SCSI/VirtIO), ordre de démarrage correct.
• Vérifiez le stockage : l’image disque existe-t-elle là où Proxmox croit qu’elle se trouve ?

Deuxième point : confirmez que le firmware correspond à l’installation (UEFI vs BIOS)

• Installation BIOS + firmware UEFI = théâtre « pas de périphérique de démarrage ».
• Installation UEFI + firmware BIOS = pareil, avec de la confusion en plus.
• UEFI nécessite souvent un disque EFI dans Proxmox (petit périphérique séparé pour la NVRAM).

Troisième point : confirmez la disponibilité des pilotes pour le contrôleur de disque et la NIC choisis

• Si Windows fait un écran bleu tôt (INACCESSIBLE_BOOT_DEVICE) : pilote du contrôleur de disque manquant. Démarrez avec SATA, installez VirtIO, basculez ensuite.
• Si Linux tombe en initramfs : mappage erroné du périphérique racine ou initramfs sans les pilotes du nouveau contrôleur ; reconstruisez l’initramfs et/ou ajustez fstab/GRUB.

Quatrième point : confirmez que le réseau est correctement mappé

• Pont attaché ? Tag VLAN correct ? Pare-feu Proxmox bloquant ?
• OS invité : nom de NIC changé (Linux), métrique d’interface étrange (Windows), ou IP statique liée à l’ancien adaptateur.

Cinquième point : problèmes de performance après démarrage

• Vérifiez si vous avez utilisé par erreur une émulation IDE ou E1000 pour des charges à haut débit.
• Vérifiez le mode de cache et les iothreads. Contrôlez la latence du stockage sur le nœud Proxmox. Ce n’est rarement « Proxmox lent » et généralement « votre chemin de stockage est différent maintenant ».

Tâches pratiques avec commandes, signification des sorties et décisions

Ce sont des commandes exécutables et ce que vous faites avec les résultats. L’objectif est de remplacer les conjectures par des preuves.

Task 1: Identify the VM’s boot mode and controller types on ESXi

On the ESXi host (SSH enabled), find the VMX file and inspect it.

cr0x@server:~$ vim-cmd vmsvc/getallvms
Vmid   Name                 File                                      Guest OS       Version   Annotation
12     app-prod-01          [datastore1] app-prod-01/app-prod-01.vmx   ubuntu64Guest  vmx-14

Meaning: You have the datastore path to the VMX. You can now check firmware and device types.

Decision: If this VM is mission-critical, snapshot/consolidation strategy matters before export.

cr0x@server:~$ grep -E 'firmware|scsi|sata|nvme|ethernet|virtualDev' /vmfs/volumes/datastore1/app-prod-01/app-prod-01.vmx
firmware = "efi"
scsi0.virtualDev = "pvscsi"
ethernet0.virtualDev = "vmxnet3"

Meaning: EFI boot, PVSCSI disk controller, VMXNET3 NIC. None of those map 1:1 to Proxmox defaults.

Decision: Configure Proxmox VM with OVMF (UEFI). Plan to switch controllers to VirtIO (or temporarily SATA/E1000 for Windows).

Task 2: Check for snapshots (and don’t ignore them)

cr0x@server:~$ vim-cmd vmsvc/snapshot.get 12
Get Snapshot:
|-ROOT
|--Snapshot Name        : pre-patch
|--Snapshot Id          : 1
|--Snapshot Created On  : 2025-11-02
|--Snapshot State       : poweredOff

Meaning: Snapshots exist. Export behavior depends on tooling; you may export the chain or a consolidated image.

Decision: Prefer consolidating snapshots before export unless you have a specific reason not to. Exports are not where you want clever snapshot chains.

Task 3: Export without vCenter (practical options)

Without vCenter, you typically export by copying files from the datastore or using an OVF tool from a workstation that can reach the ESXi management IP.

If you already have an OVA/OVF export, skip ahead. If not, copying the VMDK(s) directly is often simplest.

cr0x@server:~$ ls -lh /vmfs/volumes/datastore1/app-prod-01/
total 22G
-rw-------    1 root     root        8.5K Nov  2 09:10 app-prod-01.vmx
-rw-------    1 root     root        2.0K Nov  2 09:10 app-prod-01.nvram
-rw-------    1 root     root        512B Nov  2 09:10 app-prod-01.vmsd
-rw-------    1 root     root        30G  Nov  2 09:11 app-prod-01-flat.vmdk
-rw-------    1 root     root        1.2K Nov  2 09:11 app-prod-01.vmdk

Meaning: You have a descriptor VMDK and a flat extent. That’s a common ESXi layout.

Decision: Copy both the .vmdk and -flat.vmdk if you’re doing a raw file copy. If you only copy the descriptor, you’ve copied a label, not the disk.

Task 4: Verify what kind of VMDK you’re holding

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

Meaning: This is a VMFS-style descriptor pointing at the flat extent. Good.

Decision: Conversion with qemu-img should work. If createType is streamOptimized, expect different behavior and possibly an intermediate conversion step.

Task 5: On Proxmox, confirm storage targets and free space

cr0x@server:~$ pvesm status
Name       Type     Status           Total            Used       Available        %
local      dir      active        19619632         2231040        16252232   11.37%
local-lvm  lvmthin  active       468582400        89366528       379215872   19.07%
zfspool    zfspool  active       950000000       410000000       540000000   43.16%

Meaning: You have multiple storage backends. Space is available, but not infinite.

Decision: Choose the target storage based on performance and snapshot needs. Don’t drop a database VM onto slow directory storage because it’s “easy.”

Task 6: Extract an OVA (if that’s what you have)

cr0x@server:~$ mkdir -p /var/tmp/ova/app-prod-01 && tar -xvf app-prod-01.ova -C /var/tmp/ova/app-prod-01
app-prod-01.ovf
app-prod-01.mf
app-prod-01-disk1.vmdk

Meaning: You now have the OVF descriptor and the VMDK(s).

Decision: Ignore the manifest file if you must, but if you’re in a regulated environment, checksum validation is not optional theater—it’s the audit trail.

Task 7: Inspect the OVF for device expectations

cr0x@server:~$ grep -nE 'OperatingSystemSection|VirtualSystemType|ResourceType|rasd:ResourceSubType' /var/tmp/ova/app-prod-01/app-prod-01.ovf | head
25:  <OperatingSystemSection ovf:id="94">
44:  <vssd:VirtualSystemType>vmx-14</vssd:VirtualSystemType>
120: <rasd:ResourceType>17</rasd:ResourceType>
121: <rasd:ResourceSubType>vmxnet3</rasd:ResourceSubType>

Meaning: It’s describing VMware hardware types (vmxnet3). Proxmox won’t honor that device model.

Decision: Treat OVF as metadata, not a promise. You’ll define the target hardware explicitly in Proxmox.

Task 8: Convert VMDK to raw or qcow2 on Proxmox

Pick raw for ZFS/LVM-thin targets; qcow2 for directory targets with snapshots.

cr0x@server:~$ qemu-img info /var/tmp/ova/app-prod-01/app-prod-01-disk1.vmdk
image: /var/tmp/ova/app-prod-01/app-prod-01-disk1.vmdk
file format: vmdk
virtual size: 30 GiB (32212254720 bytes)
disk size: 8.2 GiB
cluster_size: 65536
Format specific information:
    cid: 12345678
    create type: streamOptimized

Meaning: streamOptimized disk. Conversion works, but be mindful of sparse behavior.

Decision: Convert with qemu-img convert. If you see corruption or failures, convert to raw first, then import.

cr0x@server:~$ qemu-img convert -p -f vmdk -O raw /var/tmp/ova/app-prod-01/app-prod-01-disk1.vmdk /var/tmp/app-prod-01-disk1.raw
    (100.00/100%)

Meaning: You have a raw disk image ready to import. Progress hitting 100% is necessary, not sufficient—still validate boot later.

Decision: If your storage backend supports thin provisioning at the block layer (ZFS zvol, LVM-thin), import raw into that backend.

Task 9: Create a Proxmox VM shell (don’t attach disks yet)

cr0x@server:~$ qm create 120 --name app-prod-01 --memory 8192 --cores 4 --cpu host --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci --ostype l26 --machine q35
create VM 120: success

Meaning: VM exists with VirtIO NIC and VirtIO SCSI controller. q35 machine type is modern and plays well with UEFI.

Decision: If the source is UEFI, set OVMF now. If BIOS, keep SeaBIOS.

Task 10: Configure UEFI (OVMF) and add an EFI disk when needed

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

Meaning: VM will boot with UEFI firmware and has an EFI vars disk.

Decision: If Secure Boot wasn’t used on ESXi, keep pre-enrolled-keys=0 to avoid signing drama.

Task 11: Import the disk into Proxmox-managed storage

cr0x@server:~$ qm importdisk 120 /var/tmp/app-prod-01-disk1.raw zfspool --format raw
importing disk '/var/tmp/app-prod-01-disk1.raw' to VM 120 ...
transferred 32212254720 bytes in 94 seconds (342.7 MiB/s)
Successfully imported disk as 'zfspool:vm-120-disk-0'

Meaning: Disk is now a storage-managed volume. This is what you want for backups, replication, and sanity.

Decision: Attach the imported disk on the right bus. For Linux, VirtIO SCSI is usually fine. For Windows without VirtIO drivers, start with SATA.

Task 12: Attach disk and set boot order

cr0x@server:~$ qm set 120 --scsi0 zfspool:vm-120-disk-0,discard=on,ssd=1 --boot order=scsi0
update VM 120: -scsi0 zfspool:vm-120-disk-0,discard=on,ssd=1 -boot order=scsi0

Meaning: Disk attached as SCSI (VirtIO SCSI controller) and set as the first boot device.

Decision: If boot fails and it’s a Windows guest, switch to SATA temporarily and install VirtIO drivers.

Task 13: Start the VM and watch the console like you mean it

cr0x@server:~$ qm start 120

cr0x@server:~$ qm terminal 120
starting serial terminal on interface serial0 (press Ctrl+O to exit)
[    0.000000] Linux version 5.15.0-...
[    3.214567] virtio_scsi 0000:00:05.0: 1/0/0 default/read/poll queues
...

Meaning: If you see virtio drivers initializing, you’re on a good path. If it drops into initramfs, you need root device and initramfs fixes.

Decision: Don’t “wait and see” for 20 minutes. Boot failures don’t heal with time.

Task 14: Validate disk visibility inside Linux

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
NAME   SIZE TYPE FSTYPE MOUNTPOINT
sda     30G disk
├─sda1  512M part vfat   /boot/efi
├─sda2    1G part ext4   /boot
└─sda3 28.5G part ext4   /

Meaning: Partitions present and mounted. The OS sees the disk.

Decision: If device names changed (e.g., from /dev/sda to /dev/vda), confirm /etc/fstab uses UUIDs, not device names.

Task 15: Validate network device and link state

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
ens18            UP             52:54:00:12:34:56

Meaning: Interface is up. Name likely changed versus ESXi. That’s normal.

Decision: If the interface name changed and your network config references the old name, update netplan/systemd-networkd/ifcfg accordingly.

Task 16: On Proxmox, check bridge and VLAN tagging

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

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

Meaning: Standard Linux bridge. VLAN tags can be set per VM NIC or via VLAN-aware bridge config.

Decision: If you need VLAN trunking, set bridge-vlan-aware yes and configure tags intentionally. Don’t guess; your switch won’t forgive you.

Task 17: Confirm Proxmox sees the VM config you intended

cr0x@server:~$ qm config 120
bios: ovmf
boot: order=scsi0
cores: 4
cpu: host
efidisk0: zfspool:vm-120-disk-1,size=4M,pre-enrolled-keys=0
memory: 8192
name: app-prod-01
net0: virtio=52:54:00:12:34:56,bridge=vmbr0
ostype: l26
scsi0: zfspool:vm-120-disk-0,discard=on,ssd=1
scsihw: virtio-scsi-pci
machine: q35

Meaning: This is the canonical truth. If the GUI differs, the config still wins.

Decision: Keep this output in your change record. It’s how you later prove what changed.

Blague #1 : OVF est comme un manifeste d’expédition : il vous dit ce qui devrait être dans la boîte, pas si la boîte a survécu au chariot élévateur.

Checklists / plan étape par étape (sécure et ennuyeusement correct)

Checklist pré-migration (source ESXi)

1. Documenter le matériel de la VM : firmware (EFI/BIOS), contrôleur de disque, type de NIC, nombre de disques, configuration IP.
2. Nettoyer les snapshots : consolider ou au moins comprendre la chaîne. Exporter une chaîne de snapshots, c’est là que les données se perdent.
3. Quiescer l’invité : arrêt applicatif si possible (bases de données, files). Si impossible, au moins arrêter proprement la VM.
4. Collecter les pilotes : pour Windows, préparez l’ISO des pilotes VirtIO. Pour Linux, assurez-vous que l’outil de génération d’initramfs existe dans l’invité.
5. Décider la méthode de bascule : nouvelle IP ou même IP ? Modifications DNS ? Réservations MAC ? Règles de pare-feu ?

Checklist d’exécution de la migration (Proxmox)

1. Créer une VM « coquille » avec CPU/RAM proche de la source. Ne pas surajuster immédiatement.
2. Définir le firmware (OVMF vs SeaBIOS) pour correspondre à la source.
3. Importer le disque dans le backend de stockage choisi.
4. Attacher le disque avec un contrôleur sensé (VirtIO SCSI pour Linux ; SATA d’abord pour Windows si pilotes manquants).
5. Définir explicitement l’ordre de démarrage.
6. Démarrer avec la console ouverte ; capturer les erreurs tôt.
7. Corriger les problèmes de démarrage/pilotes (voir sections ci‑dessous).
8. Corriger le mapping réseau, confirmer la connectivité, confirmer hostname/DNS.
9. Supprimer VMware Tools si approprié, installer l’agent qemu-guest-agent.
10. Valider la charge : I/O disque, vérifications applicatives, logs, monitoring.

Checklist post-migration (stabilité et opérabilité)

1. Sauvegardes : assurez-vous que les jobs de sauvegarde Proxmox incluent la VM et qu’un test de restauration fonctionne.
2. Supervision : confirmez que la VM est dans les bons alertes, avec les bons endpoints d’agent.
3. Synchronisation du temps : vérifiez NTP/chrony ; ne comptez pas sur la « magie » du temps de l’hyperviseur.
4. Sanity performance : confirmez que vous utilisez VirtIO et pas IDE. Vérifiez l’ordonnanceur I/O et les réglages discard/TRIM si applicable.
5. Journal de changement : stockez la config matérielle « avant » et « après » de la VM et les détails réseau.

Correction des pilotes et du démarrage : Windows et Linux

Windows : la voie sûre (démarrer d’abord, optimiser ensuite)

Si Windows était sur ESXi avec PVSCSI et VMXNET3, il ne saura pas automatiquement quoi faire avec VirtIO. Le mode d’échec est généralement un BSOD au démarrage : INACCESSIBLE_BOOT_DEVICE. C’est Windows qui dit : « Beau nouveau contrôleur. Je ne parle pas ce dialecte. »

Séquence recommandée pour Windows

1. Importer le disque et l’attacher en SATA (ou IDE si vraiment nécessaire, mais SATA est moins pénible).
2. Modèle NIC : utiliser E1000 ou VirtIO si le pilote est déjà installé. Si vous avez besoin de connectivité initiale sans pilotes, E1000 est les roues d’entraînement.
3. Démarrer Windows avec succès.
4. Monter l’ISO des pilotes VirtIO et installer pilotes stockage + réseau.
5. Basculer le contrôleur disque en VirtIO SCSI (ou VirtIO block), redémarrer, vérifier.
6. Basculer la NIC en VirtIO, redémarrer, vérifier.

En termes Proxmox, cela ressemble souvent à : commencer avec --sata0 et e1000, puis migrer vers --scsi0 et NIC VirtIO.

cr0x@server:~$ qm set 130 --name win-app-01 --memory 16384 --cores 6 --cpu host --net0 e1000,bridge=vmbr0 --sata0 zfspool:vm-130-disk-0 --boot order=sata0
update VM 130: -name win-app-01 -memory 16384 -cores 6 -cpu host -net0 e1000,bridge=vmbr0 -sata0 zfspool:vm-130-disk-0 -boot order=sata0

Meaning: You chose compatibility. It boots first, then you modernize.

Decision: If the VM is a domain controller or has strict NIC bindings, plan the adapter transition carefully to avoid losing network identity.

Linux : généralement facile, jusqu’à ce que ça ne le soit plus

Linux a tendance à démarrer sur VirtIO sans drame. Quand il ne le fait pas, les raisons sont cohérentes :

• /etc/fstab référence /dev/sdX au lieu d’UUID/LABEL et le nom du périphérique a changé.
• initramfs manque de modules pour le nouveau contrôleur (moins courant sur les distributions modernes, mais toujours présent sur les images minimales).
• mismatch du mode de démarrage (UEFI vs BIOS).

Correctif : confirmer que fstab utilise des UUID

cr0x@server:~$ grep -vE '^\s*#|^\s*$' /etc/fstab
UUID=3d2f7a2f-aaaa-bbbb-cccc-111122223333 / ext4 defaults 0 1
UUID=9f8e7d6c-aaaa-bbbb-cccc-444455556666 /boot ext4 defaults 0 2
UUID=1A2B-3C4D /boot/efi vfat umask=0077 0 1

Meaning: UUID-based mounts. Good. Device renaming won’t break boot.

Decision: If you see /dev/sda1 style mounts, fix them before you reboot again.

Correctif : reconstruire l’initramfs (exemple Debian/Ubuntu)

cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.15.0-92-generic

Meaning: initramfs refreshed; it will include currently-needed modules.

Decision: If the VM only boots with one controller type, rebuild initramfs while it’s in the working state, then switch controllers.

Correctif : réinstaller GRUB après un mismatch de firmware ou un changement de mapping disque

Pour les installations BIOS sur un nouveau contrôleur virtuel, réinstaller GRUB peut être le marteau le plus simple.

cr0x@server:~$ grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.15.0-92-generic
done

Meaning: Bootloader is re-established for BIOS mode on that disk.

Decision: If you’re actually UEFI, don’t do BIOS grub-install. You’ll just create a second boot confusion layer.

Blague #2 : UEFI, c’est génial jusqu’à ce que ça ne le soit plus, auquel cas ça devient une danse interprétative exécutée par le firmware.

Réseau : bridges, VLAN et surprises de MAC

Choix du bridge : attachez la VM au bon monde

Le réseau Proxmox est du réseau Linux. C’est un compliment et un avertissement.

• vmbr0 est typiquement votre bridge LAN.
• Le marquage VLAN peut se faire par NIC dans Proxmox (tag=123) ou en utilisant des bridges VLAN-aware.
• Bonding/LACP se configure sur l’hôte ; la VM voit juste une NIC.

cr0x@server:~$ qm set 120 --net0 virtio=52:54:00:12:34:56,bridge=vmbr0,tag=120,firewall=1
update VM 120: -net0 virtio=52:54:00:12:34:56,bridge=vmbr0,tag=120,firewall=1

Meaning: VM NIC is on VLAN 120, firewall enabled at Proxmox layer.

Decision: If you enable Proxmox firewall, define rules intentionally. Otherwise you’ll “migrate” the VM into a self-imposed air gap.

Adresse MAC et licences

Certaines applications lient les licences aux adresses MAC. Certaines solutions de sécurité lient aussi la confiance à celles-ci. Proxmox générera une nouvelle MAC sauf si vous la définissez.

cr0x@server:~$ qm config 120 | grep -E '^net0'
net0: virtio=52:54:00:12:34:56,bridge=vmbr0

Meaning: You have a stable MAC configured in the VM config.

Decision: If you need to preserve the ESXi MAC, set it explicitly here before first boot to avoid “new NIC” behavior in the guest.

Changements de nom de NIC sous Linux et règles persistantes

Sur ESXi, votre NIC pouvait être ens160. Sur Proxmox, cela peut être ens18 ou enp0s18. Si votre distro utilise netplan ou systemd-networkd, la logique de renommage peut vous mordre.

cr0x@server:~$ journalctl -b | grep -iE 'rename|ens|enp' | head
systemd-udevd[312]: renamed network interface eth0 to ens18
systemd-networkd[401]: ens18: Link UP

Meaning: Rename occurred; systemd sees the interface.

Decision: Update your network config to match the new name, or pin naming using match rules by MAC address.

Trois mini-histoires en entreprise (comment ça foire en vrai)

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

L’entreprise disposait d’un hôte ESXi autonome exécutant une poignée de VMs « temporaires ». Vous savez déjà où ça va : ces VMs temporaires alimentaient des revenus depuis des années, comme une rallonge oubliée derrière un meuble.

Quelqu’un a finalement acheté un cluster Proxmox. Le mandat était simple : migrer la VM la plus critique pendant un week-end, pas de vCenter, et ne pas dépenser. L’ingénieur a exporté une OVA depuis ESXi, l’a importée, et la VM a démarré. C’est à ce moment que tout le monde s’est détendu, ce qui est historiquement le moment le plus dangereux en opérations.

Lundi matin, les utilisateurs ont signalé des échecs intermittents. L’application était « up », mais la moitié des requêtes échouaient. La cause racine n’était ni CPU ni mémoire. C’était le réseau : la VM avait deux NIC sur ESXi — une pour le frontend, une pour le backend — et les métadonnées OVA n’ont pas mappé les rôles des périphériques. Sur Proxmox, l’ordre des NIC a été inversé, l’OS a gardé ses affectations IP statiques, et l’application a tenté de rejoindre les services backend via le VLAN frontend.

Ça s’est empiré : les checks de monitoring étaient verts car le endpoint de santé était sur l’interface frontend. Les échecs backend n’apparaissaient que dans les transactions métier. L’hypothèse « si ça boot et ça ping, c’est bon » a coûté une panne.

La correction a été ennuyeuse : mapper les NIC intentionnellement (bridge + tag VLAN), définir les MAC, vérifier les tables de routage et valider le graphe de dépendances applicatives réel — pas juste ICMP. La leçon a marqué car elle a été douloureuse et publique.

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

Une autre équipe a traité la migration comme une opportunité de performance. Ils ont converti tous les disques en qcow2 parce que « les snapshots sont utiles » et activé tous les réglages de cache qui semblaient rapides. Ils ont aussi basculé d’emblée des VMs Windows en VirtIO pour disque et NIC au premier démarrage, puisqu’ils l’avaient fait une fois en labo.

Les résultats furent impressionnants, à la façon d’une usine de feux d’artifice. Certaines VMs ne démarrèrent pas (problème de pilote). D’autres démarrèrent mais eurent des pics de latence étranges sous charge. L’équipe a poursuivi des fantômes dans l’OS invité pendant des jours — antivirus, mises à jour Windows, « peut-être que SQL fait quelque chose ».

Le vrai problème était un empilement de petits choix : qcow2 sur un stockage en répertoire posé sur un contrôleur RAID avec cache volatile, plus un caching writeback agressif dans QEMU, plus aucune garantie d’onduleur. Ça marchait jusqu’à ce que ça ne marche plus. La latence grimpait pendant les flushs d’hôte, et le profil de risque était inadapté aux charges état-pleines.

Ils sont revenus à des volumes raw sur ZFS zvols pour les bases, utilisé un caching conservateur, et la performance s’est stabilisée immédiatement. Les snapshots sont passés aux snapshots natifs ZFS où ils avaient leur place. L’optimisation n’est pas mauvaise ; l’optimisation sans limites l’est.

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

Une entreprise régulée devait migrer une VM ESXi exécutant un service métier avec des dépendances anciennes et un éditeur qui n’évoluait plus. L’environnement n’avait pas vCenter. L’hôte ESXi était un « pet », pas du cattle, avec du stockage local et une équipe facilities nerveuse.

Le SRE de garde a insisté sur un processus terne : capturer les paramètres VMX, enregistrer les checksums des disques après export, importer dans Proxmox avec le même mode de démarrage, et garder l’ancienne VM éteinte mais intacte pendant une semaine complète. Ils ont aussi exigé un démarrage de test sur un VLAN isolé avant le basculement production.

Pendant les tests isolés, la VM démarra mais ne pouvait pas joindre son serveur de licences. Le problème n’était pas le réseau ; c’était la dérive temporelle. La VM reposait discrètement sur la synchronisation temporelle de VMware Tools, et Proxmox ne reproduisait pas exactement ce comportement. Le handshake de licence échouait quand le skew dépassait la tolérance.

Comme l’équipe avait testé en isolation et disposait d’un plan de rollback, ils ont corrigé NTP/chrony correctement, documenté le comportement, puis basculé proprement. Rien de spectaculaire ne s’est produit en production, ce qui est la plus haute forme de compliment pour un opérationnel.

Erreurs fréquentes : symptôme → cause → correctif

1) Symptôme : « Aucun périphérique de démarrage » immédiatement au démarrage

Cause racine : mismatch BIOS/UEFI, disque EFI manquant, ou ordre de démarrage incorrect.

Correctif : Alignez le firmware avec la source (OVMF pour EFI, SeaBIOS pour BIOS). Ajoutez efidisk0 pour OVMF. Définissez un ordre de démarrage explicite.

2) Symptôme : BSOD Windows INACCESSIBLE_BOOT_DEVICE

Cause racine : le contrôleur de stockage a changé en VirtIO sans pilote installé.

Correctif : Attachez le disque en SATA, démarrez, installez les pilotes VirtIO stockage, puis basculez en VirtIO SCSI et redémarrez.

3) Symptôme : Linux tombe en initramfs ou shell d’urgence

Cause racine : système de fichiers racine introuvable à cause de changements de nom de périphérique, initramfs sans modules, ou fstab pointant vers /dev/sdX.

Correctif : Utilisez UUID dans fstab, reconstruisez initramfs, vérifiez que la config GRUB pointe vers la bonne racine.

4) Symptôme : la VM démarre, mais pas de connectivité réseau

Cause racine : mauvais bridge/tag VLAN, règles de pare-feu Proxmox, changements de nom de NIC invité, ou IP statique Windows liée à l’ancien adaptateur.

Correctif : Vérifiez bridge et tags VLAN sur l’hôte ; désactivez temporairement le pare-feu Proxmox pour isoler ; corrigez la config réseau invité ; préservez la MAC si nécessaire.

5) Symptôme : le disque est présent dans Proxmox mais l’invité voit 0 octet ou système de fichiers corrompu

Cause racine : copie incomplète des extents VMDK, chaîne de snapshots non consolidée, ou erreur de conversion depuis streamOptimized.

Correctif : Ré-exportez après consolidation des snapshots ; vérifiez que le descriptor et les fichiers flat ont été copiés ; reconvertissez via un intermédiaire raw ; validez avec des checksums.

6) Symptôme : la VM est lente, surtout I/O

Cause racine : utilisation d’IDE/SATA pour une charge nécessitant VirtIO, mauvais mode de cache, mismatch backend stockage, ou absence d’iothread pour disques très sollicités.

Correctif : Déplacez les disques vers VirtIO SCSI avec iothreads si approprié, utilisez des volumes natifs stockage (ZFS/LVM-thin), révisez les réglages de cache, mesurez la latence sur l’hôte.

7) Symptôme : l’application fonctionne mais la licence casse

Cause racine : changement d’adresse MAC, dérive d’horloge, ou changement d’empreinte matérielle.

Correctif : Préservez la MAC si nécessaire, corrigez NTP, documentez le nouveau profil matériel virtuel et contactez l’éditeur si inévitable.

FAQ

1) Ai‑je besoin de vCenter pour exporter un OVF/OVA ?

Non. vCenter facilite la tâche, mais vous pouvez exporter en copiant les fichiers VM depuis le datastore ESXi ou en utilisant un outil OVF contre l’hôte ESXi directement.

2) Est‑il préférable d’exporter OVF/OVA ou de copier les VMDK ?

Si vous pouvez arrêter proprement, copier les fichiers VMDK est souvent plus simple et plus transparent. OVF/OVA est pratique pour empaqueter, mais peut masquer des bizarreries de format disque (comme streamOptimized).

3) Proxmox peut‑il importer OVF directement ?

Pas d’une manière sur laquelle vous devriez parier en production. Traitez OVF comme un descripteur ; extrayez les disques et importez‑les avec qm importdisk après conversion si nécessaire.

4) Dois‑je utiliser qcow2 ou raw sur Proxmox ?

Raw sur ZFS zvols ou LVM‑thin est généralement le bon choix pour la performance et la simplicité. qcow2 convient sur stockage en répertoire lorsque vous voulez des snapshots fichier.

5) Ma VM Linux démarre sur ESXi mais échoue sur Proxmox avec initramfs. Pourquoi ?

Parce que le « matériel » a changé : modèle de contrôleur, nommage des disques, ou firmware. Corrigez fstab pour utiliser UUID, reconstruisez l’initramfs et confirmez le mode BIOS/UEFI.

6) Comment gérer en sécurité les pilotes VirtIO sous Windows ?

Démarrez Windows sur SATA d’abord, installez les pilotes VirtIO depuis un ISO attaché, puis basculez le contrôleur disque en VirtIO SCSI et la NIC en VirtIO. Un changement à la fois, avec redémarrages intermédiaires.

7) Dois‑je désinstaller VMware Tools ?

Généralement oui, à terme. Il peut interférer avec la synchronisation du temps et certains comportements de périphériques. Ne faites pas de cela votre première action le jour de la migration ; stabilisez d’abord le démarrage et le réseau.

8) Quid du support de l’agent invité Proxmox ?

Installez le QEMU guest agent dans la VM une fois qu’elle est stable. Il améliore l’arrêt, le reporting IP et certains workflows de sauvegarde. C’est de l’hygiène opérationnelle.

9) Puis‑je garder la même adresse IP après migration ?

Oui, mais seulement après vous être assuré que la VM est sur le bon VLAN/bridge et que votre plan de bascule évite les doublons IP. Si possible, testez d’abord avec une IP temporaire.

10) Quel est le plus grand « inconnu inconnu » dans ces migrations ?

La dépendance à des comportements spécifiques VMware : synchronisation du temps, ordre des NIC, pilotes personnalisés et hypothèses sur les snapshots. Auditez cela en amont et la migration devient routinière.

Conclusion : étapes suivantes qui réduisent réellement le risque

Si vous ne retenez que trois actions de ce guide, retenez celles‑ci :

1. Alignez le mode de démarrage (UEFI vs BIOS) avant le premier démarrage sur Proxmox. C’est le gain le moins cher.
2. Démarrez pour compatibilité d’abord (surtout Windows), puis migrez vers VirtIO une fois les pilotes installés.
3. Prouvez la correction avec des commandes : présence du stockage, ordre de démarrage, état des interfaces et journaux. Votre mémoire mentira sous pression.

Opérationnellement, considérez la migration comme deux livrables : amorçabilité et opérabilité. Obtenir un prompt de connexion n’est pas la ligne d’arrivée. Sauvegardes, monitoring, synchronisation du temps et performance vous évitent de retourner sur cette VM à 3h du matin avec un public.