Proxmox « VM verrouillée (sauvegarde/snapshot) » : comment retirer un verrou en toute sécurité

Ce que le verrou signifie réellement (et ce qu’il ne signifie pas)

Un verrou de VM Proxmox est un mécanisme de coordination. C’est une petite métadonnée qui indique : « Quelque chose effectue une opération qui ne doit pas chevaucher d’autres opérations. » Typiquement, ce « quelque chose » est une des opérations suivantes :

• sauvegarde (vzdump, PBS, ou intégration tierce)
• instantané (instantané QEMU et/ou instantané côté stockage)
• clone (souvent basé sur un instantané)
• migration (live ou offline)
• réplication (tâches de réplication Proxmox)

Le message apparaît généralement quand vous essayez de :

• démarrer/arrêter/redémarrer une VM (parfois autorisé, souvent bloqué selon l’opération)
• supprimer une VM
• retirer un disque
• prendre un autre instantané
• déplacer le stockage

La règle centrale : ne déverrouillez que lorsque vous pouvez prouver qu’aucune opération n’est réellement en cours

Un verrou obsolète est agaçant. Un déverrouillage prématuré peut coûter cher. Si une sauvegarde est en cours de streaming de l’état des disques et que vous déverrouillez puis supprimez l’instantané sous-jacent, vous créez une « sauvegarde » qui n’est ni cohérente ni honnête. Elle restaurera dans une VM en forme de mystère.

Les verrous peuvent aussi être « vrais » même si rien ne semble actif dans l’interface graphique. Peut‑être que le processus worker de Proxmox est mort, que le nœud a redémarré en plein travail, que le stockage a eu un incident, ou qu’une tâche est bloquée dans une attente noyau non interrompable. L’UI ne ment pas ; elle n’explique simplement pas toujours pourquoi.

Un réconfort sec : les verrous sont rarement la cause première. Ils sont le symptôme. La cause première est généralement la latence du stockage, un processus de sauvegarde bloqué, un instantané impossible à valider, ou un agent invité gelé qui ne s’est jamais débloqué.

Blague #1 : Un verrou Proxmox ressemble à un panneau « Ne pas déranger » sur la porte d’un hôtel — sauf que le chariot de ménage est votre baie de stockage et pèse plusieurs tonnes.

Plan de diagnostic rapide (premières/deuxièmes/troisièmes vérifications)

Voici la boucle « arrêter de deviner ». L’objectif : décider rapidement si vous devez attendre, annuler ou déverrouiller.

Première étape : confirmer le type de verrou et trouver la tâche qui l’a posé

1. Identifiez le VMID et le type de verrou depuis l’erreur (sauvegarde/instantané/migration/clone/réplication).
2. Vérifiez les tâches récentes sur le nœud et le cluster.
3. Cherchez un worker vzdump, pvescheduler, pveproxy, pvestatd ou pve-storage lié à ce VMID.

Deuxième étape : prouver si un travail est toujours en cours

1. Contrôlez les E/S sur le stockage qui héberge la VM (zpool iostat ZFS, Ceph rbd status, statistiques de montage NFS).
2. Vérifiez le processus QEMU et s’il est bloqué (ps, top, et indices d’état noyau « D state »).
3. Contrôlez la progression des artefacts d’instantané/sauvegarde (ingestion de chunks PBS, fichiers temporaires vzdump, présence d’instantanés ZFS).

Troisième étape : choisir le chemin de résolution le plus sûr

• Si une tâche progresse toujours : attendez. Si c’est critique, déplacez le problème humain (fenêtre de changement) plutôt que le problème disque.
• Si une tâche est bloquée mais annulable : arrêtez la tâche proprement (tuez le bon worker, annulez la tâche, supprimez une référence PID obsolète).
• Si tout est mort et qu’il ne reste que le verrou : déverrouillez, puis validez immédiatement les disques VM et l’état des instantanés.

Si vous hésitez entre « déverrouiller » et « ne rien faire », choisissez « ne rien faire » jusqu’à disposer de preuves. Les verrous sont peu coûteux ; la récupération des données ne l’est pas.

Faits intéressants et historique qui expliquent le comportement actuel

