Proxmox snapshot bloqué : nettoyer en toute sécurité les résidus LVM-thin

décembre 17, 2025 • février 3, 2026 • Lecture : 29 min • Views: 5

Cet article vous a aidé ?

Vous cliquez sur « Delete snapshot » dans Proxmox. La tâche tourne. Puis elle échoue. Ou pire : elle indique qu’elle a réussi, mais le stockage affiche toujours des volumes fantômes, votre thin pool reste gonflé et les sauvegardes continuent de tomber sur la même mine.

C’est la réalité rugueuse de LVM-thin dans un cluster de virtualisation occupé : les snapshots sont bon marché jusqu’à ce qu’ils ne le soient plus, et le nettoyage est sûr uniquement si vous comprenez réellement ce qui est alloué, ce qui est simplement référencé et ce qui est purement orphelin.

Le modèle mental : comment fonctionnent réellement Proxmox + LVM-thin snapshots

Si vous traitez le « snapshot » comme une machine à remonter le temps magique, vous finirez par supprimer la mauvaise chose. Traitez-le comme de la plomberie de stockage avec des compteurs de références et un comportement copy-on-write et vous dormirez mieux.

Ce que Proxmox fait quand vous cliquez sur « Snapshot »

Pour un stockage LVM-thin (lvmthin dans Proxmox), un disque VM est typiquement un volume thin à l’intérieur d’un thin pool. Un snapshot est un autre volume thin qui partage des blocs avec le volume d’origine. Les écritures vont ailleurs ; les lectures peuvent provenir des blocs partagés ou des blocs delta. Ce « ailleurs » reste votre thin pool. Le thin provisioning n’est pas de l’espace gratuit ; c’est une facturation différée.

Proxmox suit les snapshots dans la config VM (/etc/pve/qemu-server/<vmid>.conf) et utilise les outils LVM en dessous. Quand la suppression d’un snapshot échoue, vous vous retrouvez souvent avec un désaccord entre :

l’inventaire de Proxmox (ce qu’il pense exister)
la réalité de LVM (les volumes thin existants et leurs références)
l’état de device-mapper (ce qui est actif, ouvert ou suspendu)

À quoi ressemblent les « résidus » dans LVM-thin

Les résidus apparaissent comme des volumes thin qui n’ont plus de référence correspondante dans la config VM, ou comme des volumes snapshot dont l’origine a été supprimée, ou comme des volumes que Proxmox voudrait supprimer mais que LVM refuse parce que quelque chose les a encore ouverts.

Schémas de résidus courants :

Snapshot thin LV orphelin : l’enregistrement du snapshot VM a disparu, mais le thin LV reste.
Disque de base orphelin : le disque VM a été déplacé ou supprimé au niveau Proxmox, mais le thin LV est toujours là.
Périphériques « occupés » : qemu, qemu-nbd, les outils de sauvegarde, ou même des mappings device-mapper obsolètes maintiennent l’LV ouvert.
Pression sur les métadonnées du thin pool : les suppressions et fusions deviennent lentes ou échouent quand les métadonnées sont presque pleines ou que le pool est instable.

Une citation, parce que c’est toujours vrai

Idée paraphrasée (Werner Vogels) : vous devez préparer les pannes comme condition normale d’exploitation, pas comme une exception rare.

Playbook de diagnostic rapide (vérifiez 1/2/3)

Ne zappez pas. Ne « reboottez le nœud » à la va-vite sauf si vous pouvez tolérer une interruption et que vous savez quels périphériques sont ouverts. Faites plutôt ceci.

1) Vérifier si Proxmox est bloqué par ses propres verrous ou une tâche en cours

Y a-t-il une tâche en cours pour la suppression/rollback du snapshot ?
Y a-t-il un verrou obsolète dans la config VM ?
Êtes-vous en compétition avec une sauvegarde (vzdump) ou un job de réplication ?

2) Vérifier la santé du thin pool LVM et l’utilisation des métadonnées

Les données ou métadonnées du thin pool sont-elles proches de 100% ?
Y a-t-il des avertissements sur les IDs de transaction, needs-check, ou un comportement en lecture seule ?
Le dmeventd/lvmmonitor réagit-il, ou a-t-il été désactivé ?

3) Identifier qui garde l’LV ouvert

qemu est-il toujours en cours d’exécution ?
Un périphérique mapper est-il toujours actif ?
Quelque chose comme qemu-nbd ou un montage obsolète le retient-il ?

Une fois que vous savez quel de ces trois est le goulot d’étranglement, le nettoyage devient surtout mécanique. Si vous ne savez pas, chaque commande est un tirage au sort.

Faits et contexte intéressants (parce que l’histoire se répète)

