Proxmox : SMB/CIFS lent pour les disques VM — pourquoi c’est mauvais et quoi utiliser à la place

À quoi ressemble vraiment « SMB est lent » dans Proxmox

Quand les gens disent « SMB est lent », ils veulent généralement dire une des trois choses :
le débit est faible, la latence est élevée, ou la performance est en dents de scie.
Les disques VM se soucient surtout des deux dernières. Une VM peut démarrer avec un débit médiocre.
Elle ne tolérera pas une latence d’écriture aléatoire de 500 ms pendant que l’hyperviseur attend des sémantiques synchrones.

La réalité d’astreinte n’est pas « copier un fichier est lent ». C’est :

• Le démarrage des VM prend 4–10 minutes, puis redevient normal une fois les caches chauds.
• Les bases de données se bloquent. Les journaux attendent. « fsync() taking too long » apparaît dans les logs.
• Latence interactive : les sessions SSH se figent une seconde, puis rattrapent le retard.
• Les opérations de cluster semblent hantées : les migrations se bloquent, les sauvegardes expirent, les processus qemu passent en état D.
• Le pire : tout va bien jusqu’à ce que ce ne soit plus le cas, puis c’est un incident affectant l’hôte entier.

Les disques VM sur SMB échouent souvent au « test de prévisibilité ». Une pile de stockage qui livre 5 ms la majeure partie du temps mais 800 ms
à chaque fois qu’un antivirus scanne le serveur de fichiers n’est pas « rapide », c’est « un générateur de surprises ».

Blague n°1 : SMB pour les disques VM, c’est comme utiliser un camion de livraison comme voiture de course. Il avance, mais personne n’est satisfait des temps au tour.

Pourquoi SMB/CIFS est inadapté aux disques VM

1) Les E/S des disques VM sont petites, synchrones et sensibles à la latence

Beaucoup d’E/S de VM sont des lectures/écritures aléatoires 4K–64K, avec beaucoup d’activité méta.
Les systèmes d’exploitation invités et les applications aiment aussi fsync(), les barrières et les validations de journaux.
Même quand votre application est « asynchrone », le système de fichiers invité ne l’est généralement pas.

SMB est un protocole de système de fichiers distant. Cela signifie :
chaque accusé de réception d’écriture est une conversation réseau plus un travail côté serveur plus les sémantiques de durabilité que le serveur applique.
Vous pouvez optimiser une partie avec les fonctionnalités SMB3, mais vous ne pouvez pas contourner la physique.

2) Des couches supplémentaires ajoutent des attentes supplémentaires (et des façons de bloquer)

Avec des disques VM sur SMB, le chemin des E/S est typiquement :

• Filesystem invité → couche bloc invitée → virtio-scsi/virtio-blk
• QEMU sur Proxmox → noyau hôte → client CIFS
• Stack réseau → switch → NIC → NIC du serveur de fichiers
• Serveur Samba/SMB → système de fichiers local du serveur → stockage du serveur

Chacune de ces couches peut introduire un blocage tête-de-file. Les montages CIFS peuvent se figer lors de reconnexions.
Le système de fichiers du serveur peut pauser lors des snapshots. Un antivirus peut verrouiller des fichiers.
Une écriture « simple » devient une réunion de comité.

3) Verrouillage, leases, oplocks et cache sont optimisés pour des fichiers — les disques VM se comportent comme des blocs chauds

SMB est excellent pour coordonner l’accès aux fichiers partagés. Les disques VM ne sont pas des « fichiers partagés » dans le sens heureux.
Ce sont de grandes images avec des modèles d’E/S aléatoires intenses, souvent accédées par un seul processus hyperviseur qui attend des sémantiques stables et une latence constante.

Les mécanismes de cache et de verrouillage de SMB (oplocks/leases) peuvent aider les charges de fichiers normales.
Mais quand vous exécutez une base de données à l’intérieur d’une VM à l’intérieur d’un fichier, vous construisez une tour de Jenga de caches.
Un retard de verrou transitoire devient « MySQL gelé » et vous déboguez la mauvaise couche.

4) Les sémantiques de basculement et de reconnexion ne sont pas ce que vos VM attendent

SMB peut se reconnecter. Ça semble bien jusqu’à ce que vous compreniez ce que « reconnecter » signifie pour un disque VM :
de longues pauses d’E/S. Threads QEMU bloqués. Timeouts invités. Parfois une corruption du système de fichiers si la pile ment sur la durabilité.

Oui, SMB3 a des handles durables, witness, multichannel, et plus.
En pratique, vous misez quand même l’exploitation sur la pile SMB du serveur de fichiers qui se comporte parfaitement en cas de panne partielle.
Ce pari perd plus souvent qu’on ne l’admet dans les postmortems.

5) Les sémantiques d’écritures synchrones peuvent discrètement vous saboter

