Migration de stockage ESXi vers Proxmox : déplacer des datastores VMFS vers ZFS, NFS ou iSCSI avec un minimum d’interruption

Faits et contexte qui changent les décisions

Voici quelques faits concrets et éléments historiques qui comptent lorsque vous planifiez une migration de stockage VMFS → Proxmox. Ce n’est pas de la trivia : c’est du carburant pour la décision.

1. VMFS a été conçu pour un accès concurrent par plusieurs hôtes ESXi, avec des primitives de verrouillage sur disque qui supposent la pile VMware. Linux peut lire VMFS, mais ce n’est pas un citoyen de première classe dans l’univers Proxmox.
2. VMDK n’est pas « un seul format ». Il existe des variantes monolithiques sparse, thick, split et stream-optimized. Le chemin d’export (OVF/OVA) peut changer silencieusement le format du disque que vous copiez.
3. ZFS a démarré chez Sun Microsystems avec une philosophie de « checksumming bout-en-bout ». Cela compte pour les images VM parce que la corruption silencieuse est un vrai mode de défaillance, pas une histoire effrayante.
4. NFS existe depuis les années 1980 et a eu des décennies pour devenir ennuyeux. En production, l’ennui est une fonctionnalité qui vous permet d’être appelé moins souvent.
5. iSCSI est du stockage bloc sur IP — ce qui signifie que votre hôte VM prend en charge le système de fichiers (ext4, xfs, ou ZFS). Cela rend l’ajustement des performances et les domaines de défaillance très différents de NFS.
6. Le change block tracking (CBT) de VMware peut accélérer les copies incrémentales côté VMware, mais ce n’est pas un concept natif de Proxmox. Si vous en dépendiez indirectement (produits de sauvegarde), prévoyez un changement de comportement.
7. La thin provisioning est une politique, pas une loi physique. L’overcommit est facile ; récupérer l’espace plus tard est là où commence le drame, surtout lors de conversions de format.
8. L’alignement sur secteurs 4K était optionnel. Ce ne l’est plus. Le désalignement peut vous coûter des écritures doubles et des moments « pourquoi ce SSD est plus lent que de la rouille ? » pendant les migrations.

Blague #1 : Les migrations de stockage ressemblent à un déménagement : les cartons se multiplient quand vous ne regardez pas, et vous vous retrouvez à porter une imprimante que vous n’avez pas utilisée depuis 2017.

Choisir votre zone d’atterrissage : ZFS vs NFS vs iSCSI

ZFS sur Proxmox (local ou partagé via réplication)

Quand le choisir : Vous voulez une forte intégrité des données, des snapshots, un contrôle opérationnel simple, et vous pouvez garder les disques VM locaux sur un nœud Proxmox (ou accepter une HA basée sur la réplication plutôt que du stockage partagé).

Réalité opérationnelle : ZFS n’est pas « configurer et oublier ». C’est « configurer et surveiller ». ZFS vous donnera un excellent comportement si vous respectez ses besoins : suffisamment de RAM, des choix sensés de recordsize/volblocksize, et ne pas prétendre qu’un RAIDZ1 de SSD grand public est du stockage entreprise.

Angle temps d’arrêt minimal : Les snapshots ZFS et zfs send/zfs receive sont vos amis pour les gros transferts et les basculements répétables. Si vous pouvez préparer un dataset et effectuer un send incrémental final pendant une courte fenêtre d’arrêt, vous obtenez un temps d’arrêt prévisible.

À éviter si : Vous avez besoin de sémantiques de stockage partagé pour la migration à chaud entre nœuds et ne voulez pas gérer une planification de réplication avec logique de basculement. Proxmox peut faire de la réplication, mais ce n’est pas identique à un « datastore partagé ».

NFS (stockage partagé sans la personnalité iSCSI)

Quand le choisir : Vous voulez du stockage partagé facile à comprendre, vous disposez d’un NAS solide ou d’un serveur NFS Linux, et vous privilégiez la simplicité opérationnelle et la portabilité.

Réalité opérationnelle : Les performances NFS dépendent fortement du serveur, du réseau et des options de montage. L’avantage : quand quelque chose casse, les outils et les modèles mentaux sont courants. L’inconvénient : si votre réseau a des micro-bursts, vous le remarquerez.

Angle temps d’arrêt minimal : NFS partagé vous permet de placer les disques VM au centre pour déplacer le calcul séparément. Pour le basculement, il faut toujours copier les données, mais une fois les disques sur NFS, l’évacuation au niveau hôte est beaucoup plus simple.

À éviter si : Votre seul réseau est un LAN congestionné et partagé sans isolation du trafic de stockage. NFS sur un réseau instable ressemble à une base de données sur un trampoline.

iSCSI (stockage bloc avec des bords tranchants)

Quand le choisir : Vous avez déjà un SAN, vous avez besoin de sémantiques bloc, vous voulez du multipath et vous avez la discipline pour le gérer. iSCSI est bien — si vous le traitez comme un système, pas comme une case à cocher.

Réalité opérationnelle : iSCSI vous apporte des modes de défaillance qui ressemblent à « le stockage est lent » mais sont en fait « un chemin clignote et multipath fait de la danse interprétative ». Votre monitoring doit inclure la santé des chemins et la distribution des latences, pas seulement le débit.