Les snapshots LVM précèdent le thin provisioning. Les snapshots LVM classiques étaient notoirement gourmands en espace et lents sous charges d’écriture lourdes ; les snapshots thin ont changé le profil de performance mais pas les angles opérationnels tranchants.
Device-mapper est le vrai moteur. LVM est l’orchestration en espace utilisateur ; le device-mapper du noyau Linux réalise le mapping réel, le suivi des références et le thin provisioning.
Les métadonnées du thin pool sont leur propre « disque ». Quand les métadonnées se remplissent, le pool peut basculer en lecture seule pour éviter la corruption. Les suppressions peuvent devenir impossibles au pire moment—juste quand vous avez besoin d’espace.
Supprimer des snapshots peut coûter cher. La suppression d’un snapshot thin peut déclencher des discard de blocs et des mises à jour de métadonnées, qui ne sont pas « gratuits », surtout sur des pools occupés.
Proxmox utilise l’état de config comme vérité. Si la config et le stockage dérivent, l’UI peut mentir sans état d’âme. Le système n’est pas malveillant ; il lit simplement un livre différent de LVM.
Le thin provisioning peut cacher des risques. L’overcommit fonctionne jusqu’à ce qu’il ne fonctionne plus ; le mode de défaillance est brutal et moche, et il a tendance à survenir pendant des opérations intensives en snapshots.
Les noyaux plus anciens avaient des histoires de réparation thin plus rugueuses. Les outils de métadonnées thin se sont améliorés, mais la réparation reste le genre de « succès » accompagné d’un mal de tête et d’un postmortem.
Les tempêtes de snapshots existent. Les cycles répétés de création/suppression de snapshots peuvent fragmenter les métadonnées et amplifier la latence d’une manière qui surprend ceux qui ne regardent que les graphiques IOPS bruts.

Blague #1 : Un snapshot, c’est comme un abonnement à la salle de sport—bon marché à créer, mystérieusement cher à se débarrasser.

Tâches pratiques avec commandes : diagnostiquer, décider, agir

Ces tâches sont ordonnées comme je les exécute réellement en production : prouver ce qui se passe, réduire la zone d’impact, puis supprimer les éléments en toute confiance.

Tâche 1 : Confirmer le type de stockage et le nom utilisé par Proxmox

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        197919072        45121480       142663256   22.80%
local-lvm      lvmthin    active        9996536384      7125647360      2870889024   71.28%

Ce que ça signifie : Vous avez un stockage lvmthin appelé local-lvm. Les résidus de snapshot seront des thin LVs à l’intérieur du VG qui soutient ce stockage (souvent pve).

Décision : Utilisez les outils LVM-thin, pas les outils ZFS, et ne « supprimez pas des fichiers au hasard ». Votre chemin de nettoyage est lvs/lvremove/dmsetup, plus l’hygiène de config Proxmox.

Tâche 2 : Identifier la VM et voir si Proxmox pense qu’un snapshot existe