Les disques VM, surtout avec les paramètres par défaut de QEMU et le comportement des invités, peuvent générer beaucoup d’écritures synchrones.
Côté serveur, celles-ci peuvent correspondre à un comportement « write-through », forçant des validations sur stockage stable.
Si le stockage sous-jacent du serveur n’a pas de cache en écriture protégé (BBU/flash-backed),
vos IOPS sont maintenant limités par la latence des disques rotatifs ou l’amplification d’écriture des SSD bas de gamme.

Même avec de bons disques, SMB ajoute des allers-retours. La latence domine.
Vous pouvez avoir une liaison 10GbE et quand même obtenir de mauvais IOPS si chaque I/O nécessite plusieurs attentes sérialisées.

6) L’avantage « permissions faciles » est sans rapport pour les disques VM

Les gens aiment SMB parce que les ACL s’intègrent aux systèmes d’identité d’entreprise.
Ça compte pour les partages utilisateurs. Ça a rarement de l’importance pour les images de disques VM.
Pour le stockage VM vous voulez : performance prévisible, panne prévisible et récupération prévisible.
L’élégance des ACL ne vous aidera pas à 3 h du matin quand la VM ERP du PDG est bloquée en état D.

Idée paraphrasée (John Allspaw, opérations/fiabilité) : « Les systèmes complexes échouent de façons complexes ; la fiabilité vient de l’apprentissage et de la résilience, pas d’une configuration optimiste. »

Faits et contexte historique intéressants (court, concret et pertinent)

1. SMB est né dans les années 1980 comme protocole de partage de fichiers réseau ; son ADN est « fichiers », pas « dispositifs bloc virtuels ».
2. CIFS était essentiellement la marque SMB1 et est devenu célèbre pour son côté bavard ; SMB2/3 ont beaucoup amélioré les choses, mais la réputation est gagnée.
3. SMB2 a réduit les allers-retours et introduit le contrôle de flux basé sur des crédits ; cela a aidé les WAN, mais les disques VM punissent toujours la latence.
4. SMB3 a ajouté chiffrement et multichannel ; excellent pour la sécurité et le débit, mais le chiffrement peut coûter du CPU et augmenter la gigue sous charge.
5. Les serveurs de fichiers Windows ont popularisé « le partage comme plateforme de stockage » ; la virtualisation a ramené l’industrie vers le bloc ou le stockage distribué pour les disques.
6. NFS est devenu un standard pour la virtualisation en partie parce que ses sémantiques et implémentations correspondaient mieux aux modèles d’accès d’images VM (surtout sur des arrays entreprise).
7. iSCSI a survécu parce que c’est ennuyeux : dispositif bloc, histoire multipath claire, sémantiques prévisibles pour les hyperviseurs.
8. La conception RADOS Block Device (RBD) de Ceph a été façonnée par le besoin de servir des E/S aléatoires de type VM à grande échelle avec réplication et gestion des pannes intégrées.
9. Les débats « NAS vs SAN » refont surface depuis des décennies ; les disques VM ramènent toujours la discussion aux fondamentaux de latence et d’ordre d’écriture.

Mode opératoire de diagnostic rapide : trouver le goulot en quelques minutes

Voici l’ordre que j’utilise quand un hôte Proxmox fait tourner des VM depuis SMB et que les utilisateurs se plaignent de « tout le cluster est lent ».
L’objectif n’est pas un benchmarking parfait. C’est localiser rapidement le facteur dominant pour décider : tuner, migrer ou remplacer.

Première étape : confirmer que c’est la latence du stockage, pas la CPU ou la mémoire

• Vérifiez la charge hôte et l’attente I/O. Si iowait pique lors des gels VM, vous êtes dans le bon quartier.
• Confirmez que les processus qemu sont bloqués en état D (sleep non interruptible). C’est généralement des attentes de stockage.

Deuxième étape : isoler où la latence est introduite

• Le montage SMB lui-même se bloque-t-il ? Cherchez des reconnexions CIFS, des timeouts ou « server not responding ».
• Le réseau perd-il des paquets ou négocie-t-il de mauvais réglages (MTU incohérent, contrôle de flux étrange) ?
• Le sous-système disque du serveur de fichiers est-il saturé ou force-t-il des écritures synchrones vers un média lent ?

Troisième étape : valider les sémantiques que vous avez configurées par erreur

• Options de montage SMB : mode de cache, actimeo, vers, multichannel, signing, encryption.
• Samba/serveur : strict sync, sync always, oplocks/leases, paramètres aio.
• Proxmox/QEMU : mode de cache disque, thread IO, backend aio, paramètres discard.

Quatrième étape : décider si vous perdez votre temps à tuner

Si la charge est des bases de données, des runners CI, des serveurs mail, ou tout ce qui fait beaucoup de petites écritures synchrones, cessez de tuner SMB et commencez à planifier la migration.
Si ce sont de légères VM de bureau et que la latence est « seulement » modérément mauvaise, vous pouvez tenter des changements — temporairement.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici des contrôles opérationnels réels que vous pouvez exécuter sur un hôte Proxmox et, quand pertinent, sur le serveur SMB.
Chaque tâche inclut : la commande, ce que signifie une sortie typique, et la décision à en tirer.

