Comment migrer de VMware ESXi vers Proxmox VE (pas à pas) : VMs, disques, VLANs, temps d’arrêt

Ce que vous migrez réellement (ce n’est pas que des VMs)

Un parc ESXi est un ensemble d’accords que vous n’avez pas consignés : quels VLAN existent, quelles NIC sont en trunk, quels datastores sont « assez rapides »,
quelles VMs sont autorisées à utiliser un ancien matériel virtuel, et lesquelles prennent des snapshots en douce depuis le trimestre dernier.
Proxmox exécutera volontiers vos charges, mais il ne préservera pas ces accords à moins que vous ne les reconstruisiez délibérément.

Pensez à la migration comme quatre mouvements indépendants :

• Sémantique de calcul : exposition du modèle CPU, comportement NUMA, type de contrôleur disque, firmware (BIOS vs UEFI), secure boot, timers.
• Sémantique du stockage : thin vs thick, snapshots, ordre d’écriture, profondeur de file d’attente, TRIM/discard, alignement, paramètres de cache.
• Sémantique réseau : balises VLAN, MTU, LACP, apprentissage MAC, mode promiscuitif (rarement nécessaire, souvent « activé accidentellement »).
• Sémantique opérationnelle : sauvegardes, restaurations, supervision, fenêtres de maintenance et procédure de rollback quand une VM ne démarre pas.

Votre objectif n’est pas « réussir à démarrer ». Votre objectif est « rendre ça ennuyeux à nouveau ». L’ennui est une fonctionnalité.

Faits et contexte qui changent les décisions

Voici les petits éléments concrets d’historique et de comportement qui comptent dans la planification. Ignorez-les et vous les apprendrez de la manière coûteuse.

1. VMDK est plus ancien que la plupart de vos outils. Les formats de disque virtuel de VMware ont évolué avec VMFS et les chaînes de snapshots ; les VM de longue durée portent souvent des hypothèses héritées (comme les types de contrôleurs).
2. QCOW2 n’a pas été conçu comme un « format performance ». Il est flexible (snapshots, compression), mais raw sur ZFS ou LVM-thin peut être plus simple et plus rapide pour de nombreuses charges en production.
3. Virtio est devenu la norme de facto pour les performances KVM car l’émulation est coûteuse. Si vous laissez la NIC et le disque en équivalents e1000/IDE « par sécurité », vous paierez ce choix indéfiniment.
4. OVF/OVA visaient la portabilité, mais la vraie portabilité dépend des drivers. Exporter un appliance ne garantit pas qu’il démarre proprement sur un autre matériel virtuel.
5. Les snapshots ESXi ne sont pas des sauvegardes, et la structure des fichiers le montre. Une chaîne de delta disks se comporte comme une tour de Jenga : stable jusqu’à ce que vous la heurtiez.
6. Le modèle de cluster de Proxmox est volontairement simple. Il est conçu pour qu’une petite équipe puisse l’exploiter sans acheter une plane de gestion ; cette simplicité devient votre responsabilité pour la conception réseau et stockage.
7. Les bridges VLAN-aware sous Linux sont matures. Ce n’est plus 2008. Un bridge Linux avec filtrage VLAN peut remplacer de nombreux cas d’usage de vSwitch proprement—si vous mappez correctement les tags.
8. ZFS a une mémoire longue. Il vous protégera contre la corruption silencieuse, mais il conservera aussi fidèlement vos mauvaises décisions (comme un recordsize inadapté pour des bases de données) jusqu’à ce que vous le régliez.

Une citation pour vous garder honnête et justifier la paranoïa de votre plan de changement :
L’espoir n’est pas une stratégie. — James R. Schlesinger

Inventaire pré-vol : quoi mesurer avant de toucher quoi que ce soit

Si vous ne pouvez pas lister vos VLANs, l’utilisation des datastores et le firmware de démarrage des VMs, vous ne migrez pas — vous jouez et ajouterez des étapes.
Le travail d’inventaire n’est pas glamour. Ni l’examen d’incident.

Ce qu’il faut inventorier (minimum)

• Liste des VM : nom, CPU, RAM, disques, nombre de NIC, OS, criticité, propriétaire, fenêtre de maintenance, RPO/RTO.
• Disposition des disques : quels VMDK sont thin, chaînes de snapshots, et le datastore où ils résident.
• Firmware : BIOS vs EFI. Le secure boot compte plus que vous ne le pensez.
• Réseau : port groups, IDs VLAN, ports trunk, MTU, LACP, uplinks.
• Périphériques spéciaux : passthrough USB, ports série, GPU, dongles, passthrough de NIC physiques.
• Dépendances temporelles : sources NTP, contrôleurs de domaine, serveurs de licences.
• Sauvegardes : ce qui peut être restauré, à quelle vitesse, et si quelqu’un l’a testé cette année.

Blague n°1 : La seule chose plus permanente qu’une règle de pare-feu « temporaire » est un snapshot VM « temporaire ».

Décidez à l’avance : migration froide ou partielle en ligne ?