• Fait 1 : la configuration des VM Proxmox est du texte brut, stockée sous /etc/pve/ sur un système de fichiers distribué (pmxcfs). Cela rend facile la représentation des verrous comme une ligne dans un fichier de config.
• Fait 2 : pmxcfs est un système de fichiers de cluster soutenu par Corosync ; il est conçu pour de petites configs/états, pas pour des données en masse. Lorsqu’il est malheureux, les écritures de config (y compris les mises à jour de verrous) peuvent être retardées ou échouer.
• Fait 3 : le verrou « sauvegarde » est généralement placé par vzdump (classique) ou par des workers liés aux sauvegardes ; il empêche le chevauchement d’opérations snapshot/sauvegarde qui briseraient la cohérence.
• Fait 4 : les instantanés dans Proxmox peuvent être « internes QEMU », « instantanés côté stockage », ou un mix — selon le type de stockage et la configuration. C’est pourquoi effacer un verrou sans nettoyer l’état du stockage peut laisser un instantané que vous ne pouvez pas supprimer.
• Fait 5 : le gel/dégel via guest-agent est utilisé pour améliorer la cohérence des systèmes de fichiers, mais si l’agent est absent ou bloqué, l’orchestration d’instantané peut s’arrêter à des endroits surprenants.
• Fait 6 : les opérations d’instantané QEMU dépendent de QMP (QEMU Machine Protocol). Si QEMU est bloqué ou que QMP ne répond plus, Proxmox ne peut pas compléter le workflow d’instantané, et le verrou peut persister.
• Fait 7 : un « backup bloqué » n’est souvent pas un problème de sauvegarde. C’est un problème de latence d’I/O. Un disque lent ou défaillant peut faire paraître qu’un commit d’instantané « ne fait rien ». En réalité, cela avance, mais très lentement.
• Fait 8 : sur les stockages CoW (ZFS, Ceph), les instantanés sont peu coûteux à créer et parfois coûteux à supprimer — surtout si beaucoup de blocs ont changé après l’instantané.
• Fait 9 : Proxmox a historiquement supporté plusieurs backends de stockage avec des sémantiques différentes (LVM-thin, ZFS, RBD, NFS). Les verrous sont une abstraction unificatrice sur une réalité désordonnée.

Où Proxmox stocke les verrous et comment ils restent bloqués

Le verrou est généralement une ligne dans la config de la VM

La plupart du temps, le verrou est enregistré dans le fichier de configuration de la VM sous pmxcfs, par exemple :

• /etc/pve/qemu-server/101.conf pour VMID 101
• /etc/pve/lxc/202.conf pour le conteneur 202 (les conteneurs ont aussi des verrous)

Vous verrez typiquement quelque chose comme :

• lock: backup
• lock: snapshot
• lock: migrate

Proxmox place le verrou au début d’une opération sensible, puis le retire à la fin. Si le worker plante, si le nœud redémarre, si pmxcfs ne peut pas valider le changement de config, ou si la tâche est tuée à un mauvais moment, l’étape « nettoyage du verrou » ne s’exécute jamais.

Pourquoi un verrou obsolète est plus sûr qu’un système optimiste

Proxmox choisit le mode d’échec conservateur : s’il n’est pas sûr, il bloque. Cela ennuie les humains, mais cela vous empêche de faire des opérations destructrices alors qu’un merge d’instantané pourrait être en cours.

Voici la réalité opérationnelle : le « verrou » n’est pas un verrou noyau. Il ne garantit pas qu’un instantané soit réellement actif. Il signifie seulement : à un moment donné, Proxmox croyait qu’il était actif, et il n’a pas enregistré la complétion.

Ce que signifie réellement un « déverrouillage sûr »

Un déverrouillage sûr n’est pas « exécuter qm unlock et passer à autre chose. » Un déverrouillage sûr c’est :

1. Trouver la tâche qui a posé le verrou.
2. Confirmer qu’elle n’est plus en cours (ou qu’elle est bloquée irrécupérablement).
3. Confirmer que la couche de stockage n’est pas en pleine transaction (commit d’instantané, envoi de réplication, RBD flatten, etc.).
4. Supprimer le verrou.
5. Valider que la VM peut démarrer et que les opérations d’instantané sont à nouveau saines.

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

Tous les exemples supposent VMID 101 sur le nœud pve1. Adaptez à votre environnement. Les commandes sont volontairement ennuyeuses ; l’ennui est la façon de préserver les données.

Tâche 1 : Confirmer le verrou et son type

