Proxmox LVM-thin « out of data space » : libérer de l’espace sans détruire les VM

octobre 7, 2025 • février 3, 2026 • Lecture : 30 min • Views: 6

Cet article vous a aidé ?

Vous le remarquez d’abord quand les sauvegardes échouent. Puis une VM se fige en plein écriture. Ensuite Proxmox commence à afficher des erreurs comme
thin-pool ... out of data space et soudain votre petit hôte de virtualisation calme se comporte comme une valise faite par un enfant : plus rien ne rentre et tout est par terre.

La bonne nouvelle : un thin pool LVM qui indique « out of data space » est généralement récupérable sans supprimer les VM. La mauvaise nouvelle :
il faut être méthodique, car « libérer de l’espace » sur un stockage thin provisioned n’est pas la même chose que supprimer des fichiers.
Réparons le pool, pas « nettoyons autour ».

Ce que « out of data space » signifie vraiment (et ce que ce n’est pas)

Le stockage local-lvm de Proxmox est souvent un thin pool LVM : un grand volume logique (le « thinpool ») à partir duquel les disques de VM
(thin LVs) sont alloués à la demande. Vous pouvez surprovisionner : présenter 10 To de disques virtuels soutenus par 2 To de blocs réels,
tant que les invités n’écrivent pas réellement tout cela.

Quand le thinpool indique « out of data space », cela signifie que le LV données du pool (la partie qui stocke les blocs réels)
est plein. Les écritures vers n’importe quel volume thin peuvent se bloquer ou échouer. Selon vos paramètres, LVM peut suspendre le pool pour éviter
la corruption, ce qui ressemble à un « gel » au niveau des VM.

Deux nuances critiques qui vous empêchent de prendre la pire décision à 2 h du matin :

Supprimer des fichiers à l’intérieur d’une VM ne libère pas forcément de l’espace dans le thinpool à moins que discard/TRIM soit activé et exécuté.
Sans discard, l’hôte pense toujours que ces blocs sont utilisés.
Les snapshots ne sont pas une « assurance gratuite ». Les snapshots thin peuvent grossir énormément si le disque de base continue de changer.
Les snapshots sont en copy-on-write ; un churn soutenu les transforme en voraces silencieux d’espace.

Si vous retenez une chose : votre mission est de déterminer si le pool est à court de données, de métadonnées, ou des deux, puis
choisir la manière la moins risquée de récupérer ou d’ajouter de l’espace. La panique est optionnelle.

Blague n°1 : Un thinpool ne « manque pas d’espace », il « atteint une pleine utilisation » juste avant que votre SLA n’atteigne un nouveau plancher.

Playbook de diagnostic rapide (vérifications première/seconde/troisième)

C’est la séquence « ne pas se perdre dans les détails » que j’utilise quand un hôte Proxmox m’appelle pour de l’espace thinpool.
L’objectif est de localiser le véritable goulot en moins de cinq minutes.

Premier : confirmer ce qui est plein (données vs métadonnées) et si le pool est suspendu

Vérifiez l’utilisation du thinpool avec lvs (data% et meta%).
Vérifiez l’état du pool : est-il actif, en lecture seule, ou suspendu ?

Second : identifier ce qui consomme les blocs (snapshots, sauvegardes, volumes orphelins)

Listez les LVs avec tailles et data% pour repérer les gros écrivains.
Listez les snapshots dans Proxmox et dans LVM (ce n’est pas toujours la même « histoire »).
Vérifiez les volumes abandonnés provenant de VM supprimées ou de restaurations échouées.

Troisième : décider du levier d’urgence (récupérer vs étendre vs les deux)

Si vous pouvez ajouter de la capacité rapidement : étendez le VG et le thinpool.
Si vous ne pouvez pas : récupérez de l’espace en supprimant des snapshots et en exécutant discard/trim, puis envisagez des mesures temporaires.
Si les métadonnées sont le facteur limitant : étendez les métadonnées maintenant ; c’est petit, rapide et souvent le vrai coupable.

Si vous hésitez : étendre le thinpool (données + métadonnées) est l’option la moins dramatique si vous avez des extents libres dans le VG ou pouvez ajouter un disque.
Récupérer de l’espace est plus subtil et a tendance à surprendre les gens.

Faits et contexte intéressants (pourquoi LVM-thin se comporte ainsi)

Ce ne sont pas des anecdotes pour le plaisir. Chaque point correspond à un mode d’échec ou à une meilleure habitude opérationnelle.