Angle temps d’arrêt minimal : Si votre LUN iSCSI est déjà le backing store partagé, vous pouvez migrer le calcul plus librement. La migration des données existe toujours (VMFS vers le système de fichiers que vous utilisez sur le LUN), mais vous gagnez en flexibilité ensuite.

À éviter si : Vous n’avez pas de réseau redondant, vous ne pouvez pas faire du multipath correctement, ou vous tenez à ce que votre équipe dorme. iSCSI sans standards est générateur de tickets.

Architectures cibles qui fonctionnent réellement

Architecture A : Proxmox mono-nœud avec ZFS local

Idéale pour petits et moyens environnements, labs, sites distants, ou équipes migrant par phases. Placez les VM sur un pool ZFS local. Utilisez des snapshots pour revenir en arrière. Utilisez la réplication ZFS vers un second nœud pour le DR ou une « HA à la bonne franquette ».

Décisions clés : mirror vs RAIDZ, SLOG ou pas, compression, ashift, et comment vous gérerez les sauvegardes (Proxmox Backup Server ou autre). La disposition du pool est une porte sans retour.

Architecture B : Cluster Proxmox avec NFS partagé

C’est l’option « rendre ça ennuyeux ». Stockage NFS partagé pour les disques VM + réseau de cluster Proxmox séparé pour corosync + chemin de sauvegarde dédié. La migration à chaud devient un déplacement de calcul, pas de stockage.

Décisions clés : conception du serveur NFS (NAS ZFS-backed courant), isolation réseau (VLANs ou NICs physiquement séparées), et options de montage adaptées à la charge.

Architecture C : Cluster Proxmox avec iSCSI + multipath + LVM-thin ou ZFS

Vous pouvez utiliser des LUNs iSCSI avec LVM-thin, ou des LUNs iSCSI consommés par ZFS comme vdev (pas ma préférence sauf si vous savez exactement pourquoi). La plupart des équipes utilisent LVM-thin sur iSCSI pour des sémantiques de stockage bloc.

Décisions clés : politique multipath, profondeurs de queue, réglages ALUA, et comment vous monitorerez la latence par chemin. Aussi : qui gère la config SAN et comment contrôler les changements.

Blague #2 : iSCSI, c’est comme une relation avec une grande chimie et une terrible communication — quand ça va, c’est brillant ; quand ça ne va pas, c’est Wireshark à 3 h du matin.

Pré-vol : inventaire, contraintes et calcul du temps d’arrêt

Inventoriez les VM comme si vous le pensiez vraiment

Votre plan de migration n’est aussi bon que votre inventaire. « Environ 40 VM » n’est pas un inventaire. L’inventaire inclut : tailles de disques (provisionnées et utilisées), types d’OS, modes de démarrage (BIOS vs UEFI), services critiques, attentes RPO/RTO, et si le guest supporte un arrêt propre.

Mesurez le taux de changement, pas seulement la taille

Si une VM a 2 To de disque mais ne change que de 2 Go/jour, vous pouvez préparer la majeure partie des données à l’avance et garder le basculement court. Si elle change de 400 Go/jour, vous faites une coupure froide ou vous construisez une stratégie de réplication côté application.

Décidez ce que signifie « interruption minimale »

Interruption minimale n’est pas zéro interruption. C’est la plus petite fenêtre d’arrêt honnête : temps pour quiescer l’application, copie delta finale, démarrage sur Proxmox, validation et retour arrière si nécessaire.

Prévoyez une histoire de retour arrière avant de commencer

Si vous ne pouvez pas revenir en arrière, vous migrez ; vous jouez. Le rollback signifie généralement : garder la VM ESXi intacte, ne pas supprimer les données VMFS, et prévoir les inversions DNS/load balancer. Si vous devez réutiliser des IP, préparez un plan pour rafraîchir les caches ARP et réinitialiser les états de pare-feu.

Tâches pratiques avec commandes (et quoi décider selon la sortie)

Voici les vérifications réelles que j’exécute avant, pendant et après une migration de stockage. Chaque tâche inclut une commande, un extrait de sortie plausible, ce que cela signifie, et la décision que vous prenez.

Task 1: Confirm Proxmox node health and kernel basics

cr0x@server:~$ pveversion -v
pve-manager/8.2.2/1a2b3c4d (running kernel: 6.8.12-4-pve)

Ce que cela signifie : Vous êtes sur une version moderne de Proxmox avec un noyau pve à jour. Les drivers de stockage et le comportement ZFS sont sensibles au noyau.

Décision : Si vous êtes sur un noyau ancien, corrigez cela avant de migrer. Ne combinez pas « nouveau stockage + noyau ancien + coupure à minuit ».

Task 2: Verify CPU virtualization and IOMMU (for futureproofing)

cr0x@server:~$ lscpu | egrep -i 'Virtualization|Model name'
Model name:                           Intel(R) Xeon(R) Silver 4214R CPU @ 2.40GHz
Virtualization:                       VT-x

Ce que cela signifie : La virtualisation matérielle est présente. Pas directement lié au stockage, mais cela affecte le succès de la migration si vous devez exécuter les mêmes configs de guest.