Task 1: Confirm iowait and run queue during the “slow” window

cr0x@pve1:~$ mpstat -P ALL 1 5
Linux 6.8.12-pve (pve1)  12/26/2025  _x86_64_ (32 CPU)

12:01:10 PM  CPU   %usr  %nice   %sys %iowait  %irq %soft  %steal  %idle
12:01:11 PM  all   12.3   0.0     4.1   38.7    0.0  0.6    0.0     44.3

Signification : 38.7% d’iowait est un signal d’alarme : les CPU sont inactifs mais bloqués en attente d’achèvement d’I/O.
Décision : considérer cela comme de la latence de stockage, pas un besoin de CPU. Passez aux vérifications du chemin d’E/S.

Task 2: Identify which devices are actually slow

cr0x@pve1:~$ iostat -x 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.52    0.00    3.90   36.10    0.00   49.48

Device            r/s     w/s   rMB/s   wMB/s  await  aqu-sz  %util
sda              0.2     1.1     0.0     0.1   2.10    0.00   0.3
dm-5            55.0   420.0     4.2    31.8  180.4   22.10  99.2

Signification : dm-5 est saturé avec ~180 ms d’attente moyenne. C’est « les VM vont se comporter comme si elles étaient saoules ».
Décision : mapper dm-5 au magasin SMB en arrière-plan (souvent une boucle, un fichier, ou une couche FUSE).
Si c’est le montage CIFS, passez aux vérifications spécifiques CIFS.

Task 3: See if qemu processes are blocked on I/O

cr0x@pve1:~$ ps -eo pid,stat,comm,args | grep -E "qemu-system|D " | head
21133 D    qemu-system-x86_64 /usr/bin/kvm -id 101 -name vm101 ...

Signification : L’état D indique un sommeil non interruptible, communément des attentes de stockage.
Décision : confirmer sur quel système de fichiers/montage ces E/S tombent ; rechercher des blocages CIFS et la latence côté serveur.

Task 4: Confirm the VM disk is on SMB storage in Proxmox

cr0x@pve1:~$ qm config 101 | sed -n '1,120p'
boot: order=scsi0;ide2;net0
memory: 8192
name: vm101
scsi0: smbstore:101/vm-101-disk-0.qcow2,size=80G
scsihw: virtio-scsi-single

Signification : Le disque est un fichier qcow2 sur un stockage nommé smbstore.
Décision : s’attendre à une double indirection (métadonnées qcow2 + sémantiques système de fichiers SMB). Planifier une migration vers raw-on-block ou RBD.

Task 5: Inspect the CIFS mount options on the Proxmox host

cr0x@pve1:~$ mount | grep cifs
//filesrv01/vmstore on /mnt/pve/smbstore type cifs (rw,relatime,vers=3.1.1,cache=strict,username=svc_pve,uid=0,gid=0,soft,nounix,serverino,mapposix,nofail)

Signification : soft peut provoquer des erreurs d’I/O lors d’incidents transitoires ; cache=strict peut augmenter les allers-retours de métadonnées.
Décision : retirez les options « mignonnes ». Évitez soft pour les disques VM ; de préférence — cessez d’utiliser SMB pour les disques VM.

Task 6: Check CIFS client stats for reconnects and timeouts

cr0x@pve1:~$ cat /proc/fs/cifs/Stats
Resources in use
CIFS Session: 1
Share (unique mount targets): 1
SMB Request/Response Buffer: 1 Pool size: 5
SMB Small Req/Resp Buffer: 3 Pool size: 30
Operations (MIDs): 0

0 session 0 share reconnects 17
Total vfs operations: 121044
Total timeouts: 9
Total retries: 203

Signification : les reconnexions/timeouts pendant les heures d’activité sont un risque de performance et d’intégrité des données.
Décision : considérer la stabilité du réseau et du serveur comme une exigence. Si vous ne pouvez pas ramener les reconnexions à zéro, migrez hors de SMB.

Task 7: Look for CIFS errors in the kernel log

cr0x@pve1:~$ dmesg -T | grep -i cifs | tail -n 8
[Thu Dec 26 12:03:18 2025] CIFS: VFS: Server filesrv01 has not responded in 60 seconds. Reconnecting...
[Thu Dec 26 12:04:19 2025] CIFS: VFS: cifs_reconnect: server reconnect succeeded

Signification : Ces 60 secondes sont une éternité pour les disques VM. Les invités vont se bloquer ; certains planteront.
Décision : arrêtez de prétendre que c’est acceptable pour un stockage VM de production. Réparez le réseau/serveur, ou migrez le stockage.