Pour ESXi vers Proxmox, la « migration à chaud » n’est pas le chemin par défaut sauf si vous introduisez un outil intermédiaire de réplication.
Pour la plupart des environnements, l’approche fiable est la migration froide par VM (arrêt, export/copie, import, démarrage).
Votre temps d’arrêt est dominé par la copie des disques et la validation post-démarrage.

Vous pouvez réduire le temps d’arrêt avec :

• Pré-peuplement des disques pendant que la VM tourne (copier le VMDK vers la zone de staging, puis une synchronisation finale pendant le downtime).
• Réplication au niveau application (réplication DB, synchronisation de fichiers), puis basculement des points d’accès.
• Parallélisme (plusieurs VMs par fenêtre), mais ne surchargez pas votre stockage puis faites semblant d’être surpris.

Architecture cible sur Proxmox : stockage, types CPU, modèle réseau

Proxmox vous donne assez de corde pour construire une excellente plateforme ou une panne artisanale. Choisissez une baseline et standardisez-la.

Calcul : choisissez la compatibilité d’abord, puis la performance

Pour des clusters avec du matériel mixte, commencez par un type CPU conservateur (x86-64-v2 ou un baseline similaire) afin que les VMs puissent migrer entre nœuds plus tard.
Si vous n’avez qu’un nœud par VM pour toujours, oui, utilisez host pour la performance maximale. Mais soyez honnête sur votre futur.

• Bus disque : VirtIO SCSI (single) ou VirtIO Block ; évitez IDE/SATA sauf si vous bootstrappez un OS ancien.
• Modèle NIC : VirtIO ; gardez e1000 seulement pour les installateurs anciens et retirez-le ensuite.
• Firmware : faites correspondre la VM source (BIOS vs OVMF/UEFI). Ne « modernisez » pas durant la migration sauf si vous aimez déboguer deux fois.

Stockage : choisissez un backend principal et tenez-vous-y

Backends Proxmox communs dans les projets de migration :

• ZFS : intégrité forte, snapshots, réplication ; excellent si vous comprenez les besoins RAM et l’amplification d’écriture.
• LVM-thin : simple, rapide, familier ; moins de réglages ; les snapshots existent mais se comportent différemment de ZFS.
• Ceph : puissant, mais migrer vers Proxmox n’est pas le moment d’apprendre le stockage distribué depuis zéro.
• NFS/iSCSI : correct pour le stockage partagé ; les performances dépendent du réseau et du tuning du serveur.

Prise de position : si c’est votre première migration Proxmox et que vous n’avez pas déjà une équipe stockage, utilisez ZFS en miroir/RAIDZ
ou LVM-thin sur RAID matériel. Réservez Ceph pour le moment où vous pouvez vous permettre de bien le maîtriser.

Réseau : adoptez les bridges Linux et soyez explicite

Proxmox utilise le réseau Linux en interne. C’est une bonne nouvelle : c’est prévisible, scriptable et débogable avec des outils standards.
Votre migration dépendra de la recréation des port groups ESXi en tant que bridges Linux VLAN-aware (ou bridges séparés), puis d’attacher les NICs des VMs avec les bons tags.

VLANs, bridges, bonds : cartographier le réseau ESXi vers Proxmox

ESXi cache une partie de la complexité derrière « vSwitch » et « port group ». Linux vous montre les rouages. C’est une fonctionnalité jusqu’à ce que vous mal étiquetiez le trafic.

Traduire le modèle

• ESXi vSwitch uplinks → Linux bond (optionnel) ou une NIC physique
• Port group avec VLAN ID → port du bridge Proxmox avec tag défini, ou bridge VLAN-aware + tag VLAN par VM
• Comportement trunk/native VLAN → filtrage VLAN du bridge Linux + configuration switchport doit être cohérente

Patron recommandé : un bridge VLAN-aware par hôte

Créez vmbr0 attaché à votre uplink trunk (ou bond), activez VLAN-aware, et taguez par NIC VM.
Cela garde la configuration de l’hôte stable pendant que vous changez les tags par VM durant la migration.

MTU et jumbo frames : décidez avec des preuves

Si vous avez besoin de MTU 9000 pour le stockage (iSCSI/NFS/Ceph), réglez-le de bout en bout : switchports, NICs physiques, bonds, bridges et interfaces VM selon le besoin.
Un seul lien à 1500 crée un cauchemar « ça marche parfois ». Ce sont les meilleures sortes de cauchemars : intermittents.

Stratégies de migration des disques (choisissez votre douleur)

Il existe trois manières courantes d’acheminer un disque d’ESXi vers Proxmox. Aucune n’est universellement meilleure ; choisissez selon la taille, la bande passante et votre tolérance au downtime.

Stratégie A : exporter OVF/OVA, importer dans Proxmox

Idéal quand : vous voulez un export empaqueté et vos VMs sont simples.
Pire quand : vous avez de très gros disques ou souhaitez un contrôle strict des formats et des contrôleurs.

• Avantages : conteneur standardisé, facile à archiver.
• Inconvénients : peut être lent ; l’import peut ne pas préserver toutes les nuances ; il faut toujours valider drivers/contrôleur.