Décision : Si la virtualisation est absente/désactivée, arrêtez et corrigez les réglages BIOS. La migration de stockage n’a pas d’importance si rien ne démarre.

Task 3: Check NIC link, speed, and errors (storage over network depends on this)

cr0x@server:~$ ip -s link show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    9876543210  1234567      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
    8765432109  1122334      0       0       0       0

Ce que cela signifie : Les erreurs sont à zéro ; quelques drops peuvent être normaux lors de bursts, mais « 12 dropped » est une odeur que vous devriez comprendre.

Décision : Si les erreurs augmentent pendant les tests, corrigez le câblage/le switching avant d’accuser NFS/iSCSI/ZFS.

Task 4: Validate jumbo frames end-to-end (only if you insist on them)

cr0x@server:~$ ping -M do -s 8972 -c 3 10.10.20.10
PING 10.10.20.10 (10.10.20.10) 8972(9000) bytes of data.
8980 bytes from 10.10.20.10: icmp_seq=1 ttl=64 time=0.612 ms
8980 bytes from 10.10.20.10: icmp_seq=2 ttl=64 time=0.590 ms
8980 bytes from 10.10.20.10: icmp_seq=3 ttl=64 time=0.605 ms

--- 10.10.20.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms

Ce que cela signifie : MTU 9000 fonctionne sur le chemin. Si cela échoue, vous n’avez pas de jumbo frames ; vous avez de la fragmentation et de la tristesse.

Décision : Si cela échoue, corrigez l’MTU de façon cohérente partout ou revenez à 1500. Un MTU mixte est pire que l’absence de jumbo.

Task 5: Create a ZFS pool with correct ashift (example: mirrored SSDs)

cr0x@server:~$ sudo zpool create -o ashift=12 -o autotrim=on rpool mirror /dev/disk/by-id/nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4X7NX0N123456 /dev/disk/by-id/nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4X7NX0N789012
cr0x@server:~$ sudo zpool status rpool
  pool: rpool
 state: ONLINE
config:

        NAME                                                                STATE     READ WRITE CKSUM
        rpool                                                               ONLINE       0     0     0
          mirror-0                                                          ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4X7NX0N123456                  ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4X7NX0N789012                  ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : Le pool est sain ; ashift=12 est une valeur par défaut raisonnable pour des périphériques 4K (y compris beaucoup de SSD qui mentent sur leurs secteurs).

Décision : Si vous avez déjà créé un pool avec le mauvais ashift, reconstruisez-le. Il n’y a pas de « correction magique » après coup.

Task 6: Tune ZFS datasets for VM images (volblocksize + compression)

cr0x@server:~$ sudo zfs create -o compression=zstd -o atime=off rpool/vmdata
cr0x@server:~$ sudo zfs get -o name,property,value compression,atime rpool/vmdata
NAME         PROPERTY     VALUE
rpool/vmdata compression  zstd
rpool/vmdata atime        off

Ce que cela signifie : La compression est activée (généralement bénéfique pour les images VM), atime est désactivé (moins d’écritures métadonnées).

Décision : Si votre charge est déjà liée au CPU, la compression peut nuire. Sinon, elle améliore souvent espace et performances.

Task 7: Benchmark storage latency the boring way (fio, sync writes)

cr0x@server:~$ sudo fio --name=sync4k --directory=/rpool/vmdata --rw=randwrite --bs=4k --iodepth=1 --numjobs=1 --size=2G --direct=1 --fsync=1
sync4k: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.33
sync4k: (groupid=0, jobs=1): err= 0: pid=22110: Mon Dec 23 14:03:41 2025
  write: IOPS=4200, BW=16.4MiB/s (17.2MB/s)(2048MiB/124800msec)
    clat (usec): min=120, max=24000, avg=230.50, stdev=410.20

Ce que cela signifie : Latence sync 4K moyenne ~230 µs est correcte pour un miroir NVMe. Les queues longues (24 ms) sont ce qui impactera les bases de données et services intensifs en logs.

Décision : Si la latence de queue est mauvaise, arrêtez. Corrigez le firmware du périphérique, vérifiez les réglages du cache d’écriture, ou reconsidérez la topologie du pool avant d’importer des VMs en production.

Task 8: Export VM disks from ESXi datastore to a staging server (via SSH + vmkfstools copy)

cr0x@server:~$ ssh root@esxi-01 "vim-cmd vmsvc/getallvms | head"
Vmid   Name                 File                                 Guest OS           Version   Annotation
12     app01                [vmfs01] app01/app01.vmx              ubuntu64Guest      vmx-19
13     db01                 [vmfs01] db01/db01.vmx                centos7_64Guest    vmx-19

Ce que cela signifie : Vous pouvez énumérer les VMs et localiser leurs chemins VMX. À partir de là, vous localisez les VMDK dans le répertoire de la VM.

Décision : Si vous ne pouvez pas SSH sur ESXi pour des raisons de politique, utilisez une méthode d’export (OVF/OVA) ou la restauration d’un produit de sauvegarde. Prévoyez des changements de format et du temps.

Task 9: Confirm VMDK type and size on ESXi before copying