Task 8: Confirm network path health (drops, errors, MTU surprises)

cr0x@pve1:~$ ip -s link show dev bond0
4: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9123349901  9812331  0       214      0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    8331990021  8441122  0       0        0       0

Signification : Il y a des drops en réception. Ils peuvent être anodins ou corrélés aux pics.
Décision : si les drops augmentent pendant les blocages, investiguez les buffers du switch, les tailles de ring NIC, le contrôle de flux et la cohérence MTU bout en bout.

Task 9: Measure latency to the file server under load (not just ping once)

cr0x@pve1:~$ ping -c 20 -i 0.2 filesrv01
PING filesrv01 (10.20.0.10) 56(84) bytes of data.
64 bytes from 10.20.0.10: icmp_seq=1 ttl=63 time=0.380 ms
64 bytes from 10.20.0.10: icmp_seq=2 ttl=63 time=0.412 ms
64 bytes from 10.20.0.10: icmp_seq=9 ttl=63 time=12.881 ms
64 bytes from 10.20.0.10: icmp_seq=10 ttl=63 time=0.401 ms

--- filesrv01 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 3810ms
rtt min/avg/max/mdev = 0.362/1.104/12.881/2.776 ms

Signification : des pics occasionnels à 10–15 ms sont déjà mauvais pour des I/O sync-intensives. SMB amplifie ces pics.
Décision : si la gigue de latence existe, ne mettez pas les disques VM sur un système de fichiers distant qui dépend d’allers-retours réguliers.

Task 10: Quick and dirty I/O test on the SMB mount (latency tells the story)

cr0x@pve1:~$ fio --name=randwrite --directory=/mnt/pve/smbstore --size=2G --bs=4k --rw=randwrite --iodepth=16 --numjobs=1 --runtime=30 --time_based --direct=1
randwrite: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, ioengine=psync, iodepth=16
...
  write: IOPS=420, BW=1680KiB/s (1720kB/s)(50.0MiB/30500msec)
    lat (usec): min=2100, max=980000, avg=38000.12, stdev=92000.55

Signification : moyenne 38 ms avec une latence max proche de 1s. Ce n’est pas « un peu lent ». C’est « pauses VM ».
Décision : cessez d’utiliser SMB pour les disques VM pour cette charge. Vous pouvez tuner, mais vous ne pouvez pas éliminer une latence de queue à 980 ms.

Task 11: Check Proxmox storage configuration (what it thinks “smbstore” is)

cr0x@pve1:~$ cat /etc/pve/storage.cfg | sed -n '1,200p'
dir: local
        path /var/lib/vz
        content iso,vztmpl,backup

cifs: smbstore
        path /mnt/pve/smbstore
        server filesrv01
        share vmstore
        content images,backup
        username svc_pve
        vers 3.1.1

Signification : Proxmox considère ceci comme un stockage basé fichier adapté aux images et sauvegardes.
Décision : gardez SMB pour les sauvegardes/ISOs si nécessaire ; retirez images du contenu SMB si vous voulez moins d’incidents.

Task 12: Inspect QEMU disk cache mode (it can make things worse or merely different)

cr0x@pve1:~$ qm config 101 | grep -E '^scsi0:'
scsi0: smbstore:101/vm-101-disk-0.qcow2,cache=writeback,discard=on,size=80G

Signification : cache=writeback peut améliorer la sensation de vitesse mais augmente le rayon d’action d’un crash hôte et des blocages SMB.
Décision : n’utilisez pas le mode cache comme pansement pour un mauvais backend. Si vous avez besoin de writeback pour être « assez rapide », le backend est mauvais.

Task 13: Check the Samba server for synchronous write policies (server side)

cr0x@filesrv01:~$ testparm -sv 2>/dev/null | grep -E 'strict sync|sync always|aio read size|aio write size'
        aio read size = 1
        aio write size = 1
        strict sync = Yes
        sync always = Yes

Signification : sync always = Yes est une falaise de performance pour les disques VM : cela force des sémantiques de stockage stable à chaque écriture.
Décision : si c’est un serveur de fichiers pour documents, conservez la durabilité. Si vous essayez de l’utiliser comme SAN, arrêtez et redesign.

Task 14: Verify the file server’s filesystem and storage are not the real limiter

cr0x@filesrv01:~$ iostat -x 1 3
Device            r/s     w/s   rMB/s   wMB/s  await  aqu-sz  %util
nvme0n1         120.0   980.0    22.4   110.8   3.20    1.90  72.0
md0              10.0   320.0     1.1    38.0  45.00   18.50  99.0

Signification : Un dispositif est correct (NVMe), le device RAID/md est saturé à 99% et 45 ms d’attente.
Décision : même si SMB était parfait, le backend ne l’est pas. Les disques VM puniront ce design. Déplacez le stockage VM vers un stockage plus adapté aux VM.

Que choisir à la place : options de stockage sensées pour Proxmox