Stratégie B : copier le VMDK et convertir avec qemu-img

Idéal quand : vous voulez du contrôle, vous avez un accès shell, vous voulez choisir raw ou qcow2, et vous tenez à la performance.

• Avantages : transparent, scriptable, fonctionne sans outils sophistiqués.
• Inconvénients : les chaînes de snapshots demandent de la prudence ; le temps de conversion peut être significatif ; nécessite de planifier l’espace disque.

Stratégie C : réplication au niveau bloc ou déplacement basé sur le stockage

Idéal quand : vous avez déjà de la réplication (réplication DB, synchronisation de fichiers) ou du stockage partagé que vous pouvez ré-assigner.
Ce n’est généralement pas une histoire « migration générique de VM » ; c’est spécifique à l’application.

Blague n°2 : Le plan de migration qui dit « on va juste convertir les disques » ressemble à dire « on va juste poser l’avion ». Techniquement correct, émotionnellement incomplet.

Listes de contrôle / plan étape par étape (temps d’arrêt et bascule)

Phase 0 : choisir le pilote et définir le succès

• Choisissez 1–3 VMs représentatives mais pas encore critiques pour l’entreprise.
• Définissez le « succès » en termes opérationnels : démarrage, accessibilité réseau, contrôles de santé applicatifs, jobs de sauvegarde en marche, supervision verte.
• Définissez le rollback : éteindre la VM Proxmox, rallumer la VM ESXi, basculer DNS ou VIP si nécessaire.

Phase 1 : construire l’hôte Proxmox avec une baseline ennuyeuse

• Installez Proxmox VE, mettez à jour et redémarrez sur le noyau attendu.
• Configurez le stockage avec une seule pool/groupe de volumes principal ; évitez de mélanger les formats sans raison.
• Configurez un bridge VLAN-aware et confirmez le trunking avec l’équipe réseau (ou votre futur vous).
• Réglez NTP, DNS et un mode d’accès de management qui ne dépende pas d’un jump host unique.

Phase 2 : pré-peupler les données (optionnel mais puissant)

• Copiez les exports VM ou les VMDKs vers une zone de staging pendant que la VM tourne.
• Mesurez le débit et estimez le temps d’arrêt : taille du disque / MB/s observés + surcharge de conversion.
• Si le downtime est trop long, arrêtez-vous et redesign (réplication, meilleur lien, staging local, copie parallèle).

Phase 3 : fenêtre de maintenance (par VM)

1. Désactivez les tâches/agents qui vont vous combattre (jobs de sauvegarde, patching).
2. Arrêtez proprement la VM sur ESXi.
3. Copie finale des fichiers de disque/export.
4. Convertissez/importez dans Proxmox et attachez en respectant firmware/contrôleur.
5. Démarrez d’abord sur un réseau isolé (optionnel mais recommandé pour les applis critiques).
6. Validez : IP, routes, DNS, santé applicative, intégrité des données, synchronisation temporelle, licences, logs.
7. Basculer : déplacer VLAN/DNS/VIP, activer la supervision et les sauvegardes.
8. Laissez la VM ESXi éteinte mais intacte jusqu’au moins au lendemain ouvrable.

Phase 4 : standardiser après succès

• Convertissez la NIC/le disque en VirtIO si vous aviez démarré avec des modèles legacy.
• Installez qemu-guest-agent et activez-le pour des arrêts propres et le reporting d’IPs.
• Définissez la politique de sauvegarde Proxmox et testez la restauration (ne négociez pas la physique plus tard).

Carnet de tâches : commandes, sorties et décisions à en tirer

Vous vouliez du pratique. Voici du pratique. Chaque tâche inclut (1) commande, (2) ce que signifie la sortie, (3) la décision que vous prenez.
Adaptez les noms d’hôtes, VMID, noms de stockage et interfaces à votre environnement.

Task 1: confirm Proxmox node health and versions

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/2e1f9d1a)
pve-kernel-6.8: 6.8.12-4
qemu-server: 8.2.2
libpve-storage-perl: 8.2.3

Signification : Confirme le noyau et la pile QEMU. Les migrations échouent de façons étranges sur des combinaisons userland/noyau dépareillées.

Décision : Si le nœud est en retard, mettez-le à jour maintenant—avant d’importer des VMs et de commencer à déboguer des fantômes.

Task 2: check storage capacity and filesystem type on the target

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active         98.00 GiB       12.34 GiB       80.12 GiB   12.59%
rpool             zfspool active          3.64 TiB        1.02 TiB        2.62 TiB   28.02%

Signification : Montre les stockages disponibles pour Proxmox et l’espace libre. Les imports demandent de la marge (la conversion peut doubler l’espace temporairement).

Décision : Si l’espace disponible est inférieur à 1.3–1.5× le plus grand disque que vous allez convertir, arrêtez et ajoutez de l’espace ou changez de stratégie (import raw, conversion en flux, ou staging ailleurs).

Task 3: verify ZFS pool health before trusting it

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

