Proxmox local-lvm à 100 % : trouvez ce qui a mangé votre thin pool et réparez-le

janvier 7, 2026 • février 3, 2026 • Lecture : 30 min • Views: 8

Cet article vous a aidé ?

Local-lvm à 100 % est l’équivalent chez Proxmox d’une panne de direction assistée : tout semble normal jusqu’au moment où ça ne l’est plus. Les VM se bloquent, les sauvegardes échouent, et l’interface web commence à afficher des erreurs comme un pager stressé.

Le plus délicat n’est pas que vous manquez d’espace. C’est pourquoi vous manquez d’espace — provisionnement thin, snapshots, volumes orphelins, amplification d’écriture copy-on-write, un invité qui n’envoie jamais de TRIM, ou des métadonnées qui ont silencieusement atteint la limite avant les données. Voici comment trouver ce qui a mangé votre thin pool, réparer sans aggraver la situation et éviter que cela ne se reproduise.

Ce qu’est réellement « local-lvm » (et pourquoi il se remplit différemment)

Sur la plupart des installations Proxmox, vous vous retrouvez par défaut avec deux stockages locaux :

local : un répertoire (généralement /var/lib/vz) pour les ISO, templates, sauvegardes.
local-lvm : un thin pool LVM utilisé pour les disques des VM.

Le second est celui qui pose problème quand il atteint 100 %. Ce n’est pas parce qu’il est mauvais — LVM-thin est rapide, simple et convenable pour beaucoup de clusters — mais parce que c’est un type de comptabilité d’espace différent d’un système de fichiers classique.

Provisionnement thin : espace promis vs blocs réels

LVM-thin vous permet de créer des volumes virtuels (thin LVs) qui réclament une taille — par exemple 200G — mais ne consomment des blocs physiques dans le pool que lorsque des écritures surviennent. C’est le provisionnement thin. Il facilite le sur-engagement de stockage. Il facilite aussi la surprise quand la réalité rattrape la promesse.

Les snapshots ne sont pas gratuits, ce sont juste des factures différées

Les snapshots LVM-thin sont du copy-on-write. Le snapshot commence petit, mais chaque bloc modifié pendant l’existence du snapshot doit être copié et suivi. Des charges d’écriture importantes et l’attitude « on supprimera les snapshots plus tard » donnent un thin pool qui grossit comme un fichier journal non contrôlé.

Deux limites : données et métadonnées

Les thin pools ont de l’espace données et de l’espace métadonnées. L’une ou l’autre atteignant 100 % peut vous ruiner la journée. Les métadonnées suivent quelles zones sont allouées à quels volumes thin. Si les métadonnées se remplissent, les allocations peuvent échouer même si les données ont de la place. Si les données se remplissent, les écritures échouent même si les métadonnées ont de la place. Elles échouent différemment et nécessitent des interventions différentes.

Idée paraphrasée, attribuée à Werner Vogels (CTO d’Amazon) : Tout finit par tomber en panne ; la résilience vient du fait de concevoir pour cette réalité, pas de l’ignorer.

Plan de diagnostic rapide (à faire en priorité)

Vous voulez un signal rapide, pas un long voyage spirituel dans les entrailles de LVM. Voici le chemin le plus court vers « qu’est-ce qui est plein, pourquoi, et que fait-on maintenant ? »

Premier point : confirmer s’il s’agit de données, métadonnées ou les deux

Exécutez lvs avec les champs du thin pool. Si Data% est proche de 100, vous devez libérer des blocs ou ajouter de l’espace. Si Meta% est proche de 100, vous devez étendre/réparer les métadonnées et arrêter les déclencheurs de croissance (souvent des snapshots).

Deuxième point : identifier les plus gros consommateurs et les volumes « morts »

Listez les thin LVs triés par blocs réellement utilisés. Puis recoupez ce que Proxmox pense exister et ce que LVM a. Les disques orphelins sont fréquents après des restaurations ratées, des migrations interrompues ou du bricolage manuel.

Troisième point : arrêter l’hémorragie

Les sauvegardes, restaurations, migrations et tâches à snapshots intensifs doivent être mises en pause pendant la récupération. Sinon vous écoppez l’eau avec un trou dans la coque.

Quatrième point : choisir l’action de récupération la moins risquée

Supprimer les snapshots inutiles (gain rapide).
Supprimer les volumes véritablement orphelins (gros gain, risque moyen si vous vous trompez).
Activer/décourager TRIM selon la réalité (gain à plus long terme).
Étendre le thin pool (idéal si vous avez de l’espace PV libre).

Faits intéressants et bref historique (parce que ça explique les bizarreries)