Si vous retenez une seule chose : les disques VM veulent du stockage bloc ou des sémantiques proches du bloc avec une latence prévisible.
Ils veulent aussi une histoire de récupération qui n’implique pas « espérer que le serveur de fichiers se reconnecte vite ».

Option A : NVMe/SSD local avec ZFS (rapide, prévisible, étonnamment opérable)

Pour beaucoup d’équipes Proxmox, la meilleure réponse est aussi la moins glamour :
placez les disques VM sur des NVMe/SSD locaux et utilisez ZFS pour l’intégrité et les snapshots.
Vous perdez le « stockage partagé » pour la migration à chaud sauf si vous répliquez ou utilisez la réplication ZFS.
Vous gagnez une latence de queue qui ne ressemble pas à un moniteur cardiaque.

Quand ZFS local est gagnant :

• Vous pouvez tolérer des migrations planifiées ou un basculement basé sur la réplication.
• Votre charge est sensible à la latence et vous privilégiez la cohérence plutôt que la centralisation.
• Vous voulez des checksums d’intégrité et des outils de snapshot raisonnables.

L’essentiel : stockez les disques VM en ZVOLs (périphériques bloc) ou fichiers raw sur ZFS, pas qcow2 sur SMB. Donnez de la RAM à ZFS. Surveillez l’amplification d’écriture.

Option B : Ceph RBD (stockage partagé fait la difficile, et c’est la bonne manière)

Si vous avez besoin de stockage partagé et de migration à chaud à l’échelle, Ceph est la réponse native Proxmox.
Ce n’est pas « facile ». C’est un système de stockage avec ses propres modes de panne et exigences opérationnelles.
Mais il est conçu pour ce que vous faites : fournir des périphériques bloc aux hyperviseurs avec réplication et récupération intégrées.

Quand Ceph est gagnant :

• Vous avez besoin de disques VM partagés entre nœuds.
• Vous avez besoin d’une tolérance de panne sans un serveur de fichiers unique comme goulet.
• Vous êtes prêt à exploiter le stockage comme un système de première classe : surveillance, planification de capacité et discipline de mises à jour.

Si votre cluster est petit et que vous n’avez pas la maturité opérationnelle pour Ceph, ne le forcez pas. Le stockage partagé n’est pas gratuit.

Option C : iSCSI + LVM (stockage bloc terne, fonctionne bien, sémantiques prévisibles)

iSCSI est un choix fréquent « l’adulte dans la pièce » : un array expose des LUNs, les hôtes voient des blocs, multipath gère les pannes de chemin.
Vous pouvez empiler LVM ou LVM-thin dessus dans Proxmox.
Les performances sont généralement solides, et le comportement sous charge est plus facile à raisonner que SMB.

Où iSCSI brille :

• Vous avez un véritable array ou une cible bien construite avec cache et redondance appropriés.
• Vous voulez un stockage central et des performances cohérentes.
• Vous avez besoin d’une histoire multipath claire.

Option D : NFS (mieux que SMB pour les images VM, mais pas mon premier choix pour charges d’écriture)

NFS est couramment utilisé pour les images VM et peut bien fonctionner lorsqu’il est soutenu par un NAS d’entreprise optimisé pour la virtualisation.
Il tend à avoir moins de « bagages de serveur Windows » et des sémantiques UNIX plus simples dans de nombreux environnements.
Pourtant : c’est toujours un système de fichiers réseau. La latence et le comportement côté serveur comptent toujours.

Si vous utilisez NFS, choisissez un appliance de stockage conçu et supporté pour le stockage d’hyperviseur,
et validez la latence sous charge d’écritures synchrones.

Option E : SMB est adapté pour les sauvegardes, ISOs, templates et stockage froid

SMB n’est pas malveillant. Il est juste sollicité pour être ce qu’il n’est pas.
Utilisez-le pour :

• Repositories ISO
• Datastores Proxmox Backup Server (mieux sur disques locaux, mais SMB peut convenir pour des copies secondaires)
• Exporter des sauvegardes vers un autre système
• Templates et artefacts « non sensibles à la latence »

Gardez les disques VM hors de SMB à moins que la charge et l’impact d’une panne soient triviaux.
Si les deux sont triviaux, vous n’aviez probablement pas besoin de Proxmox — mais nous y voilà.

Blague n°2 : Le moyen le plus rapide d’accélérer le stockage VM sur SMB est d’arrêter d’utiliser le stockage VM sur SMB.

Trois mini-récits d’entreprise de l’univers « ça avait l’air OK »

Mini-récit 1 : L’incident causé par une mauvaise hypothèse (« 10GbE veut dire que c’est rapide »)

Une entreprise de taille moyenne avait un cluster Proxmox pour des services internes : Git, CI, quelques serveurs d’applications Windows, et une base de données que tout le monde faisait semblant de ne pas considérer comme critique.
Le stockage était un partage SMB sur un serveur de fichiers Windows parce que le serveur avait déjà « beaucoup d’espace », et l’équipe infra aimait les outils ACL.
Ils avaient aussi des uplinks 10GbE, ce qui les faisait se sentir modernes et donc en sécurité.