Signification : ZFS ne rapporte actuellement aucune erreur ni vdev dégradé.

Décision : Si vous voyez DEGRADED/FAULTED, n’importez pas de VMs de production pour l’instant. Réparez le pool d’abord ou vous importerez dans un incident au ralenti.

Task 4: baseline network interface and bridge state

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:fd:fe:aa:bb:01
bond0            UP             3c:fd:fe:aa:bb:01
vmbr0            UP             3c:fd:fe:aa:bb:01

Signification : Confirme l’état des liens. Si votre bridge ou uplink n’est pas UP, votre « import réussi » risque de devenir « pourquoi ça ne ping pas ».

Décision : Corrigez les problèmes physique/bond/bridge maintenant ; ne commencez pas avec un réseau cassé en espérant qu’il se guérisse.

Task 5: confirm bond mode and LACP negotiation (if using a bond)

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v6.8.12-4-pve

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
MII Status: up
LACP rate: fast
Aggregator selection policy (ad_select): stable

Slave Interface: eno1
MII Status: up
Actor Churn State: none

Slave Interface: eno2
MII Status: up
Actor Churn State: none

Signification : Confirme 802.3ad et la santé des liens. Les états de churn et « down » indiquent un mismatch switch ou un problème de câblage.

Décision : Si LACP n’est pas stable, utilisez active-backup temporairement et planifiez une correction réseau. Le jour de la migration n’est pas le moment de déboguer les channel switchports.

Task 6: verify VLAN filtering and allowed VLANs on the Linux bridge

cr0x@server:~$ bridge vlan show
port              vlan-id
bond0             1 PVID Egress Untagged
bond0             10
bond0             20
bond0             30
vmbr0             1 PVID Egress Untagged

Signification : Montre quels VLANs sont autorisés/filtrés sur les ports du bridge. Si VLAN 20 manque, les VMs taggées 20 seront muettes.

Décision : Si des VLANs sont absents, corrigez la configuration VLAN du bridge et la configuration trunk du switch avant la bascule. C’est une condition de succès binaire.

Task 7: baseline throughput for copy planning (don’t guess)

cr0x@server:~$ iperf3 -c 10.20.30.40 -t 10
Connecting to host 10.20.30.40, port 5201
[  5] local 10.20.30.11 port 50422 connected to 10.20.30.40 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  9.42 GBytes  8.09 Gbits/sec                  sender
[  5]   0.00-10.00  sec  9.41 GBytes  8.08 Gbits/sec                  receiver
iperf Done.

Signification : Vous avez ~8 Gbit/s de débit utilisable sur ce chemin de test.

Décision : Utilisez cela pour estimer le temps de copie. Si votre VM a un disque de 2 To, vous n’allez pas faire une « fenêtre rapide » sur ce lien sans pré-peuplement ou redesign.

Task 8: copy an exported VM bundle to Proxmox (staging)