Les snapshots LVM précèdent la thin provisioning et étaient réputés pour leurs chutes de performance. Les snapshots classiques utilisaient
un volume COW séparé et pouvaient ralentir fortement quand ils étaient presque pleins ; les snapshots thin ont amélioré la mécanique mais n’ont pas supprimé
la réalité : « l’espace croît avec le churn ».
La thin provisioning est une promesse, pas une garantie. Il est mathématiquement possible de provisionner plus de capacité virtuelle que vous ne pouvez physiquement stocker ; le pool reste sain si la croissance d’écriture reste maîtrisée.
Les thinpools ont deux contraintes : data et metadata. Les métadonnées suivent le mappage des blocs virtuels vers les blocs physiques. Vous pouvez avoir beaucoup d’espace de données et mourir d’un épuisement des métadonnées.
La pression sur les métadonnées augmente avec la fragmentation et les snapshots. Plus de mappages, plus d’événements copy-on-write, et plus de churn au niveau bloc augmentent la consommation de métadonnées.
Discard/TRIM n’est pas devenu normal opérationnellement du jour au lendemain. De nombreuses piles ont par défaut « discard off » pendant des années parce que les premières implémentations causaient des problèmes de performance ou des comportements inattendus sur certains stockages.
Les valeurs par défaut de Proxmox pour « local-lvm » sont conçues pour la commodité, pas pour la perfection. C’est un point de départ raisonnable pour les labs et petits clusters, mais il faut surveiller et ajuster.
L’auto-extension du thin pool existe, mais ce n’est pas une nounou. LVM peut auto-étendre un thinpool lorsqu’il atteint un seuil, mais seulement si le VG a des extents libres. Si le VG est aussi plein, vous cognez encore le mur.
La récupération d’espace est une négociation multi-couches. Le système invité doit marquer les blocs libres, le système de fichiers doit supporter le trim, le chemin du disque virtuel doit laisser passer discard, et le thinpool doit l’accepter.

Tâches pratiques : commandes, sorties, décisions

Ci-dessous des tâches réelles que vous pouvez exécuter sur un nœud Proxmox. Chacune inclut : la commande, une sortie représentative, et la décision que vous prenez à partir de là. Ne copiez pas aveuglément. Lisez la sortie comme un rapport diagnostique — parce que ça en est un.

Tâche 1 : Identifier le thinpool et voir data% et meta%

cr0x@server:~$ sudo lvs -a -o+seg_monitor,lv_attr,lv_size,data_percent,metadata_percent,pool_lv,origin vg0
  LV                      VG  Attr       LSize   Data%  Meta%  Pool          Origin  Monitor
  root                    vg0 -wi-ao----  96.00g
  swap                    vg0 -wi-ao----   8.00g
  data                    vg0 twi-aotz--   1.60t  99.12  71.43                         monitored
  data_tmeta              vg0 ewi-ao----   8.00g
  data_tdata              vg0 ewi-ao----   1.60t
  vm-101-disk-0           vg0 Vwi-aotz--  80.00g                 data                 monitored
  vm-102-disk-0           vg0 Vwi-aotz-- 200.00g                 data                 monitored

Ce que ça signifie : Le thinpool LV est vg0/data (l’attribut commence par twi-). Data% est 99.12% : vous êtes
effectivement à court. Meta% est 71.43% : les métadonnées ne sont pas le blocage immédiat, mais c’est en tendance.

Décision : Considérez cela comme une urgence. Arrêtez tout ce qui écrit intensivement (sauvegardes, restaurations, tempêtes de logs),
et choisissez maintenant entre récupérer/étendre. Si Meta% était à 95–100%, priorisez l’extension des métadonnées en premier.

Tâche 2 : Vérifier si le thinpool est suspendu (les écritures peuvent se bloquer)

cr0x@server:~$ sudo dmsetup status /dev/vg0/data
0 3355443200 thin-pool 0 5118/524288 131072/1048576 - rw no_discard_passdown queue_if_no_space

Ce que ça signifie : Le pool est en mode rw et réglé sur queue_if_no_space. Cela signifie que les écritures peuvent se mettre en file
d’attente lorsqu’il est plein au lieu d’échouer vite. Cela paraît « plus sûr » jusqu’à ce que vous réalisiez que ça peut engendrer un deadlock pour vos charges.

Décision : Si vous êtes coincé dans une spirale de file d’attente d’écriture, vous devez libérer ou ajouter de l’espace. Envisagez aussi si
queue_if_no_space est le comportement souhaité sur le long terme.

Tâche 3 : Vue rapide au niveau Proxmox : quel stockage est plein ?

cr0x@server:~$ pvesm status
Name      Type     Status           Total        Used       Avail      %
local     dir      active        100789248    22133704    73419180   21.96%
local-lvm lvmthin  active       1753219072  1738919936     14299136   99.18%

Ce que ça signifie : local (stockage par répertoire) est correct. local-lvm est presque plein. Les disques VM sur local-lvm sont à risque.

Décision : Concentrez-vous sur la remédiation LVM-thin, pas sur des suppressions aléatoires dans /var/lib/vz.

Tâche 4 : Trouver les pires coupables au niveau LV