cr0x@server:~$ ssh root@esxi-01 "ls -lh /vmfs/volumes/vmfs01/app01 | egrep 'vmdk|vmx'"
-rw-------    1 root     root         8.0K Dec 20 10:12 app01.vmx
-rw-------    1 root     root         1.2K Dec 20 10:12 app01.vmdk
-rw-------    1 root     root        150G Dec 23 03:20 app01-flat.vmdk

Ce que cela signifie : Cette VM utilise un descripteur + extent plat (commun pour les formats plutôt thick). Copiez les deux. Le descripteur est petit mais requis.

Décision : Si vous ne copiez que le -flat.vmdk et oubliez le descripteur, vous passerez du temps à reconstruire les métadonnées. Ne vous infligez pas ça.

Task 10: Copy VMDKs efficiently (rsync over SSH, with resume)

cr0x@server:~$ rsync -avP --inplace -e ssh root@esxi-01:/vmfs/volumes/vmfs01/app01/ /srv/stage/app01/
sending incremental file list
app01.vmdk
          1,248 100%    1.19KB/s    0:00:01 (xfr#1, to-chk=1/3)
app01-flat.vmdk
  12,884,901,888  8%   112.34MB/s    0:19:42

Ce que cela signifie : Vous déplacez l’extent à ~112 MB/s. L’option --inplace aide à reprendre les gros fichiers.

Décision : Si le débit est bien inférieur à ce que le réseau/le stockage devrait fournir, arrêtez et diagnostiquez (voir le playbook rapide). Ne « laissez pas traîner » et manquer votre fenêtre.

Task 11: Convert VMDK to raw or qcow2 on the Proxmox side

cr0x@server:~$ qemu-img info /srv/stage/app01/app01.vmdk
image: /srv/stage/app01/app01.vmdk
file format: vmdk
virtual size: 150 GiB (161061273600 bytes)
disk size: 150 GiB

cr0x@server:~$ qemu-img convert -p -f vmdk -O raw /srv/stage/app01/app01.vmdk /rpool/vmdata/app01-disk-0.raw
    (100.00/100%)

Ce que cela signifie : Vous avez validé le format source et converti en raw, simple et performant sur ZFS (ZVOL est aussi courant ; un fichier raw sur dataset fonctionne s’il est bien ajusté).

Décision : Si vous avez besoin de snapshots au niveau stockage et de thin provisioning, qcow2 peut aider — mais il ajoute une surcharge. Pour les VMs sensibles aux performances sur ZFS, raw ou ZVOL est généralement le choix.

Task 12: Import disk into a Proxmox VM and verify boot config (BIOS/UEFI)

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

cr0x@server:~$ qm importdisk 120 /rpool/vmdata/app01-disk-0.raw rpool
importing disk 'app01-disk-0.raw' to VM 120 ...
transferred 0.0 B of 150.0 GiB (0.00%)
transferred 150.0 GiB of 150.0 GiB (100.00%)
Successfully imported disk as 'unused0: rpool:vm-120-disk-0'

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

Ce que cela signifie : Le disque est attaché et défini comme périphérique de démarrage. Si le guest utilisait UEFI sur ESXi, vous aurez aussi besoin d’OVMF et d’un disque EFI.

Décision : Si la VM ne démarre pas, vérifiez le firmware (SeaBIOS vs OVMF), le type de contrôleur de disque (LSI vs virtio), et si l’OS a les pilotes virtio.

Task 13: Configure NFS storage on Proxmox and validate mount behavior

cr0x@server:~$ sudo pvesm add nfs nfs-vmstore --server 10.10.20.10 --export /export/vmstore --content images,iso,backup --options vers=4.1
create storage 'nfs-vmstore'

cr0x@server:~$ pvesm status
Name         Type     Status     Total      Used      Available   %
local        dir      active     98.00GB    12.44GB    85.56GB   12.69%
nfs-vmstore  nfs      active     10.00TB     4.20TB     5.80TB   42.00%

Ce que cela signifie : Le stockage est monté et visible. S’il apparaît inactif, vous avez un problème réseau/export/options.

Décision : Si NFS est actif mais les performances sont mauvaises, vérifiez les threads du serveur NFS, les réglages sync et le QoS réseau avant d’accuser Proxmox.

Task 14: Configure iSCSI target and check session/login

cr0x@server:~$ sudo apt-get update -qq
cr0x@server:~$ sudo apt-get install -y -qq open-iscsi multipath-tools

cr0x@server:~$ sudo iscsiadm -m discovery -t sendtargets -p 10.10.30.20
10.10.30.20:3260,1 iqn.2001-04.com.example:san.lun01

cr0x@server:~$ sudo iscsiadm -m node -T iqn.2001-04.com.example:san.lun01 -p 10.10.30.20 --login
Logging in to [iface: default, target: iqn.2001-04.com.example:san.lun01, portal: 10.10.30.20,3260]
Login to [iface: default, target: iqn.2001-04.com.example:san.lun01, portal: 10.10.30.20,3260] successful.

Ce que cela signifie : La découverte fonctionne et vous êtes connecté. L’étape suivante est la sanity multipath et la création du filesystem/LVM.

Décision : Si la découverte est vide, vous avez des ACLs de cible, du routage VLAN, ou des mismatches CHAP. Corrigez cela avant de toucher la config Proxmox.

Task 15: Validate multipath and path health (iSCSI)

cr0x@server:~$ sudo multipath -ll
mpatha (36001405abcde1234567890fedcba9876) dm-2 DGC,VRAID
size=2.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:10 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:10 sdc 8:32 active ready running

Ce que cela signifie : Deux chemins existent ; l’un est active/optimized (prio 50). C’est ce que vous voulez avec des arrays ALUA-capable.

Décision : Si vous ne voyez qu’un seul chemin, ne procédez pas. Corrigez la redondance réseau maintenant ; plus tard vous le ferez sous charge.

Task 16: Check ZFS health and detect silent trouble early

cr0x@server:~$ sudo zpool iostat -v rpool 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
rpool                        320G   612G    120    450  12.3M  55.1M
  mirror-0                   320G   612G    120    450  12.3M  55.1M
    nvme-SAMSUNG...123456      -      -     60    225  6.1M   27.5M
    nvme-SAMSUNG...789012      -      -     60    225  6.2M   27.6M
--------------------------  -----  -----  -----  -----  -----  -----

Ce que cela signifie : I/O équilibrée sur le miroir et débit raisonnable. Si un périphérique montre des pics de latence étranges, vous le verrez dans les motifs de zpool iostat.

Décision : Si un vdev retardataire existe, remplacez-le avant la migration. Ne « surveillez » pas jusqu’à une panne pendant la semaine de cutover.

Méthodes de migration : froide, tiède et « à éviter »

Method 1: Cold migration (shutdown VM, copy disks, boot on Proxmox)

C’est la méthode par défaut parce qu’elle est prévisible. Vous arrêtez la VM sur ESXi, copiez l’état disque final, convertissez/importez, démarrez sur Proxmox, validez les services et mettez à jour le réseau/DNS.

Profil d’interruption : Potentiellement élevé, mais borné et compréhensible. Vous pouvez tester le processus d’import à l’avance avec un clone ou un export snapshot.

Où ça gagne : Bases de données avec consistance stricte, OS legacy, ou quand vous ne faites pas confiance à la réplication au niveau guest.

Method 2: Staged copy + short cutover (copy most data first, then final sync)

Si vous pouvez garder la VM en marche pendant que vous préparez une copie en vrac (ou partir d’un snapshot), vous pouvez réduire le temps d’arrêt au « delta final + démarrage ». Approche commune :

• Préparez une copie complète des VMDK vers un hôte de transfert.
• Planifiez une fenêtre de cutover.
• Éteignez la VM, lancez un rsync/copie final (petit delta si le taux de changement est faible), convertissez/importez, démarrez.

Profil d’interruption : Souvent excellent pour les VMs à faible taux de changement. La clé est de ne pas se mentir sur le taux de changement.

Method 3: Application-level replication (min downtime, more moving parts)

Pour les grosses bases de données ou systèmes très écritures, copier des images disque est souvent la mauvaise abstraction. Répliquez au niveau applicatif : réplication DB, réplication de fichiers, ou sync spécifique au service, puis basculez les clients.

Profil d’interruption : Peut être très court, mais opérationnellement plus lourd. Exige aussi que votre application ait un plan de basculement propre.

Method 4: “Mount VMFS and copy from Linux” (works, but don’t romanticize it)

Vous pouvez monter des volumes VMFS depuis Linux avec des outils comme vmfs-fuse, puis en extraire les VMDK. Utile en cas de pépin, surtout si ESXi est mort mais que les LUNs sont vivants. Mais ce n’est pas le plan principal le plus propre. Lecture seule possible, performances variables, et vous ajoutez une couche d’abstraction pendant un moment stressant.

Méthodes à éviter sauf si vous savez vraiment pourquoi

• « On va juste convertir directement depuis le datastore ESXi en live. » Si le datastore est occupé, vous entrez en concurrence avec l’I/O de production pendant que vous copiez. C’est comme inventer votre propre incident.
• « On utilisera qcow2 partout parce que c’est flexible. » La flexibilité n’est pas gratuite. qcow2 peut convenir, mais c’est du CPU et de la métadonnée en plus. Utilisez-le quand il a un but (snapshots, thin), pas comme une religion.
• « On va mettre du RAIDZ avec des VMs random-write et espérer. » RAIDZ peut être super pour les charges séquentielles et la capacité. Les patterns random-write des VMs vous montreront pourquoi les mirrors existent.

Checklists / plan pas-à-pas

Checklist A: Decide the target storage (10-minute decision)

1. Si vous avez besoin de stockage partagé pour migration à chaud aujourd’hui, privilégiez NFS (ennuyeux) ou iSCSI (tranchant) selon votre environnement.
2. Si vous priorisez intégrité des données + opérations prévisibles et pouvez accepter des disques locaux + réplication, choisissez ZFS local.
3. Si vous possédez déjà un SAN et maîtrisez le multipath, iSCSI convient. Sinon, n’apprenez pas ça pendant la semaine de migration.

Checklist B: Pre-migration staging (do this before you touch a production VM)

1. Construisez le stockage Proxmox (ZFS/NFS/iSCSI) et exécutez fio avec écritures sync.
2. Validez la cohérence MTU et les compteurs d’erreurs réseau.
3. Créez au moins une VM de test sur Proxmox ; assurez-vous que les sauvegardes fonctionnent.
4. Choisissez une VM ESXi non critique ; réalisez une répétition complète et documentez les étapes et temps exacts.
5. Définissez le rollback : la VM ESXi reste hors tension mais intacte jusqu’à validation ; changements DNS suivis ; règles firewall/NAT préconfigurées.

Checklist C: Cutover plan (per VM)

1. Confirmez la dernière sauvegarde valide et test de restauration (oui, testez réellement).
2. Avertissez les parties prenantes avec une fenêtre d’interruption incluant le temps de validation.
3. Arrêtez le guest proprement (arrêt des applications pour les bases de données en premier).
4. Réalisez la copie disque finale / delta final.
5. Convertissez/importez le disque au format Proxmox.
6. Paramétrez le firmware/contrôleur de la VM pour correspondre aux besoins du guest.
7. Démarrez dans un VLAN isolé ou réseau déconnecté d’abord si vous devez éviter les conflits IP.
8. Validez la santé des services (systemd, logs, vérifications applicatives).
9. Basculez le trafic (DNS/LB) et surveillez.
10. Gardez l’option de rollback pendant une période définie ; puis retirez les artefacts VM anciens.

Checklist D: Post-migration hardening (because future-you has to operate this)

1. Activez les sauvegardes Proxmox avec rétention et tests de restauration périodiques.
2. Programmez les scrubs ZFS et les alertes, ou des checks NFS/iSCSI avec alertes latence.
3. Documentez la topologie de stockage : pools, datasets, exports, IDs de LUN, WWIDs multipath.
4. Établissez une baseline de latence disque depuis le guest (pour avoir des chiffres « normaux »).

Playbook de diagnostic rapide : trouver le goulot vite

Quand les copies de migration sont lentes ou que les VMs Proxmox semblent lentes après cutover, ne devinez pas. Triez comme un SRE : isolez si vous êtes CPU-bound, réseau-bound ou storage-bound. C’est le chemin le plus court vers la vérité.

First: is it the network?

• Vérifiez les erreurs/drops d’interface sur l’hôte Proxmox et sur le serveur de stockage/ports de switch.
• Faites un test ping MTU (seulement si vous utilisez des jumbo frames).
• Mesurez le débit brut avec iperf3 entre Proxmox et les endpoints NFS/iSCSI.

Interprétation : Si iperf3 est faible ou instable, le tuning stockage ne sauvera pas la situation. Réglez le réseau d’abord.

Second: is it the storage device latency (tail latency)?

• Exécutez fio avec --fsync=1 et petits blocs (4k/8k) pour imiter les pires écritures VM.
• Sur ZFS, utilisez zpool iostat pour voir si un périphérique se comporte mal.
• Sur iSCSI, vérifiez le statut multipath et la latence par chemin si l’outil array le fournit.

Interprétation : Les IOPS moyens peuvent sembler corrects tandis que la latence tail détruit les bases de données. Faites confiance aux queues longues.

Third: is it contention or misconfiguration on the host?

• Cherchez du CPU steal / saturation CPU de l’hôte pendant la conversion.
• Vérifiez que votre disque VM utilise virtio-scsi et non un contrôleur émulé sauf si nécessaire.
• Confirmez que vous n’êtes pas accidentellement sur un backend de stockage lent (comme un local dir sur disque rotatif).

Interprétation : Si l’hôte est occupé à convertir plusieurs disques en parallèle, vous pouvez faire passer le stockage pour mauvais. Modérez votre ambition.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: Copy speed is stuck at 20–40 MB/s on a 10Gb network

Cause racine : Goulot TCP par flux unique, mauvais réglages d’offload NIC, ou lecture depuis un datastore VMFS occupé.

Correctif : Validez avec iperf3. Si le réseau est ok, préparez la copie depuis un snapshot ou en dehors des heures de production. La parallélisation peut aider (deux streams), mais en abuser peut griller l’array source.

2) Symptom: VM boots on Proxmox but disk is “read-only filesystem”