cr0x@server:~$ rsync -ah --info=progress2 /mnt/stage/ESXI-EXPORTS/app01/ /var/lib/vz/import/app01/
         12.34G  12%   215.78MB/s    0:00:46
        101.22G 100%   238.11MB/s    0:07:14 (xfr#12, to-chk=0/14)

Signification : Confirme le débit soutenu réel et la complétion.

Décision : Si le débit est bien en dessous des attentes, trouvez le goulot avant de planifier le downtime (IO disque, thread unique, overhead chiffrement, chemin réseau).

Task 9: convert a VMDK to raw (often best on ZFS/LVM-thin)

cr0x@server:~$ qemu-img info /var/lib/vz/import/app01/app01-disk1.vmdk
image: /var/lib/vz/import/app01/app01-disk1.vmdk
file format: vmdk
virtual size: 300G (322122547200 bytes)
disk size: 128G
cluster_size: 65536

Signification : Montre la taille virtuelle (visible par l’invité) vs les blocs réellement utilisés (réalité thin-provisioned).

Décision : Si le disque est thin mais rempli de vieux blocs, pensez à lancer un TRIM/clean dans l’invité avant l’export final. Cela peut réduire fortement le temps de copie.

cr0x@server:~$ qemu-img convert -p -O raw /var/lib/vz/import/app01/app01-disk1.vmdk /rpool/vmdata/app01-disk-0.raw
    (0.99/100%)

Signification : La conversion consomme CPU et IO ; le pourcentage indique la progression.

Décision : Si le temps de conversion est inacceptable, évaluez l’import en qcow2 temporairement, ou pré-convertissez pendant les heures ouvrables sur un stockage de staging, puis déplacez le résultat.

Task 10: create the VM shell in Proxmox with matching firmware

cr0x@server:~$ qm create 120 --name app01 --memory 8192 --cores 4 --sockets 1 --net0 virtio,bridge=vmbr0,tag=20 --scsihw virtio-scsi-single --ostype l26 --bios ovmf
create VM 120: success

Signification : Crée la VMID 120 avec OVMF (UEFI) et une NIC virtio tagguée VLAN.

Décision : Faites correspondre BIOS/OVMF à la VM source. Si vous vous trompez, vous obtiendrez un « no boot device » qui ressemble à un problème de disque mais n’en est pas un.

Task 11: import the disk into Proxmox-managed storage

cr0x@server:~$ qm importdisk 120 /rpool/vmdata/app01-disk-0.raw rpool
importing disk '/rpool/vmdata/app01-disk-0.raw' to VM 120 ...
Formatting '/rpool/data/vm-120-disk-0.raw', fmt=raw size=322122547200
Successfully imported disk as 'unused0:rpool:vm-120-disk-0'

Signification : Le disque est maintenant dans le stockage Proxmox et attaché comme device unused.

Décision : Ensuite, il faut l’attacher comme bon device de boot/contrôleur. « Unused » signifie que Proxmox l’a importé mais que vous ne l’avez pas câblé.

Task 12: attach the imported disk and set boot order

cr0x@server:~$ qm set 120 --scsi0 rpool:vm-120-disk-0 --boot order=scsi0 --efidisk0 rpool:1,format=raw
update VM 120: -scsi0 rpool:vm-120-disk-0 -boot order=scsi0 -efidisk0 rpool:1,format=raw

Signification : La VM a maintenant son disque principal sur SCSI (VirtIO SCSI) et un efidisk pour les variables OVMF.

Décision : Si la source utilisait BIOS (legacy), n’ajoutez pas efidisk0 ; conservez --bios seabios et réglez le boot en conséquence.

Task 13: first boot with console and immediate log triage

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

cr0x@server:~$ qm terminal 120
connected to qemu-server 120 (running)

Signification : Vous êtes sur la console de la VM. Si elle bloque tôt, c’est ici que vous verrez le bootloader et les problèmes de drivers.

Décision : Si le kernel panique ou que Windows fait un BSOD, ne changez pas au hasard cinq paramètres. Identifiez d’abord le mismatch contrôleur/firmware.

Task 14: verify the VM sees its NIC and gets an IP (via guest agent)

cr0x@server:~$ qm guest cmd 120 network-get-interfaces
{
  "return": [
    {
      "name": "eth0",
      "ip-addresses": [
        {
          "ip-address": "10.20.20.51",
          "ip-address-type": "ipv4",
          "prefix": 24
        }
      ],
      "hardware-address": "BC:24:11:22:33:44"
    }
  ]
}

Signification : Le guest agent tourne et rapporte les interfaces réseau. C’est de l’or pendant les bascules.

Décision : Si le guest agent ne répond pas, vous pouvez quand même continuer, mais vous perdez en visibilité. Installez/activez l’agent dans la stabilisation.

Task 15: check host IO latency during conversion/import

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.40    0.00    6.10   18.20    0.00   63.30

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         20.00   880.00     0.00   0.00   2.10    44.00  420.00  51200.00    12.00   2.78  18.50   121.90   7.90  92.00

Signification : Un %iowait élevé et un w_await élevé indiquent une pression sur le stockage. %util proche de 100% suggère une saturation.

Décision : Si la latence monte pendant les heures ouvrables, bridez les conversions, déplacez les imports hors pic, ou stagedez sur du stockage plus rapide. Ne « forcez pas » et n’expliquez pas ensuite la lenteur entreprise.

Task 16: validate VLAN tagging from inside a VM (quick sanity)

cr0x@server:~$ ping -c 2 10.20.20.1
PING 10.20.20.1 (10.20.20.1) 56(84) bytes of data.
64 bytes from 10.20.20.1: icmp_seq=1 ttl=64 time=0.410 ms
64 bytes from 10.20.20.1: icmp_seq=2 ttl=64 time=0.392 ms

--- 10.20.20.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.392/0.401/0.410/0.009 ms

Signification : La VM atteint sa passerelle sur le sous-réseau attendu ; le VLAN et le tagging du bridge sont probablement corrects.

Décision : Si elle ne ping pas la passerelle, ne déboguez pas l’application. Corrigez d’abord L2/L3 : tag VLAN, liste VLAN autorisée sur le trunk, bridge ou configuration IP.

Pièges pour invités Windows et Linux (drivers, démarrage, qemu-guest-agent)

Les types de contrôleurs ne sont pas cosmétiques

De nombreuses VMs Windows sur ESXi ont démarré pendant des années sur LSI Logic SAS ou VMware Paravirtual controllers.
Sur Proxmox, vous souhaiterez probablement VirtIO SCSI pour la performance. Mais si Windows n’a pas le driver VirtIO installé, il ne démarrera pas après le changement.

Approche pratique :

• Démarrez d’abord en utilisant un contrôleur compatible (SATA peut être une béquille temporaire).
• Installez les drivers VirtIO dans Windows.
• Puis basculez le bus disque vers VirtIO SCSI et confirmez le démarrage.

Mismatch UEFI vs BIOS ressemble à une panne disque

Si la VM source utilisait EFI et que vous la faites démarrer sous SeaBIOS (ou l’inverse), vous obtenez souvent « no boot device ».
Les gens réimportent alors les disques, reconvertissent et gaspillent une journée. Faites correspondre le firmware d’abord.

Synchronisation temporelle : évitez les horloges rivales

ESXi avait le time sync de VMware Tools dans beaucoup d’environnements. Proxmox utilise le QEMU guest agent et les services temporels standards de l’OS.
Choisissez une méthode autoritaire (généralement NTP/chrony dans l’invité) et désactivez le reste.

Trim/discard et réalité du thin provisioning

Si vous migrez des disques thin-provisioned puis les stockez à nouveau sur du thin, vous créez une pile « thin-on-thin ».
Cela peut fonctionner, mais vous devez surveiller l’utilisation physique réelle et garantir que discard/TRIM est supporté de bout en bout.

Playbook de diagnostic rapide (trouver le goulot en minutes)

Quand une migration est « lente » ou qu’une VM est « saccadée », ne débattez pas des impressions. Prenez des mesures dans cet ordre. C’est optimisé pour la vitesse et le signal.

Premier : le réseau est-il le limitateur ?

• Exécutez iperf3 entre la zone de staging côté source et Proxmox.
• Vérifiez une liaison saturée, un mismatch duplex ou un saut 1G caché.
• Confirmez la cohérence du MTU si vous attendez des jumbo frames.

Second : le stockage cible est-il saturé ou haute latence ?

• Utilisez iostat -xz 1 sur Proxmox pendant la conversion/import.
• Recherchez %util proche de 100% et await montant dans des dizaines de millisecondes pour SSD/NVMe (ou des centaines pour du HDD).
• Vérifiez ZFS : santé du pool, pression ARC et si vous forcez des syncs involontaires.

Troisième : le CPU est-il limitant (souvent durant la conversion) ?

• Utilisez top ou pidstat pour voir si qemu-img occupe un cœur.
• Si CPU-bound, paralléliser les conversions peut aider—mais seulement si le stockage peut suivre.

Quatrième : l’invité est-il mal configuré (boot et drivers) ?

• Vérifiez d’abord firmware et bus disque (OVMF vs SeaBIOS ; VirtIO vs SATA).
• Puis le modèle NIC (VirtIO) et les tags VLAN.
• Ce n’est qu’ensuite que vous chassez les problèmes applicatifs.

Erreurs courantes : symptôme → cause racine → correctif

1) La VM démarre sur « no boot device »