LVM existe sous Linux depuis l’ère 2.4, et LVM2 est devenu l’approche standard à mesure que les distributions ont mûri et que les SAN se sont généralisés.
LVM-thin est arrivé au début des années 2010 quand Linux avait besoin de provisionnement thin et de snapshots sans embarquer une couche CoW de système de fichiers complète.
Les métadonnées du thin pool sont stockées sur disque, pas seulement en mémoire ; si elles sont corrompues ou pleines, vous pouvez vous retrouver en lecture seule ou avec des allocations qui échouent.
Le partitionnement par défaut de Proxmox favorisait historiquement « local + local-lvm » car il correspondait aux flux de travail VM courants : stockage d’ISO sur système de fichiers, disques sur stockage bloc.
Le TRIM/Discard pour le thin provisioning a été controversé pendant des années à cause de soucis de performance et de correction ; c’est bien meilleur maintenant, mais il nécessite toujours une activation intentionnelle de bout en bout.
Les snapshots sont coûteux opérationnellement sur presque toutes les technologies de stockage — LVM-thin, qcow2, baies SAN — car ils transforment les réécritures en opérations d’allocation et de copie.
L’épuisement des métadonnées apparaît souvent « soudainement » parce qu’il n’est pas proportionnel aux octets écrits ; il dépend du mapping d’allocation et de l’activité des snapshots.
Le surengagement est autant une fonctionnalité métier qu’une technique : il améliore l’utilisation, mais c’est fondamentalement un pari que tout ne va pas croître en même temps.

Tâches pratiques : commandes, signification et décisions (le cœur)

Ci-dessous des tâches pratiques à exécuter sur un nœud Proxmox. Chaque tâche inclut : une commande, ce que la sortie signifie et quelle décision en tirer. Supposez que votre hôte Proxmox est basé sur Debian et que vous avez root ou sudo.

Task 1: Confirm Proxmox storage view vs reality

cr0x@server:~$ pvesm status
Name        Type     Status           Total            Used       Available        %
local        dir     active        98.00GB         12.40GB         80.60GB   12.65%
local-lvm    lvmthin active       700.00GB        699.20GB          0.80GB   99.89%

Signification : Proxmox pense que local-lvm est essentiellement plein. C’est le symptôme, pas le diagnostic.

Décision : Passez immédiatement à la vue LVM. Proxmox rapporte ce que LVM lui dit ; vous devez voir pourquoi c’est plein (données vs métadonnées, plus gros thin LVs, snapshots).

Task 2: See thin pool health (data and metadata)

cr0x@server:~$ lvs -o+lv_size,segtype,data_percent,metadata_percent,lv_attr,origin,pool_lv --units g
  LV                 VG  Attr       LSize   SegType  Data%  Meta%  Origin  Pool
  data               pve twi-aotz-- 650.00g thin-pool 99.85  12.40         data
  root               pve -wi-ao----  60.00g linear
  swap               pve -wi-ao----   8.00g linear

Signification : data est le thin pool. Data% est presque à 100 %, Meta% est correct. Vous êtes en manque de données, pas de métadonnées.

Décision : Vos premières options de récupération sont de libérer des blocs (supprimer snapshots/volumes) ou d’étendre le pool. La réparation des métadonnées n’est pas le problème principal.

Task 3: If metadata is the problem, detect it explicitly

cr0x@server:~$ lvs -a -o lv_name,vg_name,lv_size,data_percent,metadata_percent,lv_attr --units g
  LV              VG  LSize    Data%  Meta%  Attr
  data            pve 650.00g  78.10  99.60  twi-aotz--
  data_tmeta      pve   4.00g                 ewi-ao----
  data_tdata      pve 650.00g                 ewi-ao----

Signification : L’utilisation des données est correcte, mais les métadonnées sont presque pleines. C’est le type de situation où l’on manque d’espace de mappage, ce qui peut être pire que le manque de données car cela peut survenir alors que beaucoup d’espace libre semble disponible.

Décision : Arrêtez le churn de snapshots, envisagez d’étendre les métadonnées et planifiez une réparation si des erreurs apparaissent. Ne continuez pas à écrire : c’est comme ça que les thin pools se corrompent.

Task 4: Find which thin volumes are actually consuming blocks

cr0x@server:~$ lvs -o lv_name,lv_size,data_percent,metadata_percent,lv_attr --units g --sort -data_percent
  LV                      LSize    Data%  Meta%  Attr
  vm-103-disk-0         200.00g   98.50         Vwi-aotz--
  vm-101-disk-0         150.00g   92.10         Vwi-aotz--
  vm-102-disk-0          80.00g   88.40         Vwi-aotz--
  vm-120-disk-0         500.00g   10.20         Vwi-aotz--

Signification : Data% ici est l’allocation par LV thin par rapport à sa taille virtuelle. Ceux proches de 100 % sont presque entièrement alloués. Ils consomment l’espace réel du pool.

Décision : Identifiez si ce sont de gros disques légitimes effectuant un travail légitime, ou si quelque chose cloche : restaurations anciennes, VM inutilisées, snapshots oubliés.

Task 5: Map a volume back to a VM and config

cr0x@server:~$ qm config 103
boot: order=scsi0;ide2;net0
cores: 4
memory: 8192
name: app-prod-03
scsi0: local-lvm:vm-103-disk-0,size=200G
ide2: local:iso/debian-12.iso,media=cdrom
net0: virtio=DE:AD:BE:EF:10:03,bridge=vmbr0