Le premier incident sérieux a commencé pendant un scan de sécurité de routine. Le scanner a frappé le datastore VM.
L’antivirus du serveur de fichiers a vu des milliers de modifications au niveau bloc à l’intérieur des fichiers qcow2 comme « intéressantes ».
Le CPU a grimpé sur le serveur de fichiers, la profondeur de file disque a augmenté, et les temps de réponse SMB sont passés de sous-millisecondes à « éventuellement ».

Côté Proxmox, les processus qemu se sont empilés en état D. Les invités ne plantaient pas immédiatement — ils ont simplement cessé de répondre.
Le monitoring rapportait des VM saines parce que les processus existaient et les hôtes étaient up. Les utilisateurs ont signalé « tout est gelé ».
L’équipe a rebooté un nœud Proxmox, ce qui a empiré le problème : des écritures en cache non validées sont devenues des vérifications de système de fichiers invité et de la corruption partielle.

L’hypothèse erronée était simple : 10GbE de bande passante équivaut à performance de stockage VM.
Ils avaient le débit. Ils n’avaient pas une latence basse et stable sous écritures aléatoires synchrones.
Après le postmortem, ils ont déplacé les disques VM vers des miroirs ZFS locaux et ont utilisé la réplication pour les quelques VM qui nécessitaient une récupération plus rapide.
Le serveur de fichiers est revenu à ce pour quoi il était bon : les fichiers.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (modes cache et « juste mettre en writeback »)

Une autre organisation exploitait une petite ferme Proxmox où quelqu’un a remarqué que les VM sur SMB étaient lentes lors des connexions du matin.
Un ingénieur bien intentionné a basculé le mode cache disque QEMU en writeback pour « la performance ».
Ça a marché. Les vagues de connexions étaient plus fluides. Le volume de tickets a chuté. Tout le monde est passé à autre chose.

Deux mois plus tard, un événement d’alimentation a touché le rack. L’onduleur a tenu, puis non. Les hôtes sont tombés brutalement.
Au redémarrage, la plupart des VM sont revenues. Quelques-unes non. Une VM base de données a démarré, mais l’application a affiché des erreurs d’intégrité plus tard dans la journée.
Personne n’avait une déclaration claire « nous avons perdu X secondes d’écritures » parce que le chemin de stockage impliquait plusieurs caches avec des sémantiques de durabilité différentes.

Le retour de bâton n’était pas que writeback est toujours mauvais. C’est que writeback a été utilisé pour masquer un backend incapable de satisfaire les besoins de latence sync de la charge.
Ils ont optimisé le symptôme et augmenté l’ambiguïté en cas de panne.
La correction ultérieure fut ennuyeuse : passer à iSCSI depuis un petit array avec cache protégé et configurer correctement multipath.
Les performances sont devenues stables et les pannes compréhensibles.

Il existe une forme particulière de dette opérationnelle où vous « accélérez » les choses en réduisant la fréquence à laquelle vous demandez la vérité.
Ça ressemble à du succès jusqu’au jour où la réalité porte plainte.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation (mesurer la latence de queue, pas les moyennes)

Une entreprise fintech-ish (du genre à aimer les tableaux de bord) a planifié une expansion Proxmox et voulait du stockage partagé pour les migrations.
SMB a été proposé parce qu’il y avait une paire de serveurs de fichiers hautement disponible existante et que l’équipe stockage promettait « c’est enterprise ».
L’équipe SRE n’a pas argumenté sur le goût. Elle a demandé une fenêtre de test.

Ils ont exécuté fio depuis un nœud Proxmox vers le montage SMB proposé avec une charge modelée sur les disques VM : écritures aléatoires 4K, moteur sync-ish, iodepth ajusté pour imiter la contention.
La latence moyenne n’était pas terrible. Le 99.9e centile était catastrophique, avec des pics périodiques de centaines de millisecondes.
Puis ils ont répété le test tout en déclenchant des activités opérationnelles normales sur le serveur de fichiers : snapshots, rotations de logs, et une tâche de sauvegarde.
La queue s’est encore dégradée.

Le résultat fut politiquement gênant mais opérationnellement parfait : SMB a été approuvé seulement pour les sauvegardes et le stockage ISO.
Les disques VM sont allés vers Ceph RBD parce que l’organisation avait déjà l’appétit d’exploiter un système distribué, et elle voulait une tolérance de panne au niveau nœud.
Quand un switch top-of-rack a plus tard mal fonctionné et causé une perte de paquets transitoire, Ceph s’est dégradé mais est resté utilisable ; SMB aurait probablement transformé ça en blocage VM à l’échelle.