Symptôme : La VM démarre, puis tombe dans le shell du firmware ou le gestionnaire de boot sans disque.

Cause racine : Mismatch de firmware (BIOS vs UEFI) ou mauvais ordre de boot, ou disque attaché sur un bus différent de celui attendu par l’OS.

Fix : Faites correspondre le firmware à la VM source ; réglez l’ordre de boot sur le bon disque ; attachez le disque sur SATA temporairement si nécessaire pour démarrer, puis installez VirtIO et basculez.

2) La VM a le lien réseau mais ne rejoint pas la passerelle

Symptôme : Interface up ; IP configurée ; ping vers la passerelle échoue.

Cause racine : Mauvais tag VLAN (ou VLAN manquant sur le trunk) ; bridge non VLAN-aware ; switchport ne trunk pas le VLAN.

Fix : Validez le tag VLAN par NIC VM ; confirmez le filtrage VLAN du bridge ; confirmez la liste VLAN autorisée sur le switch. Prouvez L2 avec ARP et ping vers la passerelle.

3) La copie de migration est « rapide au début, puis ralentie »

Symptôme : La copie démarre à des centaines de MB/s, puis chute à des dizaines.

Cause racine : Pool ZFS atteignant des écritures sync sans SLOG (si forcé), pression ARC, ou disque de destination devenu bound en latence à cause d’écritures aléatoires durant la conversion.

Fix : Stagez sur du stockage local rapide ; convertissez hors pic ; considérez raw au lieu de qcow2 ; surveillez iostat et les stats ZFS ; évitez de forcer sync sauf si nécessaire.

4) VM Windows écran bleu après le passage à VirtIO

Symptôme : Échec de boot / BSOD immédiatement après le changement de contrôleur disque ou modèle NIC.

Cause racine : Drivers VirtIO manquants ou type de contrôleur inadapté.

Fix : Démarrez avec SATA ou un contrôleur compatible ; installez les drivers VirtIO ; puis basculez et redémarrez. Gardez un point de rollback connu bon.

5) Les VMs fonctionnent mais sont mystérieusement plus lentes que sur ESXi

Symptôme : Latence plus élevée, débit réduit, saccades intermittentes.

Cause racine : Devices émulés (e1000/IDE), mauvais mode cache, réglages d’alimentation de l’hôte ou mismatch recordsize du stockage ZFS.

Fix : Utilisez VirtIO pour NIC et disque ; vérifiez les paramètres de cache ; assurez-vous que le gouverneur CPU/gestion d’énergie est sensé ; ajustez les propriétés des datasets ZFS si approprié.

6) Les sauvegardes ne capturent pas silencieusement les nouvelles VMs