cr0x@server:~$ qm config 101 | grep -E '^lock:|^name:|^scsi|^virtio'
name: app-prod-01
lock: backup
scsi0: local-zfs:vm-101-disk-0,size=120G

Ce que cela signifie : Proxmox pense qu’un workflow de backup est actif ou non terminé pour la VM 101.

Décision : Ne déverrouillez pas encore. Trouvez la tâche de sauvegarde et confirmez son état.

Tâche 2 : Trouver les tâches récentes faisant référence au VMID

cr0x@server:~$ pvesh get /nodes/pve1/tasks --limit 20 --output-format json-pretty | grep -n "101"
42:     "id": "UPID:pve1:0000A1B2:0123ABCD:676D7B22:vzdump:101:root@pam:",

Ce que cela signifie : Il y a eu un job vzdump pour la VM 101.

Décision : Récupérez le journal et voyez s’il a terminé, échoué ou est encore en cours.

Tâche 3 : Lire le journal de la tâche (vérité la plus rapide dans Proxmox)

cr0x@server:~$ pvesh get /nodes/pve1/tasks/UPID:pve1:0000A1B2:0123ABCD:676D7B22:vzdump:101:root@pam:/log
INFO: starting new backup job: vzdump 101 --storage backup-nfs --mode snapshot --compress zstd
INFO: creating Proxmox backup snapshot
INFO: status = running

Ce que cela signifie : La tâche indique « running » et n’a pas enregistré sa complétion. Elle peut être réellement en cours ou bloquée.

Décision : Vérifiez si le processus existe et s’il progresse.

Tâche 4 : Vérifier si un worker vzdump est réellement en cours

cr0x@server:~$ ps aux | egrep 'vzdump|pvescheduler|pve-backup' | grep -v grep
root      41233  0.5  0.2  24572  9120 ?        Ss   01:12   0:03 vzdump 101 --storage backup-nfs --mode snapshot --compress zstd

Ce que cela signifie : Un processus vzdump est vivant.

Décision : Ne déverrouillez pas. Ensuite : déterminez s’il progresse ou est gelé.

Tâche 5 : Surveiller les fichiers temporaires de sauvegarde pour détecter du mouvement (comportement classique de vzdump)

cr0x@server:~$ ls -lh /var/lib/vz/dump | tail -n 5
-rw-r--r-- 1 root root  88G Dec 26 01:18 vzdump-qemu-101-2025_12_26-01_12_04.vma.zst.tmp

Ce que cela signifie : Il y a un fichier temporaire. Si sa taille augmente avec le temps, la sauvegarde progresse.

Décision : Échantillonnez la taille deux fois (ou utilisez watch). Si la croissance continue, attendez. Si elle stagne, inspectez l’état du stockage et du processus.

Tâche 6 : Vérifier si le fichier temporaire continue de croître

cr0x@server:~$ stat -c '%n %s %y' /var/lib/vz/dump/vzdump-qemu-101-2025_12_26-01_12_04.vma.zst.tmp
/var/lib/vz/dump/vzdump-qemu-101-2025_12_26-01_18:27.000000000 +0000

Ce que cela signifie : C’est un point dans le temps. Exécutez la commande à nouveau après 30–60 secondes.

Décision : Si la taille et la mtime ne changent pas, considérez la tâche comme possiblement bloquée et passez aux vérifications du stockage.

Tâche 7 : Vérifier la santé du processus VM et la réactivité de QEMU

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

Ce que cela signifie : La VM tourne toujours ; les sauvegardes en mode instantané la laissent souvent fonctionner pendant l’instantané.

Décision : Si la sauvegarde est bloquée, ne redémarrez pas la VM « pour le réparer ». C’est ainsi que vous transformez une sauvegarde bloquée en une VM bloquée plus une sauvegarde bloquée.

Tâche 8 : Chercher l’état noyau « D » sur les threads de sauvegarde ou QEMU

cr0x@server:~$ ps -eo pid,stat,cmd | egrep 'vzdump 101|kvm -id 101' | head
41233 D    vzdump 101 --storage backup-nfs --mode snapshot --compress zstd
20987 Sl   /usr/bin/kvm -id 101 -name app-prod-01 ...

Ce que cela signifie : Le processus vzdump est en état D (sommeil non interrompable), généralement en attente d’E/S (NFS, disque, ZFS, Ceph, etc.). Le tuer peut ne pas fonctionner tant que les E/S ne reviennent pas.