Signification : vm-103-disk-0 est attaché à la VM 103. Vous pouvez maintenant coordonner le nettoyage avec les propriétaires applicatifs (ou votre futur vous).

Décision : Si la VM est critique, vous ne la supprimez pas. Cherchez des snapshots, nettoyez dans l’invité ou étendez. Si c’est une VM zombie, nettoyez agressivement.

Task 6: List snapshots for a VM (thin snapshots often hide here)

cr0x@server:~$ qm listsnapshot 103
`-> pre-upgrade-2024-11-15
    `-> before-hotfix
`-> backup-temp

Signification : Des snapshots existent. Chaque snapshot peut épingler d’anciens blocs et forcer du CoW sur les écritures, gonflant l’utilisation du pool.

Décision : Si ces snapshots ne sont pas activement nécessaires, supprimez-les. Ne conservez que ce que vous pouvez justifier en une phrase.

Task 7: Delete a snapshot safely

cr0x@server:~$ qm delsnapshot 103 backup-temp
Deleting snapshot 'backup-temp'...
TASK OK

Signification : Proxmox a supprimé le snapshot. La récupération d’espace LVM peut ne pas être immédiate si des blocs sont encore référencés ailleurs, mais souvent vous verrez l’utilisation du pool baisser rapidement.

Décision : Vérifiez lvs. Si l’espace ne bouge pas, le pool est plein pour d’autres raisons (ou TRIM n’est pas actif).

Task 8: Check for orphaned LVs (exist in LVM, not in Proxmox configs)

cr0x@server:~$ pvesm list local-lvm
Volid                         Format  Type         Size VMID
local-lvm:vm-101-disk-0        raw     images 161061273600 101
local-lvm:vm-102-disk-0        raw     images  85899345920 102
local-lvm:vm-103-disk-0        raw     images 214748364800 103

cr0x@server:~$ lvs --noheadings -o lv_name pve | sed 's/^[ \t]*//'
data
root
swap
vm-101-disk-0
vm-102-disk-0
vm-103-disk-0
vm-999-disk-0

Signification : vm-999-disk-0 existe dans LVM mais n’est pas listé par Proxmox storage. C’est suspect.

Décision : Enquêtez avant de supprimer. Cela peut être un résidu d’une restauration ratée, ou référencé dans une ancienne config sur un autre nœud si vous avez fait des manipulations créatives.

Task 9: Verify if a suspicious LV is referenced anywhere

cr0x@server:~$ grep -R "vm-999-disk-0" /etc/pve/qemu-server /etc/pve/lxc 2>/dev/null || echo "no references found"
no references found

Signification : Les configs Proxmox ne le mentionnent pas. C’est un fort signal qu’il est orphelin.

Décision : Si vous confirmez aussi qu’il n’est ni monté ni utilisé par autre chose, vous pouvez le supprimer pour récupérer de l’espace. Si doute, sauvegardez les métadonnées de l’hôte d’abord ou renommez le LV comme suppression douce.

Task 10: Soft-delete by renaming an LV (buy time)

cr0x@server:~$ lvrename pve vm-999-disk-0 vm-999-disk-0.ORPHANED
  Renamed "vm-999-disk-0" to "vm-999-disk-0.ORPHANED" in volume group "pve"

Signification : Vous avez retiré le nom prévisible sans détruire les données. Si quelque chose casse, vous pouvez renommer pour restaurer. Si rien ne crie, vous pourrez supprimer plus tard.

Décision : Si vous êtes sous pression, renommer est plus sûr que supprimer. Ensuite, planifiez la suppression réelle pendant une fenêtre plus calme.

Task 11: Hard-delete an orphaned LV to reclaim space

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

Signification : Le thin LV a été supprimé. Cela libère les blocs référencés dans le thin pool.

Décision : Vérifiez immédiatement l’utilisation du pool. Si le pool descend significativement, vous avez trouvé le coupable. Sinon, continuez la recherche.

Task 12: Confirm pool usage change

cr0x@server:~$ lvs -o lv_name,lv_size,data_percent,metadata_percent,lv_attr --units g
  LV    LSize    Data%  Meta%  Attr
  data  650.00g  92.30  12.45  twi-aotz--

Signification : Vous avez récupéré de l’espace : d’environ ~99.8% à ~92.3%. Ce n’est pas parfait, mais vous êtes sorti de la zone « crash imminent ».

Décision : Ne vous arrêtez pas là. Les thin pools ne pardonnent pas la complaisance. Atteignez une marge stable (au moins 10–20 % libres pour les nœuds chargés).

Task 13: If you have free space in the VG, extend the thin pool (cleanest fix)

cr0x@server:~$ vgs
  VG  #PV #LV #SN Attr   VSize   VFree
  pve   1   5   0 wz--n- 930.00g 280.00g

cr0x@server:~$ lvextend -L +200G /dev/pve/data
  Size of logical volume pve/data changed from 650.00 GiB (166400 extents) to 850.00 GiB (217600 extents).
  Logical volume pve/data successfully resized.

Signification : Vous aviez des extents libres dans le volume group et vous les avez utilisés pour étendre le thin pool.

Décision : L’extension achète du temps et réduit la pression opérationnelle. Corrigez quand même la cause racine ; sinon vous venez d’agrandir un seau qui fuit.

Task 14: Extend thin pool metadata if Meta% is high

cr0x@server:~$ lvextend --poolmetadatasize +2G /dev/pve/data
  Size of logical volume pve/data_tmeta changed from 4.00 GiB (1024 extents) to 6.00 GiB (1536 extents).
  Logical volume pve/data_tmeta successfully resized.

Signification : Plus d’espace métadonnées pour le thin pool. Souvent nécessaire après beaucoup de snapshoting ou de nombreux thin volumes.

Décision : Si vous étiez à Meta% > 90%, faites-le rapidement. Puis réduisez le churn de snapshots pour ne pas remplir aussi vite ces nouvelles métadonnées.

Task 15: Check if discards are enabled at the thin pool level

cr0x@server:~$ lvs -o lv_name,lv_attr,discards,zero
  LV    Attr       Discards  Zero
  data  twi-aotz-- passdown  yes

Signification : passdown signifie que les discards des thin LVs peuvent être transmis au pool. C’est bon pour la récupération, à condition que l’invité émette effectivement des discards.

Décision : Si les discards sont ignorés et que vous attendez du TRIM, ajustez la configuration. Si vous ne voulez pas de discards pour des raisons de charge, acceptez que la récupération nécessite d’autres méthodes et plus de marge.

Task 16: Trigger fstrim inside a Linux guest (where the real reclaim happens)

cr0x@server:~$ qm guest exec 103 -- fstrim -av
/boot: 0 B (0 bytes) trimmed
/: 24.6 GiB (26411479040 bytes) trimmed

Signification : L’invité a informé la pile de stockage des blocs libérés. Si tout est câblé correctement (virtio-scsi + discard activé + thin pool passdown), l’utilisation du thin pool peut baisser.

Décision : Si les trims récupèrent de l’espace significatif, planifiez fstrim régulièrement (ou activez discard continu avec prudence). Si fstrim renvoie 0 octet à vie, il y a un manque de configuration.

Task 17: If you suspect the pool is stuck, check dmesg and thin errors

cr0x@server:~$ dmesg | tail -n 20
[12345.678901] device-mapper: thin: 253:2: reached low water mark of 32768 blocks
[12345.678950] device-mapper: thin: 253:2: no free space for data block

Signification : La cible thin du device-mapper se plaint d’un seuil bas / pas d’espace libre pour les blocs de données. Si elle parle de métadonnées, c’est une urgence différente.

Décision : Arrêtez les écritures (pausez sauvegardes/migrations), libérez de l’espace ou étendez immédiatement. Continuer des IO lourdes ici transforme un incident stockage en projet de récupération de données.

Task 18: Identify the biggest writes from inside Proxmox (rough triage)

cr0x@server:~$ iotop -o -b -n 3 | head -n 20
Total DISK READ: 0.00 B/s | Total DISK WRITE: 48.32 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
 8421 be/4 root        0.00 B/s   22.10 M/s  0.00% 99.00%  vzdump --compress zstd 101
 9102 be/4 root        0.00 B/s   15.40 M/s  0.00% 97.00%  kvm -id 103 -name app-prod-03
 7766 be/4 root        0.00 B/s    9.90 M/s  0.00% 88.00%  kvm -id 102 -name db-prod-02

Signification : Les sauvegardes (vzdump) et certaines VM génèrent des écritures. Sur un thin pool presque plein, des rafales d’écriture peuvent vous faire basculer très vite.

Décision : Mettez en pause les jobs de sauvegarde temporairement. Si une VM génère des écritures incontrôlées (logs, fichiers temporaires, compactage), corrigez dans l’invité ou limitez son débit.

Blague 1/2 : Le provisionnement thin, c’est comme commander un soda light avec un triple burger — techniquement possible, émotionnellement trompeur.

Trouver ce qui a bouffé le pool : les suspects habituels

Suspect A : des snapshots qui ont vécu trop longtemps

Les snapshots sont destinés à être éphémères. « Éphémère » signifie des heures ou des jours, pas des trimestres. Une VM chargée avec un ancien snapshot force chaque bloc modifié à être copié, et ces blocs restent épinglés tant que le snapshot existe.

Indicateur pratique : votre pool grossit régulièrement même si les systèmes de fichiers invités semblent stables. Autre indice : qm listsnapshot renvoie un petit arbre qui cache un coût CoW important.

Suspect B : sauvegardes/restaurations/migrations qui ont laissé des déchets

Proxmox nettoie généralement bien. Mais si un nœud plante en cours de restauration, une anomalie de stockage interrompt une migration, ou un humain tue une tâche en vol, vous pouvez obtenir des thin volumes orphelins. Ce sont de vrais consommateurs invisibles dans l’UI quotidienne à moins de comparer pvesm list et lvs.

Réalité opérationnelle : les volumes orphelins sont assez courants pour que la « réconciliation LVM vs configs Proxmox » devienne une étape standard d’incident.

Suspect C : invités qui n’envoient jamais de discard (TRIM n’est pas automatique)

Un thin pool n’apprend que les blocs « libérés » si des discards sont émis et propagés. Supprimer 100 Go de fichiers dans une VM ne libère pas nécessairement 100 Go dans le thin pool. Sans discard/TRIM, le pool ne voit que des écritures, n’oublie jamais les allocations, et approche lentement 100 %.

Les invités Windows ont besoin d’une « Optimize Drives » planifiée (TRIM). Les invités Linux ont besoin de fstrim périodique ou d’options de montage qui supportent discard. Et le contrôleur virtuel doit le supporter, plus Proxmox ne doit pas le bloquer.

Suspect D : qcow2 au mauvais endroit (ou raw avec snapshots ailleurs)

Sur local-lvm (LVM-thin), Proxmox utilise typiquement des volumes raw, ce qui est bien. Mais si vous stockez du qcow2 sur un stockage de type répertoire (comme local) puis que vous faites des snapshots au niveau qcow2, vous obtenez une mécanique de croissance différente. Parfois les admins migrent des disques entre stockages et se retrouvent avec des formats et couches de snapshot inattendus.

Règle : ne pas empiler CoW sur CoW sauf si vous testez volontairement la souffrance.

Suspect E : une seule VM qui effectue des écritures « légitimes » mais explosives

Exemples courants : bases de données qui font du compactage, tempêtes de logs, rétention runaway des métriques, ou une VM qui écrit une image complète de sauvegarde sur son propre disque. Le provisionnement thin amplifie le problème car on ne ressent pas la pression avant qu’il ne soit trop tard.

Suspect F : pression sur les métadonnées due à de nombreux snapshots ou petites allocations

Même si vous n’écrivez pas beaucoup d’octets, vous pouvez brûler des métadonnées avec du churn de snapshots et des patterns d’allocation. La croissance des métadonnées peut sembler déconnectée des « Go utilisés », ce qui explique pourquoi on se fait surprendre.

Réparer maintenant : actions de récupération sûres

1) Mettre en pause le churn

Arrêtez les sauvegardes programmées, la réplication et toute tâche automatisée de snapshots. Ne faites pas de gymnastique de stockage tant que quelque chose écrit intensément.

cr0x@server:~$ systemctl stop pve-ha-lrm pve-ha-crm 2>/dev/null || true
cr0x@server:~$ systemctl stop cron 2>/dev/null || true

Signification : C’est un instrument brutal ; faites preuve de discernement. Dans un cluster, coordonnez l’impact. L’objectif est de réduire les tâches de fond qui créent des écritures et des snapshots.

Décision : Si vous ne pouvez pas arrêter l’automatisation globalement, au moins stoppez les tâches de sauvegarde/restauration actives et évitez d’en lancer de nouvelles tant que l’espace n’est pas stabilisé.

2) Supprimer les snapshots inutiles

C’est le correctif avec le meilleur ROI quand les snapshots sont la cause. Supprimez depuis Proxmox pour qu’il nettoie correctement toute la chaîne.

cr0x@server:~$ qm listsnapshot 101
`-> pre-upgrade
`-> weekly-safety

cr0x@server:~$ qm delsnapshot 101 weekly-safety
Deleting snapshot 'weekly-safety'...
TASK OK

Signification : La suppression peut prendre du temps si la VM est active et que des opérations de fusion sont nécessaires. Sur LVM-thin c’est généralement plus rapide que des merges qcow2, mais pas instantané si les IO sont lourds.

Décision : Vérifiez l’utilisation du thin pool après chaque suppression importante. Ne supprimez pas tout aveuglément si vous avez besoin d’un rollback pour un changement en cours.

3) Supprimer les orphelins (avec précaution)

Si vous avez des volumes qui ne sont référencés par aucune config VM, récupérez-les. Préférez renommer d’abord si vous avez un doute.

4) Étendre le pool (si possible)

Si votre VG dispose d’extents libres, étendre /dev/pve/data est propre et sans drama. Sinon, vous pouvez ajouter un nouveau disque comme PV et étendre le VG — pensez performances et domaines de défaillance.

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

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

cr0x@server:~$ lvextend -L +500G /dev/pve/data
  Size of logical volume pve/data changed from 850.00 GiB (217600 extents) to 1350.00 GiB (345600 extents).
  Logical volume pve/data successfully resized.

Signification : Vous avez augmenté la capacité du thin pool. Les données respirent immédiatement.

Décision : L’extension n’est pas un substitut au ménage. Si vous ne colmatez pas la fuite, vous atteindrez de nouveau 100 % — probablement à 2 h du matin un week-end, parce que le stockage a de l’humour.

5) Traiter correctement les urgences métadonnées

Si les métadonnées sont pleines, la priorité est d’empêcher une consommation supplémentaire et de regagner de l’air. Étendre les métadonnées est souvent possible en ligne, mais si le pool est déjà en erreur vous pourriez avoir besoin d’outils de réparation et d’une fenêtre de maintenance.

Vérifiez d’abord les erreurs :

cr0x@server:~$ lvs -o lv_name,lv_attr,seg_monitor,devices pve
  LV    Attr       Cpy%Sync  Monitor  Devices
  data  twi-aotz--           monitored /dev/sda3(0)

Signification : La surveillance peut aider à l’auto-extension dans certaines configurations, mais ne comptez pas dessus à moins de l’avoir configurée volontairement.

Décision : Si Meta% est élevé, étendez les métadonnées puis réduisez l’activité de snapshots. Si vous voyez des erreurs I/O, arrêtez et planifiez une réparation.

6) Rendre le TRIM réel (bout en bout)

Le TRIM n’est utile que s’il traverse la pile : système de fichiers invité → couche bloc invité → disque virtuel → couche bloc hôte → thin pool.

Sur Proxmox, assurez-vous que le disque utilise un contrôleur qui gère bien le discard (virtio-scsi est couramment utilisé). Dans la config VM, activez le discard si approprié. Puis planifiez fstrim dans les invités.

Prévenir la répétition : contrôles ennuyeux mais efficaces

La marge libre est une politique, pas un vœu

Le provisionnement thin est acceptable. Gérer un thin pool à 90–95 % sur un nœud chargé ne l’est pas. Votre enveloppe d’exploitation sûre dépend du débit d’écriture et de la vitesse de récupération. Dans la plupart des environnements de production, je veux au moins 15–20 % de données libres sur les thin pools qui hébergent des VM générant beaucoup d’écritures.

Hygiène des snapshots : limites temporelles, pas des sentiments

Imposez une TTL sur les snapshots. Si un snapshot existe plus longtemps que la raison pour laquelle il a été créé, ce n’est pas de la « sécurité », c’est une dette technique silencieuse.

Réconciliation régulière : LVM vs Proxmox

Une fois par mois (ou après tout incident impliquant des restaurations/migrations), comparez les volumes thin et les configs VM. Repérez les orphelins tant qu’ils sont petits et que vous n’êtes pas sous pression.

Plan de trim dans les invités

Pour les invités Linux, un fstrim.timer hebdomadaire suffit généralement. Pour Windows, planifiez une optimisation (TRIM). Pour les bases de données, coordonnez avec les fenêtres de maintenance si vous craignez des pics I/O.

Alertez séparément sur Data% et Meta%

La plupart des stacks d’alerte surveillent seulement « l’utilisation stockage ». Cela manque les métadonnées. Si vous alertez à 80/90% pour les données mais jamais pour les métadonnées, vous regardez le mauvais précipice.

Blague 2/2 : Un thin pool à 100 % est la façon dont la nature vous rappelle que « illimité » a toujours été du marketing.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: local-lvm shows 100%, but “df -h” looks fine

Cause racine : local-lvm est du stockage bloc ; df rapporte l’utilisation des systèmes de fichiers montés, pas la consommation du thin pool LVM.

Correction : Utilisez lvs et pvesm status. Traitez Data% et Meta% comme des métriques de première classe.

2) Symptom: VM writes fail or filesystem goes read-only during backup

Cause racine : thin pool data plein ; les pics de sauvegarde provoquent des écritures (snapshots, volumes temporaires, overhead CoW).

Correction : Arrêtez les sauvegardes, libérez de l’espace (snapshots/orphelins), ou étendez le pool. Relancez ensuite les sauvegardes avec de la marge.

3) Symptom: thin pool has space, but new allocations fail

Cause racine : métadonnées pleines (Meta% élevé) ou erreurs métadonnées.

Correction : Étendez les métadonnées (lvextend --poolmetadatasize) et réduisez le churn de snapshots. Cherchez des erreurs thin dans dmesg.

4) Symptom: you deleted lots of files inside a VM, but pool usage didn’t drop

Cause racine : pas de propagation TRIM/discard ; les blocs restent alloués dans le thin pool.

Correction : Activez discard bout en bout et exécutez fstrim dans l’invité. Validez avec des octets récupérés et le changement d’utilisation du pool.

5) Symptom: pool usage keeps growing even when VMs are “idle”

Cause racine : snapshots épinglent des blocs ; tâches de fond (rotation de logs, antivirus, indexation) réécrivent les données ; l’outil de sauvegarde crée du churn de snapshots.

Correction : Supprimez les vieux snapshots, réduisez les tâches créant du churn, et arrêtez de stocker des « snapshots pour toujours » sur des thin pools de production.

6) Symptom: pool filled “overnight” after you resized a VM disk

Cause racine : provisionnement thin surengagé plus expansion/remplissage du système de fichiers invité, ou une restauration a écrit une image complète dans le volume thin.

Correction : Auditez le surengagement. Imposer des plafonds de croissance, augmentez la marge et alertez plus tôt.

Listes de contrôle / plan pas à pas

Step-by-step: recover from local-lvm at 100% (minimal risk)

Confirmez si ce sont les données ou les métadonnées qui sont pleines (lvs -o data_percent,metadata_percent).
Pausez les tâches backup/restore/migration générant du churn.
Listez l’utilisation par disque VM (LVM thin LVs) et identifiez les gros consommateurs.
Vérifiez les snapshots sur les gros consommateurs ; supprimez les snapshots non essentiels en priorité.
Revérifiez l’utilisation du pool après chaque suppression.
Recherchez les volumes orphelins en comparant pvesm list et lvs.
Renommez les orphelins comme mesure de sécurité ; supprimez-les après confirmation.
Si le VG a de l’espace libre, étendez le thin pool et/ou les métadonnées.
Activez et validez le TRIM bout en bout ; lancez fstrim dans les invités.
Redémarrez les jobs mis en pause seulement après avoir restauré une marge de sécurité.

Operational checklist: prevent recurrence

Alertez séparément sur Data% et Meta% du thin pool.
Imposez et appliquez une politique TTL pour les snapshots (l’automatisation aide).
Scan mensuel des orphelins : réconciliez les volumes LVM avec les configs Proxmox.
Revue trimestrielle de capacité : ratio d’overcommit thin, tendances de croissance et scénario « pire cas croissance simultanée ».
Plan de trim pour les invités : vérifiez avec des octets réellement récupérés, pas des intentions.

Trois mini-récits d’entreprise issus des tranchées du thin pool

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

Ils avaient un petit cluster Proxmox exécutant des services internes : agents de build, stockage d’artefacts, quelques VM bases de données et des environnements de test « temporaires » devenus très permanents. L’équipe surveillait l’utilisation disque via une métrique hôte standard : pourcentage d’utilisation du système de fichiers /. Tout restait vert.

Puis un lundi matin, plusieurs VM sont passées en lecture seule. Le job de sauvegarde a échoué. L’UI web a affiché des erreurs ressemblant à des problèmes de permissions. L’astreignant a fait ce que font les astreints : redémarrer la VM la plus bruyante en premier. Elle est revenue en pire état.

L’hypothèse erronée était simple : « Si le système de fichiers hôte a de la place, le stockage VM a de la place. » Mais local-lvm était son propre thin pool, séparé de /. Le thin pool avait atteint 100 % tard dimanche durant une fenêtre de sauvegarde calme — calme pour les humains, pas pour le stockage.

La récupération a été simple une fois qu’ils ont regardé au bon endroit : lvs montrait les données à 99.9 %. Un snapshot de longue durée sur une VM base de données très écrasée épinglait des blocs. La suppression du snapshot a libéré assez d’espace pour stabiliser, puis ils ont étendu le pool et ajouté des alertes pour Data% et Meta%.

Le changement culturel a été meilleur : ils ont cessé de traiter le thin provisioning comme un « stockage magique » et ont commencé à l’utiliser comme un outil de capacity planning avec risques explicites. L’incident n’était pas causé par LVM-thin. Il était causé par une hypothèse que personne n’avait écrite, donc personne ne l’avait remise en question.

Mini-story 2: The optimization that backfired

Une autre équipe voulait des sauvegardes plus rapides. Quelqu’un a remarqué que les backups basés sur snapshots étaient « instantanés » à l’étape snapshot, et a raisonné qu’on pouvait prendre des snapshots plus fréquemment pour réduire les RPO. Ils ont automatisé un snapshot toutes les heures pour des VM clés et les ont conservés pendant deux semaines. Sur papier, ça avait l’air responsable.

La première semaine s’est bien passée. La deuxième semaine, la performance est devenue étrange : pics de latence, blocages IO occasionnels et une utilisation de stockage qui croissait sans correspondre à la croissance applicative. Le thin pool ne se contentait pas de se remplir ; il se remplissait selon un schéma corrélé à des jobs batch lourds en écriture.

Des snapshots horaires signifiaient un CoW constant. L’« optimisation » a augmenté l’amplification d’écriture, brûlé les métadonnées plus rapidement et épinglé d’anciens blocs pendant deux semaines — juste assez longtemps pour transformer un churn normal en allocation persistante. Ils n’avaient pas réduit les backups ; ils avaient ajouté un second mécanisme de rétention à l’intérieur de la couche de stockage.

Ils sont revenus à une approche plus saine : un snapshot court avant une opération maintenance, plus de vraies sauvegardes avec des restaurations testées. La fréquence des snapshots a chuté, la performance s’est stabilisée et le thin pool a cessé de se comporter comme un ballon qui se gonfle lentement.

Conclusion : les snapshots ne sont pas un système de sauvegarde gratuit. C’est un outil tranchant pour les rollbacks à court terme. Utilisez-le comme un scalpel, pas comme une armoire de stockage.

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

Une équipe liée aux finances (celle qui rend les auditeurs heureux et les ingénieurs légèrement agacés) gérait Proxmox pour quelques dizaines de VM. Leur approche était pas sexy : seuils de capacité, règles de marge libre et housekeeping programmé. Chaque VM avait un propriétaire documenté. Chaque snapshot avait une date d’expiration.

Un après-midi, un test de restauration a mal tourné. Une grosse restauration de VM a été interrompue en cours à cause d’un hic réseau. L’opérateur a relancé, et la seconde tentative a réussi. Personne n’a remarqué que la première tentative avait laissé un thin LV orphelin.

Deux semaines plus tard, le job mensuel de « réconciliation stockage » a signalé un LV présent dans LVM mais non référencé par une config Proxmox. Le rapport n’a rien supprimé automatiquement ; il a juste créé un ticket avec le nom du LV, sa taille et son heure de création. Quelqu’un a vérifié qu’il n’était pas référencé et l’a supprimé. L’espace est revenu.

Rien n’a cassé. Pas d’incident. Pas de nettoyage d’urgence. Aucun week-end ruiné.

La pratique n’était pas brillante. C’était l’opposé : des audits routiniers avec une préférence pour des actions sécurisées (renommer d’abord, puis supprimer). Cet ennui a empêché un futur incident de thin pool à 100 % le jour où l’équipe aurait été déjà occupée par d’autres urgences.

FAQ

Pourquoi local-lvm atteint-il 100 % alors que mes VM affichent encore de l’espace libre à l’intérieur ?

Parce que l’utilisation du thin pool suit les blocs alloués, pas « l’espace libre » dans l’invité. Supprimer des fichiers dans la VM ne rend pas forcément les blocs sans TRIM/discard. Les snapshots peuvent aussi épingler d’anciens blocs.

Est-ce que local-lvm est la même chose que LVM sur le disque racine de l’hôte ?

Non. C’est typiquement un thin pool LV à l’intérieur d’un VG (souvent pve), séparé du LV du système racine. Comptabilité différente, modes de défaillance différents.

Qu’est-ce qui est le plus dangereux : Data% à 99 % ou Meta% à 99 % ?

Les deux sont mauvais. Les métadonnées à 99 % peuvent être plus sournoises car les allocations peuvent échouer de façon imprévisible et la récupération peut être plus délicate. Traitez l’un ou l’autre comme un incident.

Puis-je simplement supprimer des « disques inutilisés » depuis l’interface graphique ?

Vous pouvez supprimer les disques inutilisés que Proxmox connaît. Le danger réside dans les volumes que Proxmox ne liste pas (orphelins). Pour ceux-là, réconciliez les configs d’abord ; renommer avant suppression est une bonne pratique.

Pourquoi la suppression d’un snapshot n’a-t-elle pas libéré d’espace immédiatement ?

Si d’autres snapshots référencent encore des blocs, ou si la charge de travail a réécrit fortement des blocs, l’espace peut peu baisser. Aussi, il se peut que la saturation soit due à d’autres volumes, pas aux snapshots.

L’activation du discard nuit-elle aux performances ?

Ça peut dépendre de la charge et du stockage sous-jacent. Beaucoup d’environnements s’en sortent mieux avec fstrim périodique plutôt qu’avec un discard continu. Mesurez sur votre matériel.

Comment savoir quelle VM consomme le plus d’espace ?

Utilisez lvs trié par Data% par LV et taille, puis mappez les volumes aux VM avec qm config <vmid>. Vérifiez aussi les snapshots et sauvegardes pour les pics d’écriture.

Puis-je réduire un thin LV pour récupérer de l’espace ?

Pas en sécurité comme correctif de premier niveau. Réduire un disque virtuel nécessite de réduire le système de fichiers dans l’invité et des opérations au niveau bloc risquées. Préférez supprimer snapshots/orphelins, faire du trim ou étendre le pool.

Dois-je déplacer des disques VM hors de local-lvm vers autre chose ?

Si vous avez besoin d’une réclamation prévisible, de réplication et de visibilité, envisagez un stockage avec des primitives de gestion plus fortes (ou un stockage dédié par tier). Mais local-lvm convient si vous imposez marge libre, TTL snapshots et trims.

Quel est le mouvement le plus rapide « il me faut de l’espace maintenant » ?

Supprimez les snapshots inutiles et retirez les volumes orphelins confirmés. Si vous avez de l’espace libre dans le VG, étendre le thin pool est aussi rapide et peu risqué.

Conclusion : prochaines étapes à mettre en œuvre

Quand local-lvm de Proxmox atteint 100 %, la solution n’est que rarement mystique. C’est généralement l’une des quatre choses : snapshots qui ont dépassé leur durée, volumes orphelins, absence de TRIM, ou simple manque de capacité. Le gain vient de diagnostiquer lequel avant de commencer à supprimer des éléments que vous regretterez.

Faites ceci ensuite :

Exécutez lvs et notez Data% et Meta%. C’est votre vérité terrain.
Supprimez les snapshots dont vous n’avez pas besoin, en commençant par les VM les plus actives.
Réconciliez pvesm list vs lvs et retirez les orphelins confirmés (renommez d’abord si vous êtes prudent).
Étendez le thin pool si vous avez de l’espace VG ; étendez les métadonnées si Meta% est élevé.
Rendez le TRIM réel : activez-le bout en bout et vérifiez les octets récupérés avec fstrim.
Mettez en place des alertes et une politique TTL pour les snapshots afin de ne pas reproduire cela sous pression.