cr0x@server:~$ sudo lvs -o lv_name,lv_size,lv_attr,data_percent,metadata_percent --sort -lv_size vg0
  LV            LSize   Attr       Data%
  data          1.60t   twi-aotz--  99.12
  vm-102-disk-0 200.00g Vwi-aotz--
  vm-101-disk-0  80.00g Vwi-aotz--
  root           96.00g -wi-ao----
  swap            8.00g -wi-ao----

Ce que ça signifie : Les volumes thin n’affichent pas Data% ici (c’est au niveau pool), mais cela vous indique quelles VM ont de gros disques virtuels.
Une grande taille virtuelle n’est pas la preuve d’une grande utilisation physique, mais c’est une bonne liste pour « quelles VM churnent probablement ».

Décision : Corrélez ces VM avec les jobs de sauvegarde récents, la maintenance de bases de données, les pics de logs ou la prolifération de snapshots.

Tâche 5 : Vérifier le rapport détaillé du thinpool (chunks, id de transaction, features)

cr0x@server:~$ sudo lvs -o+chunk_size,lv_health_status,thin_count,discards vg0/data
  LV   VG  Attr       LSize  Pool Origin Data%  Meta%  Chunk  Health  #Thins Discards
  data vg0 twi-aotz-- 1.60t             99.12  71.43  64.00k  ok      12     passdown

Ce que ça signifie : La taille de chunk est 64K. Les discards sont réglés sur passdown (bon signe). La santé est ok (c’est plein, mais pas corrompu).

Décision : Si les discards sont désactivés ici, le trimming au niveau hôte n’aidera pas beaucoup. Vous devrez activer le support discard
puis exécuter des trims dans les invités ou sur l’hôte où c’est applicable.

Tâche 6 : Lister les snapshots Proxmox (les snapshots « humains »)

cr0x@server:~$ qm listsnapshot 102
`-> pre-upgrade
    `-> weekly-retain-1