Cause racine : Incohérence du système de fichiers due à un arrêt dirty ou une copie incomplète ; parfois aussi mismatch pilote/contrôleur provoquant des timeouts.

Correctif : Faites un arrêt propre sur ESXi. Recopiez après arrêt. Exécutez fsck (Linux) ou chkdsk (Windows) en validation dans un réseau isolé.

3) Symptom: VM won’t boot; drops into EFI shell or “no bootable device”

Cause racine : Mismatch de firmware (UEFI vs BIOS), disque EFI manquant, mauvais ordre de boot, ou bootloader lié au type de contrôleur.

Correctif : Assortissez le firmware : SeaBIOS pour installations BIOS, OVMF pour UEFI. Ajoutez un disque EFI pour OVMF. Assurez-vous que le disque est attaché comme scsi0/virtio si l’OS l’attend.

4) Symptom: NFS storage is active but VM I/O is spiky and latency jumps

Cause racine : Réglages sync du serveur NFS, CPU NAS surchargé, ou micro-bursts/drops réseau. Parfois une seule NIC/port défaillant.

Correctif : Vérifiez les compteurs d’erreurs NIC et les stats port du switch. Validez la version NFS (4.1 souvent meilleure) et le nombre de threads côté serveur. Isolez le trafic stockage si possible.