La pratique qui les a sauvés n’était pas magique. C’était mesurer la bonne chose (la latence de queue) et tester pendant du bruit de fond réaliste.
Ennuyeux, correct, et cela a évité un incident qui aurait été attribué à « l’instabilité aléatoire de Proxmox ».

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: VMs “freeze” but host CPU is mostly idle

Cause racine : latence élevée du stockage et E/S bloquées (qemu en état D), souvent lors de reconnexions CIFS ou pauses côté serveur.

Correction : confirmer avec mpstat, iostat, dmesg et les stats CIFS ; puis migrer les disques VM hors de SMB (Ceph RBD, iSCSI, ou ZFS local).

2) Symptom: Backups are fine, but interactive workloads are awful

Cause racine : le débit est correct, mais la latence de queue ne l’est pas. Les flux de sauvegarde sont séquentiels ; les disques VM sont aléatoires et sync-intensifs.

Correction : benchmarquez avec des E/S aléatoires petits blocs et examinez les max/percentiles. Ne vous fiez pas à la vitesse de copie de fichier comme proxy.

3) Symptom: Performance is great after reboot, then degrades

Cause racine : la chaleur des caches masque la latence du backend jusqu’à ce que le working set croisse ; les caches metadata et writeback SMB masquent la réalité.

Correction : testez froid et chaud. Surveillez l’éviction des caches côté serveur, le comportement de writeback et les files d’attente disque. Préférez un stockage à latence cohérente.

4) Symptom: Random “Input/output error” inside guests

Cause racine : CIFS monté avec soft ou des timeouts/retries agressifs lors de pannes transitoires.

Correction : évitez soft pour le stockage VM ; corrigez la stabilité réseau ; mieux encore, cessez d’utiliser SMB pour les disques VM.

5) Symptom: Migration stalls or takes forever

Cause racine : le stockage SMB partagé devient un point de sérialisation ; opérations metadata et verrous ralentissent sous charge ; la gigue réseau pénalise.

Correction : utilisez Ceph/disque partagé pour la migration à chaud, ou utilisez du stockage local avec réplication et acceptez une fenêtre de maintenance planifiée.

6) Symptom: Everything goes bad when “someone runs a scan” or “backup starts”

Cause racine : les tâches background du serveur de fichiers (scan AV, snapshots, sauvegardes) concurrencent les I/O VM et introduisent des pics de latence.

Correction : séparez les préoccupations. Le stockage des disques VM ne doit pas partager le même appliance et les mêmes politiques que les partages utilisateurs.

7) Symptom: Good latency in ping, bad latency in disk I/O

Cause racine : les opérations SMB ne sont pas ICMP ; elles impliquent CPU serveur, verrous système de fichiers, journaling, et validations de stockage.

Correction : mesurez ce qui compte : la latence I/O et le comportement de queue avec fio et des traces de charges VM réelles.

Checklists / plan étape par étape

Checklist A: If you’re already on SMB and suffering

1. Confirmez que le symptôme est une latence I/O : exécutez mpstat et iostat -x pendant l’incident.
2. Vérifiez la santé du client CIFS : cherchez des reconnexions/timeouts dans /proc/fs/cifs/Stats et les logs noyau.
3. Validez les bases réseau : drops/erreurs, cohérence MTU, et gigue de latence vers le serveur.
4. Inspectez les contraintes côté serveur : file disque, politiques sync, jobs de snapshot, scans AV.
5. Arrêtez l’hémorragie : déplacez d’abord les VM les plus bruyantes (bases de données, CI, mail) vers SSD locaux ou stockage bloc.
6. Changez l’usage du stockage Proxmox : retirez images du stockage SMB et gardez-le pour sauvegardes/templates.
7. Construisez le remplacement : choisissez Ceph/iSCSI/ZFS local selon la réalité opérationnelle, pas l’aspiration.
8. Migrez avec un plan : planifiez des fenêtres, testez les restaurations, et validez l’intégrité des systèmes de fichiers invités après les déplacements.

Checklist B: Choosing the right alternative

• Besoins de migration à chaud et disques partagés ? Préférez Ceph RBD ou un SAN iSCSI/FC adapté.
• Besoin de la simplicité pour des performances fiables ? Miroirs NVMe locaux avec ZFS, plus réplication pour les charges critiques.
• Vous avez déjà un NAS entreprise conçu pour VM ? NFS peut être acceptable ; prouvez la latence de queue d’abord.
• Vous utilisez un serveur Windows parce qu’il existe ? Servez-vous en pour fichiers et export de sauvegardes, pas pour les disques VM primaires.

Checklist C: Migration safety moves (because storage changes are where careers go to die)

1. Faites une sauvegarde fraîche et faites un test de restauration d’au moins une VM vers le stockage cible.
2. Déplacez une VM non critique en premier et validez performance et logs pendant une journée complète.
3. Suivez la latence de queue (99e/99.9e), pas seulement les moyennes, avant et après.
4. Documentez le rollback : où est l’ancienne image disque, comment la rattacher, et quelles dépendances DNS/app existent.
5. Ce n’est qu’ensuite que vous migrez les charges bruyantes.