Décision : Ne commencez pas par kill -9. Commencez par trouver le goulot d’I/O.

Tâche 9 : Identifier sur quel stockage réside le disque de la VM

cr0x@server:~$ qm config 101 | grep -E '^(scsi|virtio|sata)[0-9]+:'
scsi0: local-zfs:vm-101-disk-0,size=120G

Ce que cela signifie : Le disque est sur le stockage ZFS local-zfs. Les sémantiques d’instantané/suppression dépendent de ZFS.

Décision : Vérifiez la santé du pool ZFS et l’état des instantanés avant d’envisager un déverrouillage.

Tâche 10 : Vérifier la santé du pool ZFS (test rapide contre la corruption)

cr0x@server:~$ zpool status -x
all pools are healthy

Ce que cela signifie : ZFS ne signale pas d’erreurs connues.

Décision : Si le pool est en mauvaise santé, arrêtez-vous et traitez-le comme un incident de stockage. Déverrouiller ne vous sauvera pas.

Tâche 11 : Vérifier les E/S et la latence ZFS

cr0x@server:~$ zpool iostat -v 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
rpool       1.10T  700G     12    340   2.1M  110M
  mirror    1.10T  700G     12    340   2.1M  110M
    sda         -      -      6    170   1.0M   55M
    sdb         -      -      6    170   1.1M   55M

Ce que cela signifie : Des écritures ont lieu ; la sauvegarde peut progresser (commit d’instantané, activité zvol, etc.). Cela ne garantit pas que c’est la sauvegarde, mais cela plaide contre « rien ne se passe ».

Décision : Si vous voyez des E/S régulières et pas d’erreurs, privilégiez l’attente plutôt que l’intervention forcée.

Tâche 12 : Vérifier si les métadonnées d’instantané Proxmox existent