5) Symptom: iSCSI LUN performance is fine until a path fails, then everything stalls

Cause racine : Mauvaise configuration multipath (queue_if_no_path sans timeouts sensés), ALUA non respecté, ou chemins asymétriques mal gérés.

Correctif : Corrigez la politique multipath et les timeouts. Validez les priorités ALUA. Testez une défaillance de chemin contrôlée avant la mise en production.

6) Symptom: ZFS pool looks healthy but VM writes are slow

Cause racine : RAIDZ sous workload random-write, RAM insuffisante (miss ARC), ou mauvaise idée de SLOG (ajouter un SLOG lent peut nuire).

Correctif : Mirrors pour pools VM-intensifs. N’achetez pas un SSD consumer pour SLOG ; si vous n’avez pas besoin de sémantiques synchrones, laissez-le de côté. Mesurez avec fio.

7) Symptom: Storage space “disappears” after migration

Cause racine : Disques thick créés à partir de sources thin, choix de préallocation qcow2, ou snapshots orphelins sur le nouveau backend.

Correctif : Décidez thin vs thick intentionnellement. Suivez et supprimez les snapshots. Sur ZFS, surveillez referenced vs used ; sur LVM-thin, surveillez data+metadata.

Trois micro-histoires du monde de l’entreprise (douleur incluse)