`-> weekly-retain-2

Ce que ça signifie : La VM 102 a plusieurs snapshots. Chaque snapshot peut pinner des blocs et provoquer de la croissance.

Décision : Si vous manquez d’espace, supprimez les snapshots inutiles — en commençant par les plus anciens, après avoir confirmé
qu’ils ne font pas partie d’un workflow de sauvegarde/réplication actif.

Tâche 7 : Supprimer un snapshot Proxmox en toute sécurité (et à quoi faire attention)

cr0x@server:~$ qm delsnapshot 102 weekly-retain-2
Deleting snapshot 'weekly-retain-2'...
TASK OK

Ce que ça signifie : Proxmox a planifié la fusion du snapshot. Sur un stockage thin, les merges peuvent causer de l’I/O. Ils peuvent aussi
temporairement augmenter l’activité d’écriture. Ce n’est pas une raison pour éviter la suppression ; c’est une raison pour la faire intentionnellement.

Décision : Si le pool est à 99–100% plein, envisagez d’arrêter d’abord les gros écrivains pour que la fusion ne se heurte pas au churn de production.

Tâche 8 : Détecter les LVs orphelins (le problème « le stockage est hanté »)

cr0x@server:~$ sudo lvs vg0 | grep -E 'vm-[0-9]+-disk-[0-9]+' | awk '{print $1}'
vm-101-disk-0
vm-102-disk-0
vm-109-disk-0
vm-999-disk-0

cr0x@server:~$ ls /etc/pve/qemu-server/ | sed 's/\.conf$//' | sort | tail -n +1
101
102
109

Ce que ça signifie : Il y a un LV vm-999-disk-0 mais pas de 999.conf. Ce disque est probablement orphelin : créé lors d’une restauration échouée,
d’un clone ou d’une manipulation manuelle.

Décision : Vérifiez qu’il est vraiment inutilisé, puis supprimez-le pour récupérer de l’espace. Ne le supprimez pas parce qu’il « a l’air bizarre » ; supprimez-le parce que vous avez prouvé qu’il n’est pas utilisé.

Tâche 9 : Prouver qu’un orphelin suspect n’est référencé par aucune config VM

cr0x@server:~$ grep -R "vm-999-disk-0" /etc/pve/qemu-server/

cr0x@server:~$ echo $?
1

Ce que ça signifie : Le code de sortie 1 indique « introuvable ». C’est une preuve (pas une certitude) qu’il n’est pas attaché.

Décision : Vérifiez aussi les processus QEMU en cours et les mappages de périphériques bloc avant la suppression.

Tâche 10 : Confirmer qu’aucune VM en cours n’a le LV ouvert

cr0x@server:~$ sudo lsof | grep "/dev/vg0/vm-999-disk-0" | head

Ce que ça signifie : Pas de sortie suggère que rien ne l’a ouvert. Sur un hôte chargé, lsof peut être lourd ; utilisez-le prudemment.

Décision : S’il n’est pas ouvert et pas référencé, vous pouvez le supprimer.

Tâche 11 : Supprimer un LV thin orphelin

cr0x@server:~$ sudo lvremove -y /dev/vg0/vm-999-disk-0
  Logical volume "vm-999-disk-0" successfully removed.

Ce que ça signifie : Vous avez supprimé le mapping LV. L’espace devrait revenir au pool immédiatement (même si les métadonnées thin et la comptabilité du noyau peuvent légèrement prendre du retard).

Décision : Re-vérifiez Data% et Meta% du thinpool pour confirmer l’impact. Si rien n’a changé, vous n’avez pas supprimé la bonne chose — ou le pool est bloqué par les métadonnées.

Tâche 12 : Re-vérifier l’utilisation du pool après suppressions

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vg0/data
  LV   LSize  Data%  Meta%
  data 1.60t  96.44  70.90

Ce que ça signifie : Vous avez récupéré ~3% du pool. Cela peut suffire à débloquer les opérations, mais ce n’est pas une solution si la croissance continue.

Décision : Si vous êtes toujours au-dessus d’environ 90% et que vous avez du churn en cours, étendez le pool. La récupération est une mesure palliative à moins que vous ne changiez le comportement.

Tâche 13 : Vérifier l’espace libre du VG (peut-on étendre sans ajouter de disques ?)

cr0x@server:~$ sudo vgs -o vg_name,vg_size,vg_free,vg_free_count
  VG   VSize  VFree   #VFree
  vg0  1.80t  180.00g 46080

Ce que ça signifie : Vous avez 180G libres dans le volume group. Vous pouvez étendre le thinpool tout de suite.

Décision : Étendez le LV de données du thinpool, et envisagez d’étendre aussi les métadonnées. Faites les deux ; c’est une assurance bon marché.

Tâche 14 : Étendre les données du thinpool (en ligne) puis les métadonnées (en ligne)

cr0x@server:~$ sudo lvextend -L +150G /dev/vg0/data
  Size of logical volume vg0/data changed from 1.60 TiB (419430 extents) to 1.75 TiB (458752 extents).
  Logical volume vg0/data successfully resized.

cr0x@server:~$ sudo lvextend -L +2G /dev/vg0/data_tmeta
  Size of logical volume vg0/data_tmeta changed from 8.00 GiB (2048 extents) to 10.00 GiB (2560 extents).
  Logical volume vg0/data_tmeta successfully resized.

Ce que ça signifie : Les données ont grandi de 150G. Les métadonnées ont grandi de 2G. Les métadonnées thin sont petites mais cruciales ; les agrandir de façon proactive est généralement judicieux.

Décision : Re-vérifiez Data% et Meta% après. Si Meta% reste extrêmement élevé, vous pourriez avoir besoin de plus de métadonnées ou de moins de snapshots/churn.

Tâche 15 : Vérifier que le thinpool est maintenant sain et a de la marge

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vg0/data
  LV   LSize  Data%  Meta%
  data 1.75t  88.12  56.41

Ce que ça signifie : Vous avez acheté de l’air. 88% reste « à surveiller de près » en thin, mais vous n’êtes plus à deux doigts de l’échec.

Décision : Maintenant, empêchez la réapparition : activez discard de bout en bout, réduisez la rétention des snapshots et mettez en place des alertes.

Tâche 16 : S’il n’y a pas d’espace libre dans le VG, ajouter un nouveau disque et étendre le VG

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
NAME         SIZE TYPE FSTYPE      MOUNTPOINT
sda        1.8T  disk
├─sda1       1M  part
├─sda2     1G  part ext4         /boot
└─sda3   1.8T  part LVM2_member
  ├─vg0-root  96G lvm  ext4         /
  ├─vg0-swap   8G lvm  swap         [SWAP]
  └─vg0-data 1.75T lvm
sdb        1.0T  disk

cr0x@server:~$ sudo pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created.

cr0x@server:~$ sudo vgextend vg0 /dev/sdb
  Volume group "vg0" successfully extended

cr0x@server:~$ sudo vgs -o vg_name,vg_size,vg_free
  VG   VSize  VFree
  vg0  2.80t  1.03t

Ce que ça signifie : Vous avez ajouté de la capacité réelle. Vous pouvez maintenant étendre à nouveau le thinpool.

Décision : Étendez vg0/data et (optionnellement) vg0/data_tmeta. Puis configurez du monitoring pour ne pas répéter ce rituel.

Tâche 17 : Activer un TRIM hebdomadaire pour les invités où c’est pertinent (et confirmer)

cr0x@server:~$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled)
     Active: active (waiting)

Ce que ça signifie : Les invités qui utilisent systemd peuvent périodiquement détruire les blocs libérés. C’est l’un des rares gains « configurer et oublier ».

Décision : Assurez-vous que discard est autorisé dans les paramètres disque de la VM et supporté par le système de fichiers/stockage. Sinon, vous ne faites que planifier de l’optimisme.

Tâche 18 : Vérifier si un disque VM est configuré pour passer le discard (Proxmox)

cr0x@server:~$ qm config 102 | grep -E 'scsi|virtio|sata'
scsi0: local-lvm:vm-102-disk-0,discard=on,iothread=1,size=200G

Ce que ça signifie : discard=on est activé pour ce disque. Bien. Sans cela, le TRIM invité n’atteindra pas le thinpool.

Décision : Pour les disques où vous souhaitez de la récupération, activez discard. Pour certains workloads sensibles à la latence, testez d’abord — mais la plupart des gens devraient l’activer.

Options de récupération sans détruire les VM

Quand vous êtes à court de data space, vous avez trois leviers réels : arrêter les écritures, récupérer des blocs, et ajouter de la capacité. La meilleure réparation est généralement une combinaison.
La mauvaise réparation est « supprimer des trucs au hasard jusqu’à ce que l’erreur disparaisse ».

Option A : Supprimer les snapshots inutiles (récupération « réelle » la plus rapide)

Si vous avez des snapshots anciens, c’est le premier endroit que j’inspecte. Les snapshots pinnen des versions anciennes des blocs et maintiennent des données qui seraient autrement réutilisables.
Les supprimer peut libérer beaucoup, mais les merges génèrent de l’I/O — donc faites-le en conscience.

Quand le faire : le pool est plein, des snapshots existent, et vous pouvez tolérer une certaine activité de merge.
Quand l’éviter : le snapshot est utilisé activement pour un rollback dans une fenêtre de changement planifiée (rare).

Option B : Supprimer les volumes orphelins et débris de restaurations échouées (le geste « passer l’aspirateur dans l’entrepôt »)

Proxmox est généralement propre, mais les humains sont créatifs. Les orphelins apparaissent après des sauvegardes ratées, des restaurations interrompues ou des modifications LVM manuelles.
C’est une victoire propre et à faible risque — si vous vérifiez d’abord les références.

Option C : Étendre le thinpool (l’option ennuyeuse, généralement la meilleure)

Si le volume group a des extents libres, étendre le thinpool est rapide et en ligne. S’il n’en a pas, ajoutez un disque et étendez le VG.
En termes d’incident, c’est l’action la plus confiante : elle réduit immédiatement la pression.

Option D : Récupération depuis l’intérieur des invités avec TRIM (bon, mais pas instantané)

La récupération n’est pas magique. L’invité doit émettre des discards, le contrôleur virtuel doit les transmettre, et le thinpool doit les accepter.
Aussi : l’invité peut ne pas émettre des discards de façon agressive sauf si vous lancez fstrim ou montez avec discard continu (pas toujours recommandé).

Option E : Triage temporaire : arrêter l’hémorragie

Si vous êtes à 99–100% et que les VM sont bloquées, l’action immédiate consiste à arrêter les tâches à fort débit d’écriture :
sauvegardes, restaurations, agrégation de logs, vacuum/compaction de bases, indexation, churn d’artefacts CI.
Vous ne « réparez » pas, vous prévenez un effet domino pendant que vous créez de l’espace.

Blague n°2 : La façon la plus rapide de récupérer du stockage est de programmer une fenêtre de maintenance ; soudain tout le monde se souvient de ce qui peut être supprimé.

Trois mini-récits d’entreprise depuis les tranchées thinpool

Mini-récit 1 : L’incident causé par une fausse supposition

Une organisation de taille moyenne exploitait un cluster Proxmox pour des services internes : Git, des runners CI, quelques serveurs d’application, et une base de données que tout le monde prétendait ne pas appeler « production »
parce qu’elle n’était pas exposée aux clients. Elle vivait sur local-lvm, thin provisionnée, avec des disques virtuels généreux. Le monitoring surveillait le système de fichiers de l’hôte,
pas le thinpool. Tout semblait vert — jusqu’à ce que non.

La mauvaise supposition était simple : « Si l’invité supprime des fichiers, l’hôte récupère de l’espace. » Leurs runners CI produisaient des artefacts, les téléversaient, puis nettoyaient
l’espace de travail. À l’intérieur de la VM, l’utilisation du disque semblait correcte. Sur l’hôte, le thinpool grimpait malgré tout. Personne n’a remarqué parce qu’on ne regardait pas le Data%.

Puis une mise à jour OS a créé de nouveaux paquets, les logs ont roulé, CI est devenu occupé, et le thinpool a franchi la ligne. Les écritures se sont mises en file. Les runners CI se sont bloqués. Le service Git est devenu lent. La base de données a commencé à timeouter parce que fsync ne finissait pas. On croyait à un problème réseau jusqu’à ce que quelqu’un vérifie réellement LVM.

La réparation n’a pas été héroïque : activer discard sur les disques VM, activer fstrim hebdomadaire dans les invités, supprimer les snapshots obsolètes, et étendre le pool de quelques centaines de gigas.
Le changement culturel a compté davantage : ils ont ajouté du monitoring thinpool et ont arrêté de traiter local-lvm comme « infini parce que thin ».

Personne n’a été viré. Mais la relation de l’équipe avec les « suppositions » a changé pour de bon. La thin provisioning est un contrat avec la réalité, et la réalité lit toujours les petites lignes.

Mini-récit 2 : L’optimisation qui a mal tourné

Un autre service voulait « des sauvegardes plus rapides ». Ils snapshottaient une VM occupée et exécutaient des jobs de sauvegarde fréquents. Pour réduire le temps de sauvegarde, ils ont augmenté la fréquence des snapshots
et conservé plus de points de restauration. Les graphiques semblaient excellents — jusqu’à ce que le thinpool ne le soit plus.

Les snapshots sont peu coûteux à la création. C’est le piège. La VM était un serveur applicatif très orienté logs avec des écritures constantes. Chaque snapshot pippait d’anciennes zones ; plus ils gardaient de snapshots,
plus de versions de blocs « chauds » vivaient simultanément. Le thinpool s’est rempli plus vite précisément parce que leur « optimisation » conservait le churn.

Quand le thinpool a atteint le plafond, le job de sauvegarde qui « sécurisait les choses » est devenu le déclencheur de l’indisponibilité. Pire : supprimer des snapshots pendant l’incident a provoqué un pic de merges exactement au moment où le système subissait déjà du stress I/O. Ce travail de merge n’était pas le méchant, mais ce n’était certainement pas une berceuse apaisante.

La correction à long terme a été contre-intuitive : moins de snapshots, une planification de sauvegarde plus intelligente, et déplacer les workloads à fort churn sur un stockage dimensionné pour le churn.
Ils ont aussi mis en place l’autoextend du thinpool avec une règle stricte « il faut des extents libres dans le VG » et des alertes quand les extents libres devenaient faibles.

La performance s’est améliorée. La fiabilité s’est améliorée. La plainte « les sauvegardes sont lentes » a été remplacée par « les sauvegardes sont ennuyeuses », ce qui est le plus grand compliment pour les opérations.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une équipe conservatrice exploitait Proxmox pour des plateformes internes. Ils avaient une norme simple, presque terne : chaque backend de stockage avait des alertes à trois niveaux (avertissement, urgent,
stop-the-world), et les thinpools étaient traités comme des bases de données de production — planification de capacité, pas de l’espoir.

Ils avaient aussi une habitude qui ressemble à de la paperasserie : après chaque test de restauration ou de migration, ils exécutaient un « balayage des orphelins » pour vérifier qu’aucun volume errant ne restait.
C’était un petit script et un petit rappel de calendrier. Les gens levaient parfois les yeux au ciel.

Un après-midi, un test de restauration a échoué à mi-chemin à cause d’un hic réseau. Il a laissé plusieurs grands volumes thin. Le lendemain, le balayage d’orphelins les a détectés.
Ils ont retiré les débris et sont passés à autre chose. Aucun incident. Aucune extension d’urgence. Aucun appel nocturne.

Des mois plus tard, une restauration similaire a échoué pendant une période chargée. Mais la même pratique ennuyeuse a joué son rôle. L’hôte n’a jamais atteint la falaise, parce que l’équipe n’a pas laissé
s’accumuler des déchets silencieux.

La leçon n’était pas « être paranoïaque ». C’était « être routinier ». La plupart des pannes ne proviennent pas de bugs exotiques. Elles proviennent de l’accumulation lente d’un état non possédé.

Erreurs courantes : symptôme → cause racine → correction

Ce sont des schémas que je vois régulièrement dans des environnements Proxmox réels. Si l’un d’eux correspond à votre situation, n’en débattez pas — agissez.

1) Symbole : thinpool est plein, mais l’invité a beaucoup d’espace libre

Cause racine : Discard/TRIM n’atteint pas le thinpool, ou n’est jamais émis.
Correction : Activez discard=on pour les disques VM ; activez et exécutez fstrim dans les invités ; confirmez que les discards du thinpool sont passdown.

2) Symbole : « out of data space » survient soudainement après avoir activé des snapshots fréquents

Cause racine : Rétention de snapshots + churn élevé. Le copy-on-write piphone les anciens blocs ; le churn multiplie l’espace consommé.
Correction : Réduisez le nombre/la rétention des snapshots ; planifiez les snapshots pendant les périodes de faible churn ; étendez le pool ; envisagez de déplacer les VM à fort churn sur un stockage dédié.

3) Symbole : data% du pool est modéré, mais les écritures échouent ou le pool semble bloqué

Cause racine : Métadonnées pleines (Meta% proche de 100%) ou risque de corruption des métadonnées.
Correction : Étendez data_tmeta ; réduisez les snapshots ; réduisez la fragmentation/le churn ; vérifiez la santé et envisagez une maintenance si une corruption est suspectée.

4) Symbole : vous supprimez une VM, mais l’utilisation du thinpool change à peine

Cause racine : Les disques VM ne sont pas réellement sur ce thinpool, ou des snapshots/orphelins supplémentaires existent, ou vous avez supprimé la config mais pas les disques.
Correction : Vérifiez qm config et le mapping de stockage ; listez les LVs ; supprimez les orphelins ; confirmez que la suppression Proxmox était configurée pour retirer les disques.

5) Symbole : après avoir libéré de l’espace, le pool indique toujours presque plein

Cause racine : Les blocs libérés n’ont pas été discardés ; la comptabilité thinpool est retardée ; ou vous avez libéré de l’espace sur le mauvais stockage (directory vs lvmthin).
Correction : Re-vérifiez avec pvesm status et lvs ; exécutez des trims ; confirmez les discards ; assurez-vous d’agir sur local-lvm.

6) Symbole : les merges/suppressions de snapshots aggravent la performance pendant l’incident

Cause racine : Supprimer des snapshots déclenche un nettoyage/merge copy-on-write à un moment où l’I/O est déjà critique.
Correction : Mettez en pause les jobs à fort écriture d’abord ; supprimez les snapshots de manière stratégique ; ajoutez de la capacité pour réduire la pression avant les merges si possible.

Listes de contrôle / plan étape par étape

Checklist d’urgence (thinpool à 95–100%)

Arrêter les gros écrivains : mettez en pause sauvegardes/restaurations, arrêtez les tempêtes de logs, retardez les jobs de maintenance de bases.
L’objectif est d’arrêter d’accélérer vers le mur.
Confirmer le problème : exécutez pvesm status et lvs pour Data% et Meta%.
Supprimer les snapshots à faible valeur : commencez par les plus anciens et les moins justifiés. Gardez « celui dont vous pourriez avoir besoin » seulement si vous en avez vraiment besoin.
Supprimer les orphelins prouvés : grep des configs, vérifiez les handles ouverts, puis lvremove.
Étendre le thinpool si possible : vérifiez vgs ; si le VG a des extents libres, étendez maintenant.
Étendre les métadonnées de façon proactive : surtout si Meta% > 70% et que vous utilisez des snapshots.
Re-vérifier la santé : confirmez que Data% redescend à une plage plus sûre et que les VM récupèrent.

Checklist de stabilisation (après avoir arrêté l’hémorragie)

Activer discard de bout en bout : paramètre disque Proxmox discard=on, trims côté invité, thinpool discards passdown.
Définir une politique de snapshots : limiter le nombre, l’âge, et aligner avec les patterns de churn.
Mettre en place des alertes : avertissement à 70–80%, urgent à 85–90%, critique à 95% pour Data% et Meta% du thinpool.
Mesurer le churn : identifiez les VM qui écrivent constamment ; traitez-les comme des multiplicateurs de capacité.
Tester les processus de restauration : les restaurations échouées sont une source majeure d’orphelins.

Checklist de planification capacité (pour que ça ne revienne pas)

Définir un ratio de surprovisionnement : choisissez un chiffre défendable (ex. 2:1) et faites-en une règle culturelle.
Suivre le taux de croissance du thinpool : si Data% augmente de 1–2% par jour, vous êtes sur une horloge compte à rebours.
Garder de l’espace libre dans le VG : si vous comptez sur l’autoextend, gardez des extents libres. Sinon l’autoextend n’est qu’une idée réconfortante.
Séparer les charges : placez les VM à fort churn sur un stockage dimensionné pour le churn, pas sur le même thinpool que l’infrastructure « calme ».

Prévention : rendre ça ennuyeux, le rendre permanent

L’urgence thinpool n’est généralement pas un incident isolé. C’est une facture différée pour une commodité antérieure : surprovisionnement sans monitoring, snapshots sans discipline de rétention,
et invités qui suppriment des données sans les discard.

Monitoring qui fonctionne vraiment

Surveillez le Data% et le Meta% du LV thinpool. Ne vous fiez pas à « espace disque libre » à l’intérieur des invités. Ne vous fiez pas à df -h sur le système de fichiers hôte.
Ce sont des couches différentes avec des vérités différentes.

Une règle pratique : alerter assez tôt pour pouvoir répondre pendant les heures ouvrables. Le but n’est pas d’attraper 99%. Le but est d’empêcher d’y arriver.

Discipline des snapshots

Les snapshots sont une dette opérationnelle avec intérêts composés. Gardez-les quand ils ont un but : un filet de sécurité court pour un changement risqué.
Ne les conservez pas « parce que le stockage est bon marché ». En thin provisioning, le stockage n’est pas bon marché ; il est simplement différé.

Discard : l’activer, puis prouver que ça marche

Activer discard sur un disque Proxmox est nécessaire mais pas suffisant. Les invités doivent émettre des trims. Certains systèmes de fichiers et workloads bénéficient d’un fstrim périodique plutôt que d’un montage avec discard continu.
Testez sur votre workload, mais ne sautez pas cette étape.

Autoextend : un bon serviteur, un mauvais patron

L’autoextend LVM peut vous sauver des surprises de croissance lente, mais il ne peut pas créer de l’espace. Il ne consomme que les extents libres du VG. Si vous utilisez tout l’espace du VG,
l’autoextend devient un faux sentiment de sécurité — comme une roue de secours en carton.

Une citation pour rester honnête

Paraphrase d’une idée de John Allspaw : la fiabilité vient de la façon dont votre système se comporte sous stress, pas du souhait que le stress n’arrivera pas.

FAQ

1) Puis-je corriger « out of data space » sans redémarrer l’hôte Proxmox ?

Généralement oui. Étendre le thinpool et supprimer des snapshots/orphelins sont typiquement des opérations en ligne. Les redémarrages sont réservés aux cas où vous avez creusé un trou plus profond (ou pour des problèmes de noyau/driver),
pas pour des corrections basiques de capacité.

2) Quelle est la différence entre l’espace « data » et « metadata » du thinpool ?

Les données sont les blocs réels stockés pour les disques VM. Les métadonnées sont la base de données de mappage qui suit où chaque bloc virtuel vit dans le pool et comment les snapshots se rapportent.
Vous pouvez être « à court d’espace » dans l’un ou l’autre, et les symptômes peuvent se ressembler.

3) Pourquoi supprimer des fichiers dans la VM ne libère-t-il pas d’espace sur l’hôte ?

Parce que le thinpool ne sait que les blocs sont réutilisables quand il reçoit des discards. Supprimer un fichier marque des blocs libres dans le système de fichiers, mais sans TRIM/discard,
le stockage sous-jacent les considère toujours comme alloués.

4) Activer `discard=on` est-ce sûr pour toutes les VM ?

Pour la plupart des workloads généraux, oui — et c’est généralement le bon choix par défaut en thin provisioning. Pour certains workloads sensibles à la latence, testez d’abord.
Le risque plus grand est d’exécuter du thin sans récupération, puis d’être surpris quand il se remplit.

5) J’ai supprimé des snapshots mais Data% a à peine bougé. Pourquoi ?

Soit les snapshots n’étaient pas le principal consommateur, soit le pool est rempli par des données actives toujours référencées par des disques courants, soit vous êtes en réalité limité par les métadonnées.
Aussi, « à peine bougé » peut encore être significatif si votre pool fait plusieurs téraoctets ; vérifiez avec lvs et corrélez avec les sources de churn.

6) Dois-je ajouter plus d’espace metadata même si Meta% n’est pas élevé ?

Si vous utilisez beaucoup de snapshots ou avez un churn élevé, oui — dans une certaine mesure. Étendre les métadonnées est peu coûteux comparé à un incident où Meta% atteint 100% et le pool se dérègle.

7) Puis-je réduire un disque VM pour récupérer de l’espace dans le thinpool ?

Réduire est possible mais rarement la première option : cela nécessite de réduire le système de fichiers à l’intérieur de l’invité (ce qui n’est pas toujours supporté), et c’est risqué opérationnellement.
Privilégiez la récupération par discard et le nettoyage des snapshots. Étendez la capacité si vous le pouvez.

8) Quelle est la « première action » la plus sûre quand le pool est à 99% et que les VM sont lentes ?

Arrêtez ou mettez en pause les plus gros générateurs d’écritures (sauvegardes/restaurations/tempêtes de logs), puis créez de l’espace en supprimant snapshots/orphelins prouvés ou en étendant le pool.
Ne commencez pas un « nettoyage » à l’intérieur des invités en espérant que ça atteindra l’hôte. L’espoir n’est pas un driver de stockage.

9) Pourquoi ça s’est rempli si vite alors que les disques VM ne sont pas si grands ?

La plénitude du thinpool concerne les blocs physiquement écrits, pas la taille des disques virtuels. Les patterns à fort churn (bases, logs, espaces de travail CI), plus les snapshots, peuvent multiplier rapidement l’utilisation physique.

10) Si j’étends le thinpool, Proxmox le remarquera automatiquement ?

Oui dans la plupart des cas ; Proxmox lit l’état LVM et reflétera la nouvelle capacité dans pvesm status. S’il ne se met pas à jour immédiatement, vérifiez que vous avez étendu le bon LV
et que la définition de stockage pointe vers ce pool.

Conclusion : prochaines étapes à faire aujourd’hui

Si vous lisez ceci en plein incident, faites trois choses dans l’ordre : confirmez si ce sont les données ou les métadonnées qui sont pleines, récupérez de l’espace en supprimant snapshots et orphelins prouvés,
puis étendez le thinpool (et les métadonnées) si vous avez une capacité à ajouter. Cela vous sortira de la zone dangereuse sans détruire les VM.

Ensuite faites la partie qui empêche la suite : activez discard de bout en bout, exécutez des trims, appliquez une rétention de snapshots responsable, et ajoutez du monitoring sur Data% et Meta% du thinpool.
Rendez le stockage ennuyeux à nouveau. Votre futur vous est déjà fatigué.