cr0x@server:~$ qm listsnapshot 104
`-> current
   `-> pre-upgrade-2025w51  2025-12-18 02:14:09  VM snapshot
   `-> before-agent-change  2025-12-20 11:07:55  VM snapshot

Ce que ça signifie : Proxmox croit que des snapshots existent. Si la suppression échoue, soit LVM a refusé, soit l’état Proxmox a dérivé en cours d’opération.

Décision : Si Proxmox liste des snapshots, privilégiez la suppression via qm delsnapshot d’abord. Les suppressions LVM manuelles sont pour les cas où l’état est déjà incohérent ou Proxmox est bloqué.

Tâche 3 : Chercher les verrous de config VM qui bloquent les opérations de snapshot

cr0x@server:~$ grep -E '^(lock:|snapshots:)' /etc/pve/qemu-server/104.conf
lock: snapshot

Ce que ça signifie : La VM est verrouillée pour une opération de snapshot. Cela peut être légitime (encore en cours) ou obsolète (tâche morte).

Décision : S’il n’y a pas de tâche en cours et que le verrou est obsolète, déverrouillez la VM avant de retenter les suppressions. S’il y a une tâche en cours, arrêtez-vous et investiguez d’abord.

Tâche 4 : Vérifier l’historique des tâches Proxmox pour l’opération échouée

cr0x@server:~$ journalctl -u pvedaemon -u pveproxy --since "2 hours ago" | tail -n 30
Dec 26 09:10:14 server pvedaemon[2214]: starting task UPID:server:0000B5AA:0001B2C1:676D6E46:qmddelsnapshot:104:root@pam:
Dec 26 09:10:16 server pvedaemon[2214]: command 'lvremove -f pve/vm-104-disk-0-pre--upgrade--2025w51' failed: exit code 5
Dec 26 09:10:16 server pvedaemon[2214]: error: Logical volume pve/vm-104-disk-0-pre--upgrade--2025w51 contains a filesystem in use.
Dec 26 09:10:16 server pvedaemon[2214]: TASK ERROR: command 'lvremove -f pve/vm-104-disk-0-pre--upgrade--2025w51' failed: exit code 5

Ce que ça signifie : Ce n’est pas une « bizarrerie de l’UI Proxmox ». LVM a refusé parce que le périphérique est « en cours d’utilisation ». C’est généralement un descripteur de fichier ouvert, un périphérique mapper obsolète, ou qemu qui le référence.

Décision : Identifiez le processus qui le retient. Ne forcez pas la suppression avant de savoir ce que « en cours d’utilisation » signifie réellement.

Tâche 5 : Trouver les volumes thin LVM pour la VM et mapper les noms de snapshot aux LVs

cr0x@server:~$ lvs -a -o vg_name,lv_name,lv_attr,origin,devices,lv_size,data_percent,metadata_percent pve | grep -E 'vm-104'
pve  vm-104-disk-0                             Vwi-aotz--                                    thinpool           200.00g  78.12
pve  vm-104-disk-0-pre--upgrade--2025w51       Vwi---tz-k  vm-104-disk-0                     thinpool           200.00g  12.44
pve  vm-104-disk-0-before--agent--change       Vwi---tz-k  vm-104-disk-0                     thinpool           200.00g   3.02

Ce que ça signifie : Vous avez le disque de base et deux snapshots thin. origin pointe vers le disque de base. Les attributs (Vwi---) indiquent qu’il s’agit de volumes thin et actifs.

Décision : Si des LVs existent, Proxmox ne hallucine pas. Si Proxmox pense qu’un snapshot existe mais qu’il manque ici, vous êtes face à une dérive d’état et devrez corriger la config.

Tâche 6 : Inspecter la santé du thin pool (usage données + métadonnées)

cr0x@server:~$ lvs -o vg_name,lv_name,lv_attr,lv_size,data_percent,metadata_percent pve
VG   LV        Attr       LSize   Data%  Meta%
pve  root      -wi-ao----  96.00g
pve  swap      -wi-ao----   8.00g
pve  thinpool  twi-aotz--   7.30t  71.28  92.10

Ce que ça signifie : Des métadonnées à 92% sont un feu orange clignotant. L’épuisement des métadonnées du thin pool provoque des échecs étranges : suppressions bloquées, basculement en lecture seule, allocations qui échouent, et vous apprenez de nouveaux jurons.

Décision : Si les métadonnées sont >80%, priorisez le nettoyage et/ou l’extension des métadonnées avant de lancer une forte activité de snapshots. Si elles sont >95%, traitez cela comme un incident.

Tâche 7 : Vérifier si la VM est en marche et pourrait encore référencer des périphériques snapshot

cr0x@server:~$ qm status 104
status: running

Ce que ça signifie : Une VM en fonctionnement peut garder des périphériques ouverts. La suppression de snapshot cible généralement les volumes snapshot, mais selon les opérations (rollback, backup, clone), des mappings supplémentaires peuvent exister.

Décision : Pour un nettoyage sûr, planifiez une fenêtre de maintenance pour arrêter la VM si vous devez retirer des LVs qui déclarent « en cours d’utilisation ». Si vous ne pouvez pas l’arrêter, vous devez prouver qu’aucun chemin critique ne référence encore l’LV.

Tâche 8 : Trouver qui a l’LV ouvert (lsof/fuser sur le chemin du périphérique)

cr0x@server:~$ lsof /dev/pve/vm-104-disk-0-pre--upgrade--2025w51 | head
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
qemu-syst 915 root   49u  BLK  253,7      0t0  891 /dev/dm-7

Ce que ça signifie : qemu a le périphérique ouvert. LVM a raison de refuser la suppression.

Décision : Comprenez pourquoi qemu tient un LV snapshot. Communément : un block job, une sauvegarde, ou une tentative de rollback. Ne tuez pas qemu aveuglément sauf si vous avez accepté l’impact sur la VM.

Tâche 9 : Mapper les nœuds device-mapper aux noms lisibles

cr0x@server:~$ dmsetup ls --tree | sed -n '1,80p'
pve-thinpool (253:2)
 ├─pve-vm--104--disk--0 (253:3)
 ├─pve-vm--104--disk--0--pre--upgrade--2025w51 (253:7)
 └─pve-vm--104--disk--0--before--agent--change (253:8)

Ce que ça signifie : Le snapshot est un périphérique dm. S’il est ouvert, dm n’autorisera pas LVM à le supprimer proprement.

Décision : Utilisez ce mapping pour confirmer exactement ce qui est ouvert, et évitez la pensée « rm -rf ». Vous pouvez aussi utiliser dmsetup info pour vérifier le compteur d’ouverture.

Tâche 10 : Vérifier le compteur d’ouverture sur le périphérique problématique

cr0x@server:~$ dmsetup info -c /dev/mapper/pve-vm--104--disk--0--pre--upgrade--2025w51
Name  Maj Min Stat Open Targ Event  UUID
pve-vm--104--disk--0--pre--upgrade--2025w51 253 7 L--w 1 1 0 LVM-6l3B0bQyQq0yYV3uQ0sG0fQxY3o2mV3S

Ce que ça signifie : Open est 1. Quelque chose l’a ouvert. Cela explique l’échec de lvremove.

Décision : Trouvez et arrêtez le titulaire (préféré), ou terminez l’opération qui le retient, puis retentez la suppression. Si Open est 0 et que lvremove échoue encore, vous avez affaire à des mappings obsolètes ou à des bizarreries de métadonnées LVM.

Tâche 11 : Vérifier les jobs de sauvegarde ou sauvegardes basées sur snapshot en cours

cr0x@server:~$ ps aux | grep -E 'vzdump|qemu-nbd|pbs-client' | grep -v grep
root     18444  2.1  0.1  35472 12896 ?        Ss   09:05   0:16 vzdump 104 --mode snapshot --compress zstd

Ce que ça signifie : Le job de sauvegarde a peut-être créé des mappings snapshot temporaires ou peut retenir des périphériques ouverts pendant le transfert.

Décision : Laissez la sauvegarde se terminer ou arrêtez-la proprement si elle est bloquée. Supprimer des snapshots au milieu d’une sauvegarde est un excellent moyen de se fabriquer des accusations de corruption.

Tâche 12 : Tenter la suppression de la manière supportée (après avoir levé la cause racine)

cr0x@server:~$ qm delsnapshot 104 pre-upgrade-2025w51
delete snapshot 'pre-upgrade-2025w51'
TASK OK

Ce que ça signifie : Proxmox a géré la suppression, mis à jour l’état de config, et demandé à LVM de supprimer le bon LV.

Décision : Revérifiez l’utilisation du thin pool et que le LV est réellement parti. « TASK OK » est nécessaire, mais pas suffisante.

Tâche 13 : Vérifier que le LV est réellement supprimé (faire confiance, puis vérifier)

cr0x@server:~$ lvs -a pve | grep -E 'vm-104-disk-0-pre--upgrade'

Ce que ça signifie : Pas de sortie signifie que le LV a été supprimé.

Décision : S’il est encore présent, vous avez une défaillance partielle : l’état Proxmox dit « supprimé » mais LVM ne l’a pas fait. C’est là que commence le nettoyage manuel, et vous le faites avec précaution.

Tâche 14 : Rechercher les volumes « inconnus » du point de vue de Proxmox

cr0x@server:~$ pvesm list local-lvm | grep -E 'vm-104|unused|snap' | head -n 20
local-lvm:vm-104-disk-0        vmimage 200.00g
local-lvm:vm-104-disk-0-before--agent--change  vmimage 200.00g

Ce que ça signifie : Proxmox voit encore le snapshot « before-agent-change » comme une image VM. Cela peut être correct ou un résidu selon ce que qm listsnapshot renvoie.

Décision : Si Proxmox ne liste pas le snapshot mais que pvesm list le fait, considérez-le comme candidat orphelin et confirmez les références avant suppression.

Tâche 15 : Vérifier la config VM pour des disques « unused » pointant vers d’anciens LVs

cr0x@server:~$ grep -E '^(scsi|virtio|sata|unused)[0-9]+:' /etc/pve/qemu-server/104.conf
scsi0: local-lvm:vm-104-disk-0,size=200G
unused0: local-lvm:vm-104-disk-0-before--agent--change

Ce que ça signifie : Proxmox gare parfois des volumes qui ne sont plus attachés sous la forme unusedX. C’est une forme polie de thésaurisation.

Décision : S’il est vraiment inutilisé, supprimez-le via Proxmox pour qu’il mette à jour son inventaire, puis validez avec LVM.

Tâche 16 : Supprimer un disque unused en toute sécurité via l’outil Proxmox

cr0x@server:~$ qm unused 104
unused0: local-lvm:vm-104-disk-0-before--agent--change

cr0x@server:~$ qm set 104 --delete unused0
update VM 104: -delete unused0

Ce que ça signifie : La référence de config est supprimée. Selon le stockage et les paramètres, le LV sous-jacent peut exister jusqu’à suppression explicite.

Décision : Retirez maintenant le volume via pvesm free (préféré) ou lvremove (seulement si vous avez confirmé qu’il est orphelin).

Tâche 17 : Libérer un volume en utilisant le gestionnaire de stockage Proxmox

cr0x@server:~$ pvesm free local-lvm:vm-104-disk-0-before--agent--change
successfully removed 'local-lvm:vm-104-disk-0-before--agent--change'

Ce que ça signifie : Proxmox a demandé au backend de supprimer le LV et a mis à jour son état interne.

Décision : Si cela échoue avec « volume is busy », revenez au compteur d’ouverture et aux processus détenteurs. Forcer la suppression ici est la manière de se réveiller à 3h du matin avec des surprises.

Tâche 18 : Si Proxmox est désynchronisé, localiser les vrais orphelins en scannant LVM pour des volumes « vm- » sans configs

cr0x@server:~$ ls /etc/pve/qemu-server | sed 's/\.conf$//' | sort -n | tail -n 5
101
102
104
110
132

cr0x@server:~$ lvs --noheadings -o lv_name pve | awk '{print $1}' | grep '^vm-' | head
vm-101-disk-0
vm-102-disk-0
vm-104-disk-0
vm-999-disk-0-oldsnap

Ce que ça signifie : vm-999-... existe dans LVM mais il n’y a pas de 999.conf. C’est un candidat orphelin.

Décision : Avant de supprimer, confirmez qu’il n’est pas référencé par une autre VM (clones liés, chaînes de template) et qu’il n’est pas utilisé par la réplication ou des outils de sauvegarde.

Tâche 19 : Confirmer si un candidat orphelin est référencé quelque part dans les configs Proxmox

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

Ce que ça signifie : Pas de sortie suggère qu’aucune config VM ne le référence.

Décision : Vérifiez quand même qu’il n’est pas ouvert et qu’il ne fait pas partie d’une chaîne origine/snapshot importante.

Tâche 20 : Vérifier les relations snapshot/origin pour un candidat orphelin

cr0x@server:~$ lvs -a -o lv_name,lv_attr,origin,lv_size,data_percent pve | grep -E 'vm-999|Origin'
vm-999-disk-0-oldsnap              Vwi---tz-k  vm-999-disk-0                 100.00g  24.11
vm-999-disk-0                      Vwi-aotz--                                   100.00g  88.02

Ce que ça signifie : Le LV « oldsnap » est un snapshot de vm-999-disk-0. Si vm-999-disk-0 est aussi orphelin, vous pouvez supprimer les deux—mais l’ordre compte et vous devriez vérifier les compteurs d’ouverture.

Décision : Supprimez d’abord les snapshots, puis les origines, à moins d’avoir une raison (et des preuves) de faire autrement.

Tâche 21 : Confirmer que rien n’a l’LV orphelin ouvert

cr0x@server:~$ dmsetup info -c /dev/mapper/pve-vm--999--disk--0--oldsnap
Name  Maj Min Stat Open Targ Event  UUID
pve-vm--999--disk--0--oldsnap 253 22 L--w 0 1 0 LVM-0bqVtQyS2L3kVJrQ9xF5jH1gYd2nM3p

Ce que ça signifie : Le compteur Open est 0. Bien.

Décision : Vous pouvez le supprimer, mais faites-le de manière à garder la cohérence des métadonnées LVM et à faciliter l’audit.

Tâche 22 : Supprimer un LV orphelin avec LVM directement (seulement après preuve d’orphelinat)

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

Ce que ça signifie : Le LV snapshot est parti. Si c’était le résidu, vous devriez voir l’utilisation du thin pool baisser avec le temps (parfois pas instantanément si les discards sont différés).

Décision : Revérifiez l’usage du pool et les métadonnées. Si les métadonnées restent dangereusement élevées, planifiez une extension des métadonnées ou une fenêtre de maintenance pour un nettoyage plus approfondi.

Tâche 23 : Reverifier l’état du thin pool après nettoyage

cr0x@server:~$ lvs -o lv_name,data_percent,metadata_percent pve/thinpool
LV       Data%  Meta%
thinpool 69.90  88.40

Ce que ça signifie : Les métadonnées sont passées de 92% à 88%. C’est significatif. Le soulagement des métadonnées importe souvent plus que l’usage brut des données quand les suppressions échouent.

Décision : Si les métadonnées sont encore élevées, continuez à élaguer les snapshots et envisagez d’étendre la metadata du thinpool.

Tâche 24 : Étendre les métadonnées du thin pool (avec prudence) quand vous êtes près du gouffre

cr0x@server:~$ lvdisplay pve/thinpool | grep -E 'LV Size|Pool metadata'
LV Size                7.30 TiB
Pool metadata          thinpool_tmeta

cr0x@server:~$ lvs -o lv_name,lv_size pve | grep thinpool_tmeta
thinpool_tmeta  16.00g

cr0x@server:~$ lvextend -L +4G pve/thinpool_tmeta
Size of logical volume pve/thinpool_tmeta changed from 16.00 GiB (4096 extents) to 20.00 GiB (5120 extents).
Logical volume pve/thinpool_tmeta successfully resized.

cr0x@server:~$ lvconvert --repair pve/thinpool
Attempting repair of thin pool pve/thinpool
Thin pool pve/thinpool repaired

Ce que ça signifie : Vous avez augmenté la capacité des métadonnées et réparé/mis à jour les structures du thin pool. Selon votre environnement, vous n’aurez pas besoin de --repair sauf si le pool le réclame, mais redimensionner les métadonnées est une soupape standard contre la pression.

Décision : Si vous n’avez pas d’extents libres dans le VG, arrêtez-vous ici et planifiez une expansion de stockage. Étendre les métadonnées sans espace disponible n’est pas une astuce intelligente ; c’est comment on transforme des avertissements en indisponibilités.

Tâche 25 : Valider l’inventaire Proxmox après modifications manuelles LVM

cr0x@server:~$ pvesm list local-lvm | grep -E 'vm-999|oldsnap' || true

Ce que ça signifie : Pas de sortie signifie que Proxmox ne le voit pas. S’il apparaît encore, rescannez ou vous avez peut-être une perception de cache de stockage obsolète.

Décision : Préférez que Proxmox soit l’acteur des suppressions. Si vous devez faire des suppressions LVM manuelles, suivez par une vérification d’inventaire et un nettoyage de config.

Blague #2 : LVM-thin est comme un tiroir à bazar—tout rentre jusqu’au moment où vous devez trouver une seule chose et qu’elle en retient trois autres en otage.

Trois micro-histoires d’entreprise (comment cela foire en vrai)

Micro-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne exploitait un cluster Proxmox pour des services internes : runners de build, quelques applications legacy, et une poignée de VMs « temporaires » qui ont survécu à trois réorganisations. Les snapshots étaient beaucoup utilisés avant les fenêtres de patch. Le backend de stockage était LVM-thin sur SSD rapides, parce que « c’est simple et local ».

Lors d’une fenêtre de mise à jour du noyau, un ingénieur a supposé que supprimer un snapshot est toujours une opération metadata et donc quasiment instantanée. Ils ont enchaîné des suppressions pour des dizaines de vieux snapshots sur plusieurs VMs alors que des sauvegardes tournaient aussi en mode snapshot. Le système n’a pas échoué immédiatement ; il est devenu lent. Vraiment lent.

Les métadonnées du thin pool ont grimpé dans les haut 90s. LVM a commencé à émettre des avertissements, puis le thin pool est passé en lecture seule pour se protéger. C’était le moment où « supprimer des snapshots pour libérer de l’espace » a cessé d’être une option, parce que l’acte même de libérer de l’espace nécessitait des écritures de métadonnées.

L’incident n’était pas dramatique au sens explosions—juste une incapacité croissante à écrire : les VMs bloquaient sur l’I/O disque, les services expiraient, et tous les tableaux de bord s’allumaient comme si le réseau lâchait. La cause racine était le stockage, mais tout avait l’air d’autre chose.

La réparation fut ennuyeuse et douloureuse : arrêter les jobs intensifs en snapshots, éteindre les VMs non critiques pour réduire la churn, étendre les métadonnées, puis élaguer soigneusement les snapshots dans un ordre contrôlé. La leçon : la suppression de snapshots peut être la charge I/O la plus lourde que vous fassiez de la semaine, selon la pression metadata et le nombre d’opérations concurrentes.

Micro-histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait des sauvegardes plus rapides. Ils ont ajusté leur pipeline pour lancer plus de VMs en parallèle, toujours en mode snapshot, car cela réduisait le downtime invité. Quelqu’un a aussi activé une planification agressive pour que les sauvegardes finissent avant les heures ouvrées. Ça a bien marché quelques semaines.

Puis ça a commencé à « échouer aléatoirement » : parfois les snapshots ne se supprimaient pas, parfois l’utilisation du thin pool ne baissait pas, parfois des LVs restaient « occupés » longtemps après la fin du job de sauvegarde. On a suspecté des bugs Proxmox, puis des bugs noyau, puis « peut-être le firmware des SSD ». Le tour habituel.

Le vrai problème était un couplage qu’ils n’avaient pas modélisé : les sauvegardes snapshot parallèles augmentaient la durée de vie et le nombre de périphériques snapshot mappés simultanément. Cela a augmenté les compteurs d’ouverture, et cela a augmenté le churn de métadonnées. Quand l’utilisation des métadonnées a monté, les opérations ont ralenti, ce qui a allongé la fenêtre de sauvegarde, ce qui a créé plus de chevauchements, ce qui a créé plus de périphériques ouverts. Une boucle de rétroaction à la coupe de cheveux corporate.

Ils se sont « optimisés » dans un système où le nettoyage ne suivait plus la création. La partie qui a mal tourné n’était pas que le parallélisme soit mauvais ; c’est qu’ils ont ajouté du parallélisme sans garde-fous liés à la santé du thin pool. La solution a été de limiter la concurrence en fonction du pourcentage de metadata et d’échelonner les opérations de snapshot. Les sauvegardes ont duré un peu plus longtemps, mais le cluster a arrêté de jouer à la roulette du stockage.

Micro-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Un environnement régulé (beaucoup de paperasse, beaucoup de contrôle de changement) avait un cluster Proxmox qui n’était ni le plus rapide ni le plus récent, mais il était stable. Leur pratique de stockage était douloureusement conservatrice : limiter le nombre de snapshots par VM, appliquer un TTL sur les snapshots « temporaires », et exécuter un audit hebdomadaire qui comparait l’inventaire Proxmox à LVM.

Une semaine, l’audit a signalé quelques LVs qui n’apparaissaient dans aucune config VM. Personne n’a paniqué. Ils ont suivi le runbook : vérifier le compteur d’ouverture, chercher des tâches de réplication/sauvegarde, confirmer les relations d’origine, puis planifier la suppression dans la fenêtre suivante.

Deux jours plus tard, un nœud a planté à cause d’un problème matériel sans rapport. Lors de la récupération, ils ont découvert que les LVs orphelins venaient d’une tentative de migration à moitié échouée. Si ces LVs étaient restés, ils auraient poussé les métadonnées près du gouffre pendant le pic d’écriture de la reprise. Au lieu de cela, il y avait de la marge dans les métadonnées, et la reprise est restée ennuyeuse. Ennuyeux est le plus grand compliment en exploitation.

La pratique salvatrice n’était pas un génie. C’était une réconciliation régulière et des limites disciplinées. Leur système de snapshots n’était pas « plus fiable » grâce à un système de fichiers sophistiqué ; il était fiable parce qu’ils traitaient l’état du stockage comme l’état financier : rapprochez-le, ne le supposez pas.

Checklists / plan étape par étape : nettoyage sûr des résidus LVM-thin

Voici le plan que je donnerais à un on-call qui doit réparer ça sans improviser. L’objectif : supprimer les snapshots bloqués et les LVs orphelins sans causer de perte de données accidentelle ni transformer le thin pool en lecture seule.

Checklist A : Stabiliser le patient

Geler la création de nouveaux snapshots. Suspendez les jobs de sauvegarde et toute automatisation créant des snapshots.
Vérifier le pourcentage de métadonnées du thin pool. Si c’est très élevé, considérez chaque opération comme plus risquée et plus lente.
Identifier si la/les VM(s) peuvent être arrêtées. Si vous pouvez les arrêter, vous résoudrez les conditions « busy » plus vite et plus sûrement.
Confirmer qu’il n’y a pas déjà une panne de stockage en cours. Si le pool est en lecture seule ou rapporte des erreurs, stoppez et passez en mode incident.

Checklist B : Privilégier la suppression native Proxmox d’abord

Lister les snapshots avec qm listsnapshot <vmid>.
Tenter la suppression avec qm delsnapshot.
Si ça échoue, lire le log de la tâche et capturer le nom exact du LV et le message d’erreur.
Si c’est « busy », trouvez les détenteurs ouverts et supprimez le détenteur, pas l’LV.

Checklist C : Quand l’état est incohérent, rapprocher avant de supprimer

Lister les volumes LVM pour l’ID VM avec lvs.
Rechercher dans les configs Proxmox des références aux LVs candidats.
Vérifier les relations snapshot/origin et le compteur d’ouverture.
Ce n’est qu’après cela que vous utilisez pvesm free ou lvremove.

Checklist D : Ordre des opérations pour le nettoyage manuel (par défaut sûr)

Arrêter la VM si possible (ou au moins arrêter les tasks backup/réplication).
Supprimer d’abord les snapshots (LVs snapshot thin ayant une origine).
Supprimer ensuite les LVs vraiment inutilisés/orphelins.
Revérifier les métadonnées du thin pool. Si toujours élevées, envisager d’étendre les métadonnées ou planifier un élagage plus complet.
Remettre la VM en marche et exécuter un rapide contrôle d’intégrité côté invité si vous avez fait quelque chose d’invasif.

Checklist E : Si les métadonnées du thin pool sont critiques

Arrêter la churn des snapshots (sauvegardes, schedules, migrations qui snapshotent).
Libérer les gains faciles : supprimer d’abord les vieux snapshots sur les VMs non critiques.
Si vous avez des extents libres, étendre les métadonnées (thinpool_tmeta).
Ce n’est qu’ensuite que vous tentez les nettoyages plus lourds comme la suppression en masse de snapshots.

Erreurs courantes : symptôme → cause racine → correction

1) « La suppression du snapshot reste bloquée indéfiniment »

Symptôme : La tâche Proxmox tourne longtemps ; le stockage reste occupé ; timeout éventuel.
Cause racine : Pression sur les métadonnées du thin pool et/ou activité concurrente intense de snapshots ; la suppression réalise un vrai travail.
Correction : Réduisez la concurrence, suspendez les sauvegardes, vérifiez le %. Si élevé, étendez les métadonnées et élaguez les snapshots par petits lots.

2) « TASK ERROR: contains a filesystem in use » ou « device busy »

Symptôme : lvremove échoue ; Proxmox rapporte un volume occupé.
Cause racine : qemu ou les outils de sauvegarde retiennent le périphérique dm ouvert.
Correction : Utilisez lsof/dmsetup info pour identifier les détenteurs ; arrêtez la tâche ou la VM ; retentez la suppression native Proxmox.

3) « Le snapshot n’est pas listé dans l’UI, mais l’espace est toujours utilisé »

Symptôme : Aucun snapshot dans qm listsnapshot, pourtant le thin pool reste plein ; des LVs existent dans lvs.
Cause racine : LVs thin orphelins dus à des échecs partiels (migration, sauvegarde, crash en cours de suppression).
Correction : Rapprochez : scannez LVM pour des LVs vm-, grep les configs pour les références, vérifiez le compteur d’ouverture, puis supprimez via pvesm free ou lvremove.

4) « Impossible de créer des snapshots maintenant »

Symptôme : La création de snapshot échoue ; erreurs sur le thin pool ou espace insuffisant.
Cause racine : Métadonnées du thin pool pleines (plus courant que les données pleines dans les environnements à snapshots intensifs).
Correction : Étendez thinpool_tmeta si possible ; élaguez les snapshots ; appliquez des limites de snapshots par VM.

5) « Proxmox affiche des disques ‘unused’ pour toujours »

Symptôme : La config VM accumule des entrées unused0, unused1 ; le stockage ne se libère jamais.
Cause racine : Détachement sans suppression ; valeurs par défaut prudentes ; ou opérateurs évitant les actions destructrices.
Correction : Auditez avec qm unused, confirmez que les disques ne sont pas nécessaires, puis supprimez les références de config et libérez les volumes via pvesm free.

6) « Après un lvremove manuel, Proxmox pense toujours que le volume existe »

Symptôme : L’UI montre un volume fantôme ; les opérations échouent avec ‘volume does not exist’ ou des incohérences similaires.
Cause racine : Des références de config restent (unusedX ou entrées disque), ou le cache d’inventaire Proxmox n’a pas été rafraîchi.
Correction : Supprimez les références de la config VM via qm set --delete ; vérifiez avec pvesm list.

FAQ

1) Est-il sûr de supprimer des snapshots LVM-thin pendant que la VM est en marche ?

Parfois oui—quand Proxmox a créé le snapshot et le supprime dans un flux normal. Si le LV est « busy », la réponse sûre devient « arrêtez la VM ou le job qui le retient ». Ne luttez pas contre des périphériques ouverts.

2) Pourquoi les métadonnées du thin pool se remplissent-elles plus vite que les données ?

Les snapshots et les changements fréquents de blocs créent beaucoup de mises à jour de mapping. Les métadonnées suivent ces mappings. Un petit LV de métadonnées peut devenir le facteur limitant bien avant que l’espace données soit épuisé.

3) Si `qm listsnapshot` est vide, peut-il quand même y avoir des snapshots ?

Oui. Proxmox suit les snapshots dans l’état de config ; LVM suit les volumes thin snapshot. Si une suppression ou une migration a échoué partiellement, LVM peut garder des snapshot LVs que Proxmox ne référence plus.

4) Quelle est la façon la plus sûre de supprimer un LV thin LVM orphelin ?

D’abord prouvez qu’il n’est pas référencé : grep dans les configs Proxmox, vérifiez les chaînes origin, confirmez que le compteur d’ouverture est zéro. Puis supprimez via pvesm free si Proxmox le connaît, sinon lvremove.

5) Puis-je simplement redémarrer le nœud pour effacer « device busy » ?

Un redémarrage efface souvent les compteurs d’ouverture, oui. Il efface aussi souvent votre fenêtre de maintenance et la remplace par un incident. Redémarrez seulement si vous comprenez qui tient le périphérique et si vous pouvez tolérer l’impact.

6) Pourquoi mon usage thin pool n’a-t-il pas baissé après la suppression des snapshots ?

La libération d’espace peut être retardée par le comportement de discard, la comptabilité interne du thin pool, et des écritures en cours. De plus, si le snapshot retenait des blocs uniques encore référencés ailleurs, vous ne récupérerez pas autant que prévu.

7) Quelle est la différence entre « disque unused » et « résidu de snapshot » en termes Proxmox ?

« Disque unused » est une référence de config Proxmox à un volume non attaché à la VM. Un « résidu de snapshot » est typiquement un LV LVM qui existe sans enregistrement snapshot correspondant dans Proxmox (ou l’inverse).

8) Dois-je étendre les métadonnées du thin pool ou simplement supprimer plus de snapshots ?

Si les métadonnées sont proches du gouffre et que vous avez des extents libres, étendre les métadonnées achète de la sécurité et du temps. Supprimez quand même des snapshots—l’extension n’est pas un régime, c’est une ceinture plus grande.

9) Comment éviter que cela ne se reproduise ?

Limitez le nombre et la durée des snapshots, plafonnez la concurrence des sauvegardes en fonction du % de metadata du thin pool, et exécutez une réconciliation régulière entre les configs Proxmox et les volumes LVM. Aussi : n’autorisez pas les snapshots « temporaires » à devenir des résidents permanents.

Conclusion : prochaines étapes pour éviter les ennuis

Quand les snapshots Proxmox ne se suppriment pas, le problème est rarement « un bouton cassé ». C’est presque toujours l’un des trois : un verrou/tâche obsolète, un thin pool sous pression de métadonnées, ou un périphérique ouvert que LVM refuse correctement de détruire.

Faites le diagnostic rapide dans l’ordre. Utilisez les suppressions natives Proxmox quand c’est possible. Quand il faut faire du manuel, rapprochez d’abord les états, vérifiez les compteurs d’ouverture, et supprimez dans le bon ordre. Ensuite offrez-vous le cadeau de la prévention : appliquez des TTLs de snapshots, limitez la concurrence, et surveillez les métadonnées du thin pool comme un SLO de première classe.