Mini-story 1: The incident caused by a wrong assumption

Ils avaient un plan propre : exporter des VMs depuis ESXi, importer dans Proxmox, pointer tout vers le nouveau stockage NFS. L’équipe a fait un pilote avec deux petites VMs Linux, tout semblait bien, et le PowerPoint s’est écrit presque tout seul.

L’hypothèse erronée était simple : « Si NFS se monte, les performances seront correctes. » Personne n’a mesuré la latence tail. Personne n’a vérifié les buffers du switch. Le VLAN de stockage partageait les uplinks avec le trafic de sauvegarde, et les sauvegardes s’exécutaient quand l’équipe backup se sentait inspirée.

La nuit du cutover, une VM Windows volumineuse a atterri sur Proxmox. Lundi matin, les utilisateurs ont dit que l’Explorer « gelait ». La VM n’était pas down ; elle souffrait en mode vivant. Sur l’hôte, l’I/O NFS avait des stalls périodiques ; à l’intérieur du guest, les timeouts SMB s’empilaient comme de mauvaises décisions.

L’équipe a chassé des fantômes : pilotes virtio, updates Windows, antivirus, même DNS. Finalement quelqu’un a tracé la latence NFS et a vu que les pics coïncidaient avec le trafic de sauvegarde sur les mêmes uplinks.

La correction a été ennuyeuse : dédiquer la bande passante pour le stockage, appliquer du QoS, et caler les sauvegardes avec la discipline qu’on réserve d’habitude à la paie. La leçon : « Ça se monte » n’est pas un test de performance. C’est à peine une salutation.

Mini-story 2: The optimization that backfired

Un autre shop voulait de la vitesse. Ils ont choisi ZFS pour le stockage local VM et lu quelques posts confiants sur SLOG. Ils ont donc ajouté un NVMe « rapide » consumer comme SLOG, parce qu’il était disponible et que « journal d’intention séparé » sonne comme un cheat code.

L’environnement avait des workloads mixtes. Certaines VMs étaient des bases de données avec écritures synchrones. D’autres étaient des serveurs applicatifs. Pendant une semaine, tout semblait ok. Puis le NVMe consumer a commencé à provoquer des pics de latence intermittents sous charge sync soutenue. Pas une panne complète. Pire : une demi-panne.

ZFS a fait son travail : il a préservé l’intégrité. Les performances, elles, ont chuté pendant ces pics. Les VMs ont eu des pauses I/O périodiques. L’équipe a interprété ça comme « ZFS est lent » et a commencé à tripoter : recordsize, compression off, réglages arc. Une semaine de tuning festive.

Le vrai problème était « l’optimisation » : le SLOG n’avait pas de protection contre la perte de puissance et affichait une latence incohérente sous sync. Retirer le SLOG et revenir à des SSD enterprise en miroir a rétabli une stabilité. Plus tard, ils ont ajouté un SLOG correct avec protection PLP seulement après avoir mesuré un vrai bénéfice pour les workloads sync.

Optimiser, ce n’est pas ajouter des pièces. C’est réduire l’incertitude. Ajouter un composant à latence imprévisible, c’est optimiser pour l’assignation de blâme.

Mini-story 3: The boring but correct practice that saved the day

Une entreprise du domaine financier devait déplacer un ensemble de VMs anciennes mais critiques : un serveur de licences, une appli interne, et une base de données que tout le monde feignait d’ignorer jusqu’à ce qu’elle casse. Ils avaient une fenêtre de changement stricte et des dirigeants qui entendaient « virtuel » et pensaient « instantané ».

La pratique de l’équipe était douloureusement peu glamour : chaque migration VM avait un runbook répété, une feuille de temps et un exercice de rollback. Ils gardaient aussi les VMs ESXi intactes pendant une « période de confiance » après le cutover. Personne n’avait le droit de récupérer l’espace trop tôt, peu importe l’attrait des datastores vides.