Symptôme : Les jobs de sauvegarde s’exécutent, mais la VM migrée n’est pas incluse ou échoue.

Cause racine : VM stockée sur un backend non inclus dans la conf de sauvegarde, ou snapshots non supportés/désactivés.

Fix : Rapprochez les IDs de stockage, les plannings de sauvegarde et les capacités de snapshot. Testez la restauration immédiatement après la première bascule réussie.

Trois mini-récits d’entreprise tirés du terrain

Mini-récit 1 : l’incident causé par une mauvaise hypothèse (VLAN « par défaut »)

Une entreprise SaaS de taille moyenne planifiait une migration ESXi vers Proxmox avec ce qui semblait être une histoire réseau propre :
« Tous les réseaux VM sont taggués VLANs, trunks partout, pas de dépendance au native VLAN. » Cette phrase aurait dû être suivie de preuves, mais ce ne fut pas le cas.

Lors de la première bascule en production, la VM démarra, répondit sur son port applicatif depuis certains endroits, et était complètement injoignable depuis d’autres.
L’équipe on-call voyait les voyants de lien, une config IP correcte et un démarrage propre. Ils firent la classique : blâmer le pare-feu.
Après quelques bascules de règles, le rayon d’impact grandit, parce qu’ils changeaient plus de variables tout en manquant la seule variable qui comptait.

La cause racine était brutalement simple : le port group ESXi avait un VLAN ID défini, mais le switch en amont avait aussi un « native VLAN » qui transportait le trafic de management,
et certains systèmes legacy dépendaient des trames non tagguées atteignant la VM via une chaîne de dispositifs intermédiaires.
Sur Proxmox, le bridge était VLAN-aware mais configuré avec une liste autorisée stricte qui rejetait le trafic non taggué.

Le correctif n’a pas été de « faire Proxmox se comporter comme ESXi » en désactivant le filtrage. Le correctif a été de documenter quel trafic devait être taggué,
d’éliminer la dépendance accidentelle au native VLAN, puis de configurer explicitement le traitement du trafic non taggué là où il était réellement nécessaire.
Après cela, les migrations suivantes furent ennuyeuses. La première, non.

Mini-récit 2 : l’optimisation qui s’est retournée contre eux (thin-on-thin et surprise de capacité)

Une équipe IT d’entreprise était fière de son efficacité de stockage. Sur ESXi ils utilisaient des VMDKs thin sur un array partagé, et « ça marchait bien ».
En passant à Proxmox avec ZFS, ils gardèrent le modèle : VMDK → qcow2 (thin) → ZFS (copy-on-write). Thin partout. Efficace partout.

Pendant quelques semaines, tout semblait gagnant. Le temps de migration était acceptable, les snapshots faciles et les sauvegardes plus légères que prévu.
Puis un job trimestriel s’exécuta : une charge qui écrivait et réécrivait de gros fichiers en place.
Le copy-on-write plus la fragmentation plus l’agitation des métadonnées firent ce que ça fait toujours quand on la provoque — la latence monta et resta là.

L’équipe réagit en ajoutant plus de snapshots (« pour qu’on puisse revenir en arrière »). Cela augmenta la pression sur les métadonnées et l’espace.
Ensuite ils essayèrent la compression sur des données déjà compressées. Le CPU monta, la latence empirât, et les utilisateurs découvrirent de nouvelles façons de décrire la lenteur.

La correction finale fut ennuyeuse mais efficace : déplacer les disques de base de données chauds en raw sur un dataset dédié avec recordsize adapté,
minimiser la fréquence de snapshots sur ces volumes, et garder le thin provisioning là où il apporte réellement un bénéfice (templates VM, dev boxes, serveurs à faible churn).
L’efficacité n’est pas gratuite ; la facture arrive sous forme de latence.

Mini-récit 3 : la pratique ennuyeuse mais correcte qui a sauvé la journée (test de restauration et discipline du rollback)

Une organisation de santé avait un plan de migration qui fit lever les yeux de certains ingénieurs : « Chaque VM migrée doit passer un test de restauration. »
Pas « on a des sauvegardes ». Pas « les sauvegardes sont vertes ». Une vraie restauration, démarrage et validation sur un réseau isolé.
Ça paraissait lent. C’était lent. Ça les sauva aussi.

Une VM—un vieil appliance fournisseur avec un bootloader fragile—s’importa proprement mais échoua au premier redémarrage après un changement de configuration.
Personne n’avait touché au format du disque ; il ne revenait tout simplement pas. Le fournisseur blâma la virtualisation. La virtualisation blâma le fournisseur.
Le temps fit ce qu’il fait toujours pendant un incident : il accéléra.

Parce qu’ils avaient déjà testé des restaurations sur Proxmox, ils n’eurent pas à inventer une procédure de récupération sous stress.
Ils restaurèrent le dernier backup connu bon sur un nouveau VMID, attachèrent les NICs avec les tags VLAN corrects, et le service revint.
La VM originale resta arrêtée pour la forensique sans bloquer les opérations sensibles aux patients.