cr0x@server:~$ qm listsnapshot 101
`-> pre-backup-2025-12-26 2025-12-26 01:12:10

Ce que cela signifie : Un instantané existe. Les sauvegardes en mode instantané créent souvent un instantané puis le suppriment/committent ensuite.

Décision : Si la sauvegarde est bloquée et que l’instantané reste, vous devrez gérer le nettoyage de l’instantané avec précaution après avoir arrêté la tâche.

Tâche 13 : Chercher le verrou dans le fichier de configuration de la VM (n’éditez pas encore, observez seulement)

cr0x@server:~$ grep -n '^lock:' /etc/pve/qemu-server/101.conf
7:lock: backup

Ce que cela signifie : Le verrou est enregistré dans l’état de configuration.

Décision : Préférez qm unlock 101 plutôt que des modifications manuelles du fichier. Les modifications manuelles servent quand pmxcfs est cassé ou que vous êtes en mode incident avec un enregistrement de changement.

Tâche 14 : Annuler proprement une tâche en cours (quand c’est sûr et nécessaire)

Si le job est vraiment bloqué et que l’activité métier exige une intervention, vous pouvez arrêter la tâche. Essayez d’abord une terminaison douce.

cr0x@server:~$ kill -TERM 41233
cr0x@server:~$ sleep 2
cr0x@server:~$ ps -p 41233 -o pid,stat,cmd
  PID STAT CMD
41233 D    vzdump 101 --storage backup-nfs --mode snapshot --compress zstd

Ce que cela signifie : Toujours en état D ; il ne peut pas gérer les signaux parce qu’il est bloqué sur des I/O.

Décision : N’escaladez pas vers kill -9 comme plan par défaut. Réparez la condition d’I/O (NFS down, chemin de stockage instable, Ceph bloqué, etc.) ou acceptez d’attendre.

Tâche 15 : Une fois la tâche terminée, supprimer le verrou de la manière supportée

cr0x@server:~$ qm unlock 101

Ce que cela signifie : La ligne de verrou devrait être supprimée de la config si aucun contrainte interne ne la bloque.

Décision : Re-vérifiez immédiatement la config et l’état des instantanés. Si des instantanés existent, gérez-les avant de déclarer victoire.

Tâche 16 : Confirmer que le verrou est supprimé et que les opérations VM fonctionnent à nouveau

cr0x@server:~$ qm config 101 | grep '^lock:' || echo "no lock set"
no lock set

Ce que cela signifie : Proxmox ne bloque plus les opérations à cause de ce verrou.

Décision : Validez la liste des instantanés, exécutez une petite opération (comme qm status, qm agent ping si disponible), et planifiez une nouvelle sauvegarde bientôt.

Pièges spécifiques au stockage (ZFS, LVM-thin, Ceph RBD, NFS)

ZFS : « La création d’instantané a été instantanée ; la suppression prend une éternité »

Les instantanés ZFS sont des références de métadonnées. Les créer est généralement instantané. Les supprimer peut nécessiter de libérer beaucoup de blocs, surtout si la VM a beaucoup écrit après l’instantané. Ce « backup bloqué » peut être dans la phase de nettoyage de l’instantané.

Que faire : confirmez les E/S, confirmez la présence de l’instantané, et ne déverrouillez qu’après avoir arrêté la tâche et vérifié qu’aucun zfs send/receive ou snapshot destroy n’est en cours.

LVM-thin : merges et épuisement des métadonnées

Les instantanés et merges de LVM-thin sont d’une nature différente. Si le thin pool manque de métadonnées, les merges peuvent ramper ou échouer. Vous pouvez obtenir un verrou qui semble sans rapport avec le vrai problème.

Que faire : vérifiez l’utilisation du thin pool et les métadonnées avant d’entreprendre des actions qui forcent des merges. Si les métadonnées sont insuffisantes, la bonne action peut être « étendre les métadonnées du thin pool » et laisser l’opération se terminer.

Ceph RBD : les verrous ne sont pas les seuls verrous

Ceph a ses propres concepts de watch/lock, plus des opérations d’instantané et de flatten RBD. Proxmox peut être bloqué parce que Ceph est lent ou parce qu’une opération RBD est en attente sur le cluster.

Que faire : vérifiez l’état RBD et surveillez les opérations bloquées. Un déverrouillage Proxmox ne cancel pas une opération Ceph.

Cible de sauvegarde NFS : votre sauvegarde dépend de votre montage

Un mode d’échec courant : un hic NFS. Le processus vzdump entre en état D, Proxmox maintient le verrou, et votre GUI affiche une tâche « running » pour toujours. Le nœud peut sembler sain. Il ne l’est pas.

Que faire : traitez le montage NFS comme une dépendance. Vérifiez les stats de montage, recherchez des timeouts serveur, et soyez prêt à résoudre le chemin de stockage plutôt que « réparer Proxmox ».

Trois mini-histoires d’entreprise depuis les tranchées des verrous

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

L’équipe avait une croyance rassurante : « Si l’interface Proxmox n’affiche pas de tâche en cours, rien n’exécute. » Ce n’était pas une hypothèse déraisonnable — jusqu’à ce qu’ils rencontrent un nœud avec une latence pmxcfs intermittente pendant une matinée chargée.

Une VM était verrouillée « (snapshot) ». L’ingénieur d’astreinte a consulté la liste des tâches dans la GUI, n’a rien vu d’évident, et a exécuté qm unlock. La VM a démarré, ce qui semblait une victoire. Puis ils ont supprimé un instantané qui « devait être vieux ».

Ce qui se passait réellement : un commit d’instantané était toujours en cours côté stockage. La vue de gestion ne le reflétait pas clairement parce que le worker qui l’avait lancé était mort, et le système de fichiers du cluster était lent à mettre à jour l’état de la tâche. La suppression a fait course avec le commit, et le disque VM s’est retrouvé avec des métadonnées d’instantané incohérentes dans Proxmox et un état à moitié fini sur le stockage.

Le test de restauration suivant a échoué d’une manière douloureusement subtile : la VM a démarré, mais les données applicatives étaient incohérentes entre les tables. Pas de corruption évidente. Juste du « faux ». Cela a pris plus de temps à détecter qu’à provoquer.

La correction durable a été culturelle : le runbook est passé de « déverrouille si la GUI est silencieuse » à « déverrouille seulement après avoir prouvé que le worker est parti et que le stockage n’est pas en cours d’opération ». Ils ont aussi pris l’habitude de vérifier les tâches via CLI et de consulter la liste des instantanés avant toute action destructive.

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

Une équipe plateforme voulait des sauvegardes plus rapides. Ils sont passés des sauvegardes en mode arrêt aux sauvegardes en mode instantané partout, ont activé la compression, et ont lancé tous les jobs en même temps « pour finir avant les heures d’ouverture ». Sur le papier c’était propre : moins d’indisponibilité, sauvegardes plus rapides, équipes plus heureuses.

En réalité, les sauvegardes en mode instantané ont déplacé la charge, pas l’ont éliminée. La fenêtre de sauvegarde martelait maintenant le stockage et le réseau simultanément. Les pires matins, la latence Ceph a grimpé, des guest agents ont gelé sur quelques VMs, et plusieurs sauvegardes se sont arrêtées en plein nettoyage d’instantané.

À 9 h, une poignée de VMs étaient verrouillées. La réaction instinctive a été de les déverrouiller pour que les équipes puissent déployer. Ce « correctif » a fonctionné — jusqu’à ce que le système de sauvegarde commence à signaler des archives inutilisables parce que la chaîne d’instantanés était un désordre.

La partie qui a échoué n’était pas le mode instantané lui-même. C’était la concurrence. Ils traitaient les sauvegardes comme des jobs CPU alors que ce sont des jobs de stockage. Après avoir échelonné les plannings, limité le parallélisme par backend de stockage, et défini des timeouts/alertes explicites pour « verrou plus vieux que X », les incidents de verrou ont presque disparu.

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

Un environnement proche de la finance avait exactement une vertu : la discipline. Chaque changement nécessitait un ticket. Chaque ticket nécessitait une pré-vérification. Et chaque pré-vérification nécessitait la vérification des sauvegardes et de l’état des instantanés.

Un jour, une VM affichait « locked (backup) ». L’ingénieur d’astreinte ne l’a pas déverrouillée. Il a ouvert le journal de tâche, a vu une sauvegarde bloquée en état D, et a escaladé vers le stockage. Le stockage a trouvé un serveur NFS en train d’exécuter une mise à jour du noyau avec un plan de reboot un peu trop optimiste.

Une fois NFS revenu, le processus vzdump a fini, le verrou s’est libéré automatiquement, et l’instantané a disparu comme prévu. Aucun déverrouillage manuel nécessaire. La fenêtre de changement a bougé, les gens ont râlé, et les données VM sont restées intactes.

Cette histoire ne semble pas héroïque parce qu’elle ne l’est pas. C’est ce que vous voulez : des opérations ennuyeuses et reproductibles qui vous protègent de votre propre urgence.

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

Plan A : Le défaut sûr (la plupart des cas)

1. Identifier le verrou : qm config <vmid> | grep '^lock:'
2. Trouver la tâche : interrogez les tâches récentes sur le nœud ; localisez l’UPID pour vzdump/snapshot/migrate/replicate.
3. Lire le journal de la tâche : s’il journalise encore et progresse, attendez.
4. Valider l’état du processus : confirmez s’il existe un worker ; vérifiez l’état D.
5. Valider la santé du stockage : contrôles ZFS/Ceph/LVM/NFS selon le backend.
6. Si en progression : attendez et communiquez.
7. Si bloqué à cause d’une dépendance : réparez la dépendance (stockage/réseau), pas le verrou.
8. Si la tâche est morte et le stockage stable : déverrouillez avec qm unlock.
9. Validation post-déverrouillage : vérifiez les instantanés ; démarrez la VM ; exécutez une petite validation I/O ; planifiez une nouvelle sauvegarde.

Plan B : Vous devez intervenir (job bloqué, impact métier)

1. Confirmez que la VM n’est pas en pleine migration/réplication. Si oui, arrêtez et réévaluez.
2. Confirmez qu’aucun processus de sauvegarde n’écrit activement la sortie (croissance des fichiers temporaires, bande passante stockage).
3. Essayez une annulation/terminaison douce du process worker ou de la tâche (pas kill -9 d’abord).
4. Si le process est en état D : réparez le chemin I/O. Le kill ne fonctionnera pas tant que l’appel noyau ne se termine pas.
5. Après la disparition du worker et la stabilisation du stockage, déverrouillez avec qm unlock <vmid>.
6. Nettoyez les artefacts d’instantané (supprimez les instantanés restants uniquement après vous être assuré qu’aucun merge/commit n’est en cours).
7. Documentez ce qui s’est passé. Vous oublierez les détails plus vite que vous ne le pensez.

Plan C : pmxcfs ou l’état du cluster est cassé (rare, épicé)

1. Confirmez le quorum du cluster et la santé de pmxcfs sur le nœud.
2. Évitez d’éditer /etc/pve/ directement sauf si vous comprenez le périmètre de dégâts.
3. Restaurez d’abord la santé du cluster. Si l’état de config ne peut pas être écrit, les commandes de déverrouillage peuvent « réussir » en esprit mais pas en réalité.
4. Une fois pmxcfs stable, relancez le flux de travail normal.

Blague #2 : « Juste déverrouiller » est l’équivalent virtualisé de « juste redémarrer prod » — parfois correct, souvent mauvais pour la carrière.

Erreurs courantes : symptôme → cause racine → correctif

1) « Le verrou ne se supprime pas, mais la sauvegarde semble terminée »

Symptôme : l’archive vzdump existe ; l’interface affiche toujours verrouillé (backup).

Cause racine : la tâche a échoué pendant le nettoyage ou les étapes post-backup ; la ligne de verrou n’a pas été supprimée à cause d’un plantage du worker ou d’un échec d’écriture pmxcfs.

Correctif : vérifiez qu’aucun job n’est en cours ; confirmez que la liste des instantanés est propre ; exécutez qm unlock ; puis validez les sauvegardes avec un test de restauration (pas seulement « le fichier existe »).

2) « Je l’ai déverrouillée, maintenant les instantanés ne se suppriment plus »

Symptôme : la suppression d’un instantané échoue ou bloque ; Proxmox montre un arbre d’instantanés incohérent.

Cause racine : vous avez déverrouillé alors qu’un commit/merge côté stockage était encore en cours, ou vous avez laissé des instantanés de stockage que Proxmox ne suit plus proprement.

Correctif : revérifiez les opérations de stockage ; pour ZFS, listez les instantanés et évaluez si un destroy est en cours ; pour Ceph, vérifiez l’état/les opérations RBD ; seulement alors supprimez ou réconciliez les instantanés.

3) « La tâche de sauvegarde tourne depuis toujours et ne peut pas être tuée »

Symptôme : le processus est en état D ; les signaux ne fonctionnent pas.

Cause racine : I/O bloqué (NFS serveur inaccessible, problème de chemin disque, Ceph bloqué, ou noyau en attente sur le stockage).

Correctif : réparez la dépendance I/O. Si NFS, restaurez la connectivité ou remontez après stabilisation ; si Ceph, réparez la santé du cluster ; si disques locaux, vérifiez le matériel et dmesg. Puis laissez le processus revenir et se terminer.

4) « VM verrouillée (snapshot) après un freeze du guest-agent »

Symptôme : l’opération d’instantané a démarré ; la VM reste verrouillée ; l’invité semble gelé.

Cause racine : le guest agent QEMU n’a pas répondu au thaw, ou le freeze a expiré en plein workflow.

Correctif : vérifiez l’état de l’agent dans la VM et sur Proxmox ; envisagez de désactiver le freeze de système de fichiers pour cette charge de travail ou de réparer le service agent ; ne déverrouillez qu’après avoir confirmé qu’aucun merge/commit d’instantané n’est en attente.

5) « Les verrous se répètent toutes les nuits à la même heure »

Symptôme : incidents de verrou récurrents pendant la fenêtre de sauvegarde.

Cause racine : trop de concurrence, saturation de la cible de sauvegarde, ou maintenance périodique du stockage en collision avec les sauvegardes.

Correctif : échelonnez les jobs, limitez la bande passante, réduisez les sauvegardes parallèles par nœud/stockage, et ajoutez des alertes pour les tâches dépassant la durée attendue.

6) « qm unlock marche, mais la GUI affiche toujours verrouillé »

Symptôme : le CLI renvoie un succès ; l’UI bloque encore les opérations.

Cause racine : délai de propagation pmxcfs/état du cluster ou cache de la GUI ; parfois vous avez déverrouillé sur un nœud non autoritatif durant un incident de cluster.

Correctif : vérifiez le fichier de config sur le système de fichiers de cluster, confirmez le quorum, et re-vérifiez depuis le nœud qui héberge la VM. Si le cluster est instable, réparez-le d’abord.

FAQ (vraies questions posées à 2 h du matin)

1) Est‑il toujours sûr d’exécuter qm unlock <vmid> ?

Non. C’est sûr quand le verrou est obsolète : aucun worker en cours, aucune opération de stockage en vol, et vous avez vérifié l’état des instantanés/sauvegardes. Sinon c’est de la roulette mieux habillée.

2) Quelle est la différence entre « locked (backup) » et « locked (snapshot) » ?

« backup » signifie généralement qu’un workflow de sauvegarde (souvent basé sur des instantanés) est actif. « snapshot » signifie habituellement qu’une opération d’instantané elle‑même est active (création/suppression/rollback). Les deux peuvent impliquer des instantanés côté stockage.

3) Puis‑je simplement supprimer la ligne lock: dans /etc/pve/qemu-server/<vmid>.conf ?

Vous pouvez, mais vous ne devriez pas sauf nécessité. Utilisez qm unlock pour que Proxmox fasse la bonne gestion interne. Les modifications manuelles servent quand les services de gestion sont cassés et que vous avez un plan d’incident.

4) La tâche indique « running » mais il n’y a aucun processus. Que faire ?

Supposez que le worker est mort. Vérifiez qu’aucune activité de stockage n’est en cours et regardez si des instantanés existent. S’il est vraiment mort et stable, déverrouillez puis nettoyez les instantanés prudemment.

5) Pourquoi un verrou de sauvegarde bloque‑t‑il un redémarrage ou arrêt ?

Parce que les sauvegardes en mode instantané dépendent d’un état disque cohérent, et un redémarrage/arrêt peut interrompre la création/validation d’un instantané. Proxmox bloque pour garder le workflow de stockage cohérent.

6) Comment savoir si une sauvegarde « progresse » ?

Vérifiez les journaux de la tâche pour une sortie continue, contrôlez la croissance des fichiers temporaires, et scrutez les statistiques d’I/O du stockage. Si tout reste plat longtemps et que vous voyez l’état D, suspectez un I/O bloqué.

7) Si je déverrouille, est‑ce que cela annulera la sauvegarde/instantané ?

Non. Déverrouiller ne fait que retirer la garde de Proxmox. Le processus sous‑jacent (s’il tourne encore) continuera, et les opérations de stockage peuvent toujours être en cours. C’est pour cela que déverrouiller tôt est dangereux.

8) Que faire après avoir déverrouillé un verrou obsolète ?

Validez la liste des instantanés (qm listsnapshot), assurez‑vous que la VM démarre, vérifiez la santé du stockage, et planifiez une nouvelle sauvegarde rapidement. Analysez aussi pourquoi la tâche s’est bloquée pour éviter une récidive.

9) Une perte de quorum de cluster peut‑elle causer des verrous bloqués ?

Oui. Si pmxcfs ne peut pas valider des mises à jour de config à cause du quorum ou d’un problème de système de fichiers, les tâches peuvent ne pas enregistrer correctement leur fin. Réparez la santé du cluster d’abord ; sinon vous combattrez des fantômes.

10) Quel est le contrôle rapide « je vais faire quelque chose de risqué » le plus rapide ?

Trouvez l’UPID, lisez son journal, et confirmez si un process lié existe. Si vous ne pouvez pas relier le verrou à une tâche morte, vous n’êtes pas prêt à déverrouiller.

Prochaines étapes applicables immédiatement

Quand Proxmox affiche « VM verrouillée (sauvegarde/snapshot) », traitez‑le comme un verrou de sécurité, pas comme une nuisance. Votre travail n’est pas d’effacer le message ; votre travail est de préserver la cohérence de l’état.

Faites ceci ensuite, dans l’ordre :

1. Opérationnalisez le plan de diagnostic rapide : journal de tâche → état du process → état du stockage.
2. Standardisez « quand le déverrouillage est autorisé » : pas de worker en cours, pas d’opérations de stockage en vol, liste d’instantanés comprise.
3. Réduisez les récurrences : échelonnez les sauvegardes, limitez le parallélisme par backend de stockage, et alertez sur les tâches dépassant la durée attendue.
4. Pratiquez des restaurations : la vraie mesure du succès d’une sauvegarde est un test de restauration, pas un fichier sur disque.

Une citation pour vous garder honnête — idée paraphrasée de Richard Cook (ingénierie de la résilience) : Le succès et l’échec viennent souvent du même travail quotidien ; la fiabilité est la façon dont vous gérez ce travail.