Pendant le cutover réel, la DB a été importée mais n’a pas démarré à cause d’un mismatch firmware : ESXi l’avait en UEFI ; la VM Proxmox initiale avait SeaBIOS. C’est une correction simple, mais pas agréable quand votre chronomètre d’incident tourne.

Parce qu’ils avaient répété, ils ont reconnu rapidement le mode de défaillance. Ils ont basculé la VM vers OVMF, ajouté un disque EFI, corrigé l’ordre de boot et démarré proprement. Retard total : minutes, pas heures.

Le vrai sauvetage est venu après : une appli aval avait une IP codée en dur pour la DB, et la règle NAT réseau ne s’appliquait pas dans le nouveau segment. Le rollback n’était pas théorique. Ils ont rollbacké le trafic, corrigé la règle NAT, puis re-cut. La pratique ennuyeuse — runbooks et discipline de rollback — a battu l’ingéniosité. À chaque fois.

Une citation sur la fiabilité (approuvée par les opérations)

Idée paraphrasée (attribuée à Gene Kim) : « Améliorer la fiabilité signifie souvent améliorer le flux de travail et le feedback, pas seulement ajouter plus de contrôles. »

FAQ

1) Can Proxmox read VMFS directly?

Pas de manière supportée et de première classe pour des écritures en production. Vous pouvez parfois lire des volumes VMFS depuis Linux avec des outils d’assistance et en extraire les données. Traitez cela comme une technique de récupération, pas comme votre canal de migration principal.

2) Should I convert VMDK to qcow2 or raw?

Pour les VMs sensibles aux performances, raw (ou disques backés par ZVOL) est généralement le choix sûr. qcow2 est utile quand vous avez besoin de fonctionnalités comme les snapshots faciles sur stockage fichier ou le thin provisioning, mais cela ajoute une surcharge.

3) What’s the best option for live migration in Proxmox?

Le stockage partagé (généralement NFS, ou iSCSI avec un backend bloc partagé) rend la migration à chaud facile. ZFS local fonctionne encore avec des approches basées sur la réplication, mais ce n’est pas le modèle « datastore partagé ».

4) How do I keep downtime minimal for large VMs?

Préparez la majeure partie des données à l’avance et effectuez une synchronisation finale pendant le cutover, ou répliquez au niveau applicatif pour les systèmes à fort taux d’écriture. Copier simplement l’image disque ne vainc pas la physique pour des workloads à fort delta.

5) Do I need virtio drivers?

Linux gère généralement bien virtio. Windows nécessite souvent des pilotes virtio selon l’installation et le type de contrôleur. Si vous changez de contrôleur (ex. LSI → virtio-scsi), prévoyez la disponibilité des pilotes avant le cutover.

6) Mirrors or RAIDZ for ZFS VM storage?

Mirrors pour I/O aléatoire intensif des VMs. RAIDZ est excellent pour capacité et patterns séquentiels, mais il peut punir les écritures aléatoires et la latence tail — exactement ce que génèrent les VMs.

7) Is a SLOG device required for ZFS?

Non. SLOG importe seulement pour les écritures synchrones quand vous utilisez sync=standard et que les workloads émettent réellement des sync. Un mauvais SLOG peut dégrader les performances. N’en utilisez qu’après mesure et choisissez du matériel avec protection PLP.

8) NFS or iSCSI for shared storage?

NFS est généralement plus simple opérationnellement et plus facile à déboguer. iSCSI peut être excellent avec un multipath et une discipline SAN appropriés, mais il demande plus de configuration et apporte des modes de panne plus intéressants.

9) How do I validate performance after migration?

Mesurez des deux côtés : niveau hôte (fio, zpool iostat, multipath status) et niveau guest (latence applicative, latence filesystem, temps de commit DB). Les utilisateurs perçoivent la latence, pas le débit.

10) What’s the safest rollback strategy?

Conservez la VM ESXi originale éteinte mais intacte jusqu’à ce que vous ayez validé fonctionnalité et performances sur Proxmox, et passé une fenêtre d’observation définie. Le rollback doit être une procédure, pas une impression.

Conclusion : prochaines étapes que vous pouvez exécuter

Voici le chemin pratique qui vous tient à l’écart du club des « incidents de migration de stockage » :

1. Choisissez la zone d’atterrissage : ZFS local (intégrité + simplicité), NFS (partagé + ennuyeux) ou iSCSI (partagé + tranchant).
2. Benchmarquez ce qui compte : latence sync 4K et comportement tail, pas seulement le gros débit séquentiel.
3. Répétez une VM de bout en bout : copier, convertir, importer, démarrer, valider, rollback. Chronométrez.
4. Préparez les données tôt pour les VMs à faible taux de changement ; utilisez la réplication applicative pour les systèmes à fort débit d’écriture.
5. Coupez avec le rollback intact, et ne supprimez pas les données VMFS tant que la réalité ne vous a pas validé.

Si vous ne faites rien d’autre : mesurez, répétez et gardez le rollback ennuyeux et disponible. Voilà à quoi ressemble « interruption minimale » en production — moins de drame, plus de preuves.