Le postmortem n’était pas glamour. La leçon : les tests de restauration ne sont pas du pessimisme, ce sont des répétitions.
Dans les environnements régulés, « on peut restaurer » est une capacité, pas une croyance.

FAQ

1) Puis-je migrer des VMs ESXi vers Proxmox avec un temps d’arrêt quasi nul ?

Parfois, mais pas de façon générique. Pour un vrai temps d’arrêt quasi nul, utilisez la réplication applicative (réplication DB, synchronisation de fichiers, clustering) et basculez les points d’accès.
Les mouvements basés sur la conversion de disques sont généralement des migrations froides sauf si vous introduisez des outils de réplication spécialisés.

2) Dois-je utiliser qcow2 ou raw sur Proxmox ?

Si vous êtes sur ZFS ou LVM-thin, raw est souvent la baseline de performance la plus simple. qcow2 est utile si vous voulez ses fonctionnalités (snapshots internes),
mais il peut ajouter de la surcharge et de la complexité. Choisissez une norme par classe de stockage et ne mélangez pas à la légère.

3) Quelle est la façon la plus propre de gérer les VLANs sur Proxmox ?

Un bridge VLAN-aware (vmbr0) sur l’uplink trunk, puis définir le tag VLAN par NIC VM. C’est scalable, explicite et conceptuellement semblable aux port groups.

4) Dois-je avoir un cluster Proxmox pour commencer ?

Non. Un nœud unique suffit pour un pilote. Mais si vous prévoyez des live-migrations entre nœuds plus tard, planifiez la compatibilité CPU, le stockage partagé (ou la réplication)
et un réseau cohérent dès le départ.

5) Ma VM Windows ne démarre pas après l’import. Que vérifier en priorité ?

Le firmware (UEFI vs BIOS), puis le contrôleur/bus disque. Si vous êtes passé à VirtIO avant d’installer les drivers, revenez à un contrôleur compatible, démarrez, installez les drivers, puis repassez.

6) Comment estimer le temps d’arrêt par VM ?

Mesurez le débit de transfert (iperf et rsync réels), puis calculez : octets du disque / octets soutenus par seconde + temps de conversion + boot/validation.
Ajoutez une marge pour les surprises. Si vous essayez d’imbriquer un déplacement de 2 To dans une fenêtre de 30 minutes, les maths vous contrediront publiquement.

7) Puis-je garder la même IP et les mêmes MAC ?

Vous pouvez conserver les IP si le VLAN/sous-réseau reste identique. Les adresses MAC peuvent être définies manuellement dans Proxmox si nécessaire,
mais faites-le seulement si une licence ou une politique en dépend ; sinon laissez Proxmox attribuer et mettez à jour les dépendances.

8) Qu’en est-il des snapshots pendant la migration ?

Supprimez ou aplatissez les snapshots ESXi inutiles avant d’exporter/copier. Les chaînes de snapshots ralentissent les exports et augmentent le risque.
Sur Proxmox, établissez une nouvelle politique de snapshots/sauvegardes après stabilisation ; n’importez pas l’héritage de snapshots à moins d’une raison solide.

9) Est-il sûr de migrer et en même temps « moderniser » le hardware VM (UEFI, VirtIO, nouveau modèle NIC) ?

C’est sûr si vous pouvez vous permettre de déboguer deux fois. Pour les systèmes critiques, migrez d’abord avec un changement minimal, prouvez la stabilité, puis modernisez lors d’une seconde fenêtre de changement.

10) Quelle est la validation minimale après la bascule ?

Démarrage, IP/subnet/passerelle/DNS corrects, synchronisation temporelle, contrôles de santé applicatifs, logs suffisamment propres pour voir de nouvelles erreurs, supervision et un job de sauvegarde réussi (ou au moins une sauvegarde manuelle).

Conclusion : étapes pratiques suivantes

Faites la migration comme un opérateur, pas comme un joueur. Construisez une baseline Proxmox ennuyeuse, inventoriezn l’environnement ESXi avec intention,
et traitez les VLANs ainsi que les choix firmware/contrôleur comme des données de migration de première classe — pas des « détails qu’on corrigera après le démarrage ».

Étapes suivantes qui rapportent immédiatement :

• Choisissez une VM pilote et exécutez le chemin complet de migration froide de bout en bout, y compris le test de sauvegarde et restauration.
• Standardisez un pattern réseau (bridge VLAN-aware) et un pattern de stockage (raw sur ZFS ou LVM-thin) pour la majorité des VMs.
• Rédigez une fiche de bascule par VM : firmware, bus disque, tag VLAN, plan d’IP, étapes de validation par le propriétaire, étapes de rollback.
• Planifiez les migrations par lots en fonction du débit mesuré et de la latence de stockage, pas des mathématiques calendaires optimistes.

Quand vous aurez fini, le meilleur compliment que vous puissiez recevoir sera le silence : pas de tickets, pas de « on dirait que c’est plus lent », pas de fantômes VLAN mystérieux.
Juste des workloads qui font leur travail, sur une plateforme que vous pouvez expliquer sur un tableau blanc sans vous excuser.