FAQ

1) Is SMB always slow, or just slow for VM disks?

Principalement lent (ou instable) pour les disques VM. SMB peut être parfaitement adapté aux fichiers utilisateurs, médias, sauvegardes et artefacts.
Les disques VM transforment la latence et la gigue en panne.

2) What if I’m using SMB3.1.1 with multichannel and a fast Windows server?

Vous pouvez améliorer le débit et la résilience, mais vous utilisez toujours un système de fichiers réseau pour des E/S sensibles à la latence.
Si votre charge est légère, cela peut être acceptable. Pour les bases de données et serveurs chargés, c’est toujours le mauvais outil.

3) Can I make SMB acceptable with mount options?

Vous pouvez réduire les dégâts. Vous ne pouvez pas le faire se comporter comme un backend conçu pour les disques VM.
Si votre « correction » est un tas d’options de montage plus un tableur de politiques « ne pas toucher », vous avez déjà perdu.

4) Is qcow2 on SMB worse than raw on SMB?

Généralement oui. qcow2 ajoute des lectures/écritures de métadonnées et un comportement de fragmentation qui amplifient la latence sur les systèmes de fichiers distants.
raw réduit la surcharge, mais ne résout pas les sémantiques fondamentales de latence et de panne de SMB.

5) Is NFS really better than SMB for Proxmox VM disks?

Souvent, oui, surtout sur un stockage conçu pour la virtualisation. Mais NFS reste un système de fichiers réseau.
Il peut être excellent, médiocre ou terrible selon le serveur et le réseau. Mesurez la latence de queue sous charge réaliste.

6) Should I run Ceph for a small 3-node cluster?

Peut-être. Proxmox rend Ceph plus accessible, mais c’est toujours un système distribué.
Si vous pouvez vous engager sur la surveillance, la discipline de capacité et un réseau prévisible, ça peut bien fonctionner.
Si votre équipe peine avec l’hygiène de stockage de base, ZFS local plus réplication est généralement le pari plus sûr.

7) What’s the simplest “good enough” architecture for reliable VM storage?

Miroirs NVMe locaux sur chaque nœud avec ZFS, plus réplication planifiée pour les VM critiques, et de bonnes sauvegardes.
Ce n’est pas aussi glamour que du stockage partagé, mais c’est extrêmement efficace et facile à raisonner quand ça casse.

8) Why do VM freezes correlate with “file server maintenance jobs”?

Parce que ces jobs causent des pics de latence : snapshots, antivirus, déduplication, tiering, synchronisations cloud et agents de sauvegarde se partagent les I/O et les verrous.
Les disques VM ressentent ces pics comme des écritures bloquées et des threads I/O bloqués.

9) If SMB is bad for VM disks, why does Proxmox support CIFS storage at all?

Parce que c’est utile pour d’autres types de contenu : images ISO, sauvegardes, templates et partage de fichiers général.
« Supporté » ne veut pas dire « bon pour chaque charge ».

10) What’s the single metric I should alert on for this problem?

La latence disque au niveau hôte (await) et la latence fsync visible par les invités si vous pouvez la collecter.
Alertez aussi sur les reconnexions/timeouts CIFS — ce sont des signaux précoces avant que les utilisateurs ne commencent à crier.

Prochaines étapes que vous pouvez faire cette semaine

Si vous faites tourner des disques VM sur SMB aujourd’hui et que vous tenez à la disponibilité, traitez cela comme une dette technique avec intérêt.
Votre objectif n’est pas « rendre SMB plus rapide ». Votre objectif est « cesser de laisser le chemin de stockage VM dépendre de l’humeur d’un serveur de fichiers ».

1. Exécutez le mode opératoire de diagnostic rapide pendant votre prochaine période lente et capturez iowait, iostat, stats CIFS et extraits de dmesg.
2. Classez les charges : identifiez les 5 VM principales par IOPS d’écriture et sensibilité à fsync (bases de données, CI, mail, annuaires).
3. Choisissez votre cible :
   • ZFS local si vous voulez de la prévisibilité rapidement.
   • Ceph RBD si vous avez besoin de stockage partagé et pouvez l’exploiter.
   • iSCSI si vous avez un array et voulez des sémantiques bloc ennuyeuses mais fiables.
4. Déplacez une VM, validez la latence de queue et la stabilité pendant une journée complète, puis déplacez le reste par lots.
5. Démotez SMB pour sauvegardes/templates/ISOs. Laissez-le faire ce qu’il sait faire.

Le bénéfice est immédiat : moins de « gels aléatoires », moins de redémarrages nocturnes et moins de réunions où il faut expliquer que le stockage « était techniquement up ».
Les systèmes de production ne se préoccupent pas du « techniquement ».