Proxmox « impossible d’obtenir le verrou exclusif » : qui retient la VM et comment la libérer

Ce qu’est réellement le verrou (et ce que ce n’est pas)

Proxmox VE (PVE) est un système multi-processus qui orchestre de la manière la moins glamour possible : des fichiers de verrou et des tâches sérialisées. C’est une bonne chose. Cela empêche deux opérations d’écraser la même configuration VM ou le même disque en même temps.

Quand vous voyez « impossible d’obtenir le verrou exclusif », PVE dit : « j’ai tenté de prendre le verrou pour cette VM, mais quelque chose d’autre l’a déjà. » Ce « quelque chose » peut être :

• une tâche légitime de longue durée (sauvegarde, snapshot, réplication, migration)
• une tâche morte qui n’a pas libéré le verrou (redémarrage du démon, crash du nœud, blocage du stockage)
• un gestionnaire HA ou un composant de cluster coordonnant l’accès
• un verrou au niveau du stockage (verrou Ceph RBD, verrou d’activation LVM, verrou de fichier NFS)
• un processus QEMU en cours qui possède encore l’état d’exécution de la VM même si l’interface semble confuse

Voici la partie qui déconcerte les gens : le verrou peut être sur la config de la VM, pas sur le processus VM. « Déverrouiller » peut vous permettre d’éditer la configuration pendant qu’une opération disque est toujours en cours. C’est ainsi que vous expliquerez plus tard pourquoi les disques de la VM ressemblent à de l’art moderne.

Une vérité sèche : un verrou est une étiquette d’avertissement. L’enlever ne rend pas le contenu sûr.

Deux catégories de verrous importent en pratique :

1. Verrous au niveau PVE (typiquement dans l’état de configuration VM). Ils bloquent les actions dans qm, l’UI et l’API.
2. Verrous au niveau stockage (Ceph RBD, ZFS « dataset busy », activation LVM, verrous NFS périmés). Ceux-ci peuvent bloquer QEMU, les snapshots ou les sauvegardes même si PVE semble « déverrouillé ».

Guide de diagnostic rapide

Si vous êtes d’astreinte et que vous voulez le chemin le plus court vers « c’est sûr à corriger », faites ceci dans l’ordre. L’idée est de localiser le goulot : s’agit-il d’une tâche normale, d’une tâche bloquée ou d’un stockage en panne.

Premier point : y a‑t‑il une tâche PVE active pour la VM ?

• Vérifiez l’historique des tâches pour l’ID de VM et cherchez des tâches « en cours ».
• Confirmez si une sauvegarde, un snapshot, une migration ou une réplication est active.
• Si oui : ne déverrouillez pas encore ; décidez d’attendre, d’annuler ou de tuer le worker.

Deuxième point : QEMU tourne‑t‑il encore (ou à moitié) ?

• Recherchez un processus kvm/qemu-system-x86_64 pour cet ID de VM.
• Vérifiez si QMP répond, ou si le processus est bloqué en attente d’E/S non interruptible (état D).
• Si QEMU est vivant : le « verrou » est souvent correct. Si QEMU est bloqué : le stockage est généralement le vrai coupable.

Troisième point : le stockage est‑il bloqué ?

• ZFS : vérifiez zpool status, la latence I/O, et les opérations zfs destroy/snapshot bloquées.
• Ceph : vérifiez la santé du cluster et les verrous/watchers RBD.
• NFS : cherchez des handles de fichier périmés et des points de montage bloqués.
• LVM : vérifiez l’activation des LV et toute commande lvchange/lvs bloquée.

Puis : seulement alors envisagez de libérer les verrous

Si aucune tâche n’est en cours, QEMU ne tourne pas (ou a disparu), et le stockage n’effectue aucune opération, alors libérer un verrou obsolète est généralement sûr.

Règle empirique : s’il y a la moindre chance qu’une opération disque soit en cours, considérez « déverrouiller » comme un incident, pas comme une solution.

Tâches et commandes : trouver le détenteur, prouver la cause, choisir la correction

Ci‑dessous des tâches pratiques que vous pouvez exécuter sur un nœud PVE. Chacune inclut : une commande, ce que signifie une sortie typique, et la décision à prendre.

Task 1: Identify the exact lock message and operation

cr0x@server:~$ qm start 101
cannot get exclusive lock on VM 101 (snapshot-delete)

Ce que cela signifie : le verrou n’est pas générique ; il précise quelle catégorie d’opération le détient (ici : snapshot-delete).

Décision : allez chercher des tâches de suppression de snapshot, pas seulement « un verrou quelconque ». Cela indique aussi une implication probable du stockage.

Task 2: Check VM config for a lock field

cr0x@server:~$ grep -E '^(lock|parent|snapname):' /etc/pve/qemu-server/101.conf
lock: snapshot-delete

Ce que cela signifie : PVE a enregistré un verrou dans la configuration de la VM elle‑même. C’est souvent un résidu d’une tâche interrompue.

Décision : ne supprimez pas cette ligne à l’aveugle. Confirmez d’abord si une tâche est encore en cours ou si le stockage travaille toujours.

Task 3: Find recent tasks mentioning the VM ID in the node logs

cr0x@server:~$ journalctl -u pvedaemon -u pveproxy -u pvestatd --since "2 hours ago" | grep -E 'vmid=101|VM 101|101.conf' | tail -n 30
Dec 26 01:41:10 server pvedaemon[2143]: starting task UPID:server:00002A1F:00014B77:676D1A46:vzdump:101:root@pam:
Dec 26 01:41:11 server pvedaemon[2143]: INFO: backup job started
Dec 26 01:55:44 server pvedaemon[2143]: ERROR: backup failed: storage 'nfs-backup' not online
Dec 26 01:55:44 server pvedaemon[2143]: TASK ERROR: job failed

Ce que cela signifie : vous avez une opération qui a échoué. Les échecs peuvent laisser des verrous selon l’endroit où l’échec s’est produit.

Décision : pivotez vers le sous‑système en échec (ici : le stockage de sauvegarde). Si le stockage est toujours hors ligne, déverrouiller n’aidera pas — vous échouerez d’une manière plus créative ensuite.

Task 4: List running tasks and filter for the VM

cr0x@server:~$ pvesh get /nodes/server/tasks --running 1 | grep -E 'vzdump|qm|vmid.?101' || true
UPID:server:00002A1F:00014B77:676D1A46:vzdump:101:root@pam:

Ce que cela signifie : une tâche est encore marquée comme en cours. Elle peut réellement tourner, être bloquée, ou simplement ne pas avoir été nettoyée.

Décision : inspectez cet UPID et décidez d’attendre, d’annuler ou de tuer le processus worker.

Task 5: Inspect a task’s status (and see if it’s truly alive)

cr0x@server:~$ pvesh get /nodes/server/tasks/UPID:server:00002A1F:00014B77:676D1A46:vzdump:101:root@pam:/status
{"exitstatus":null,"id":"UPID:server:00002A1F:00014B77:676D1A46:vzdump:101:root@pam:","node":"server","pid":10783,"starttime":1735177270,"status":"running","type":"vzdump","upid":"UPID:server:00002A1F:00014B77:676D1A46:vzdump:101:root@pam:","user":"root@pam"}

Ce que cela signifie : PVE pense que le PID 10783 est toujours en cours et conserve donc le verrou valide.

Décision : vérifiez que le PID existe et n’est pas bloqué en attente d’E/S pour toujours.

Task 6: Verify the task PID exists and see what it’s doing

cr0x@server:~$ ps -o pid,ppid,stat,etime,cmd -p 10783
  PID  PPID STAT     ELAPSED CMD
10783  2143 D+     00:14:28 /usr/bin/vzdump 101 --storage nfs-backup --mode snapshot

Ce que cela signifie : l’état D signifie sommeil non interruptible, généralement bloqué sur des E/S. Le tuer peut ne pas marcher tant que l’E/S ne revient pas.

Décision : cessez de traiter cela comme « un problème de verrou Proxmox ». C’est un problème de stockage ou de réseau. Allez à la section de débogage du stockage avant de tuer quoi que ce soit.

Task 7: Check if QEMU is still running for that VM

cr0x@server:~$ pgrep -a -f "qemu-system-x86_64.*-id 101"
24591 /usr/bin/kvm -id 101 -name vm101,debug-threads=on -m 8192 ...

Ce que cela signifie : le runtime de la VM est actif. Même si le verrou de config semble obsolète, le processus VM peut être en train de réaliser un snapshot ou avoir des périphériques attachés.

Décision : ne faites pas qm unlock en premier. Déterminez si la VM est saine et quelle action est bloquée.

Task 8: Ask Proxmox what it thinks the VM status is

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

Ce que cela signifie : PVE la considère toujours comme « running ». Cela bloque généralement certaines opérations exclusives (comme la suppression de snapshot) par conception.

Décision : si votre objectif est « démarrer la VM », vous poursuivez la mauvaise piste. Si votre objectif est « supprimer un snapshot », vous devez résoudre la tâche de snapshot, pas le runtime VM.

Task 9: Review snapshot tree and identify the stuck snapshot name

cr0x@server:~$ qm listsnapshot 101
`-> current
   `-> pre-upgrade-2024-12-01
   `-> vzdump

Ce que cela signifie : les noms de snapshot comptent. Les snapshots « vzdump » sont souvent laissés par des échecs de sauvegarde.

Décision : si un snapshot « vzdump » est présent et que les sauvegardes échouent, corrigez d’abord le stockage de sauvegarde, puis supprimez proprement le snapshot.

Task 10: Try a graceful task cancellation (when appropriate)

cr0x@server:~$ pvesh create /nodes/server/tasks/UPID:server:00002A1F:00014B77:676D1A46:vzdump:101:root@pam:/stop
{"data":null}

Ce que cela signifie : vous avez demandé l’arrêt. Il peut toujours rester bloqué si le processus est en état D.

Décision : s’il s’arrête rapidement, tant mieux. Sinon, le débogage du stockage est obligatoire. Évitez d’envoyer un SIGKILL sans comprendre sur quoi il est bloqué.

Task 11: When there’s no running task, safely unlock at the PVE layer

cr0x@server:~$ qm unlock 101

Ce que cela signifie : cela a supprimé l’entrée lock: du fichier de config VM. Cela ne règle pas les verrous de stockage ni les processus QEMU bloqués.

Décision : ne le faites qu’après avoir confirmé qu’aucune opération n’est active. Après le déverrouillage, retentez l’action bloquée et surveillez les logs.

Task 12: Check storage availability in PVE (the boring “is it even mounted?” check)

cr0x@server:~$ pvesm status
Name         Type     Status     Total     Used     Available
local        dir      active    98.00GB   12.40GB     85.60GB
nfs-backup   nfs      inactive       0B        0B          0B
rbd-ceph     rbd      active     3.00TB    1.90TB      1.10TB

Ce que cela signifie : le stockage de sauvegarde est inactif. Les tâches qui en dépendent peuvent se bloquer ou échouer et laisser des verrous.

Décision : rétablissez d’abord l’accessibilité du stockage. Si vous déverrouillez alors que le stockage est toujours down, la prochaine tentative de sauvegarde/snapshot va reverrouiller et retomber en panne.

Task 13: NFS-specific: check mount health and “stale file handle” risk

cr0x@server:~$ mount | grep nfs-backup
10.0.20.15:/export/pve-backup on /mnt/pve/nfs-backup type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)

cr0x@server:~$ timeout 3 ls -la /mnt/pve/nfs-backup | head
ls: cannot access '/mnt/pve/nfs-backup': Stale file handle

Ce que cela signifie : un montage NFS « hard » avec handle périmé peut bloquer des processus en état D. Cela inclut vzdump et le nettoyage de snapshots.

Décision : remédiez à la condition NFS (redémarrage du serveur/export, remount). Ne vous contentez pas de tuer la tâche en espérant. Elle coinçera à nouveau.

Task 14: Ceph-specific: check cluster health fast

cr0x@server:~$ ceph -s
  cluster:
    id:     0f3c6f1a-9f72-4a1f-9e35-7b4c9b2a1c0a
    health: HEALTH_WARN
            1 slow ops, oldest one blocked for 34 sec
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3
    mgr: active: mgr1
    osd: 6 osds: 6 up, 6 in
  data:
    pools:   4 pools, 256 pgs
    usage:   1.9 TiB used, 1.1 TiB / 3.0 TiB avail
    pgs:     256 active+clean

Ce que cela signifie : « slow ops » corrèle avec des snapshots/migrations bloqués et des timeouts de verrou parce que l’achèvement des I/O est retardé.

Décision : résolvez la lenteur de Ceph (réseau, OSD, backfill, recovery) avant de manipuler les verrous. Sinon vous accélérez simplement la boucle d’échec.

Task 15: Ceph RBD lock/watchers: see who’s attached

cr0x@server:~$ rbd status vm-101-disk-0 --pool rbd
Watchers:
    watcher=10.0.10.21:0/1689456502 client.48231 cookie=18446744073709551615

Ce que cela signifie : un client (probablement un nœud PVE) a encore le disque ouvert. Les snapshots ou opérations exclusives peuvent bloquer.

Décision : identifiez ce client et confirmez que QEMU s’est vraiment arrêté. Si c’est un nœud mort, vous devrez peut‑être effacer des attaches périmées au niveau du cluster — avec précaution.

Task 16: ZFS-specific: confirm pool health and look for long-running operations

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

cr0x@server:~$ zfs list -t snapshot | grep -E '^rpool/data/vm-101-disk-0@' | tail -n 5
rpool/data/vm-101-disk-0@vzdump                         2.10G  -  58.3G  -

Ce que cela signifie : le pool est sain ; un snapshot existe. Si la suppression est bloquée, c’est souvent une retenue, une dépendance de clone ou un stall I/O ailleurs.

Décision : vérifiez les clones/holds avant de forcer quoi que ce soit.

Task 17: ZFS holds: find the reason a snapshot won’t delete

cr0x@server:~$ zfs holds rpool/data/vm-101-disk-0@vzdump
NAME                               TAG                 TIMESTAMP
rpool/data/vm-101-disk-0@vzdump     pve-vzdump          Thu Dec 26 01:41 2025

Ce que cela signifie : il y a une retenue explicite. Proxmox (ou un script) l’a placée pour empêcher la suppression accidentelle pendant la sauvegarde.

Décision : retirez la retenue seulement si la tâche de sauvegarde est confirmée comme morte et que le snapshot est sûr à supprimer.

Task 18: Remove a ZFS hold (surgical, not casual)

cr0x@server:~$ zfs release pve-vzdump rpool/data/vm-101-disk-0@vzdump

Ce que cela signifie : vous avez enlevé le bloqueur qui empêchait la suppression. Maintenant la suppression du snapshot peut se poursuivre.

Décision : lancez immédiatement la suppression via Proxmox à nouveau (préférable) pour que l’état de PVE reste cohérent.

Task 19: Check who is locking /var/lock at OS level (rare but real)

cr0x@server:~$ ls -la /var/lock/qemu-server/
total 0
-rw-r----- 1 root root 0 Dec 26 01:41 lock-101.conf

cr0x@server:~$ lsof /var/lock/qemu-server/lock-101.conf || true
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pvedaemon 2143 root    8u   REG  0,53        0  512 /var/lock/qemu-server/lock-101.conf

Ce que cela signifie : le démon lui‑même tient le descripteur de fichier. Cela peut arriver pendant des opérations légitimes — ou quand le démon est bloqué.

Décision : si pvedaemon est englué (et les tâches bloquées), un redémarrage contrôlé peut être approprié, mais seulement après avoir compris sur quoi il attend.

Task 20: Restart the management daemons (last resort, but sometimes correct)

cr0x@server:~$ systemctl restart pvedaemon pveproxy pvestatd

Ce que cela signifie : vous avez redémarré le plan de contrôle. Cela peut effacer des verrous obsolètes et la tenue des tâches. Cela ne débloquera pas un I/O noyau bloqué.

Décision : faites‑le quand : (1) vous avez confirmé que QEMU et le stockage sont OK, (2) les tâches sont fantômes, et (3) l’état HA/cluster est stable. Sinon vous redémarrez le tableau de bord alors que le moteur est en feu.

Blague #1 : Déverrouiller une VM sans vérifier le stockage, c’est comme éteindre l’alarme incendie parce qu’elle fait du bruit. Le bruit s’arrête ; le problème, lui, reste.

Types de verrou dans Proxmox : ce que chacun signifie en général

La chaîne de raison du verrou (la partie entre parenthèses) est votre indice. Traitez‑la comme une hypothèse de départ, pas comme un verdict.

backup / vzdump

Signification habituelle : une tâche de sauvegarde est en cours ou a planté en cours de route, laissant souvent un snapshot derrière (surtout sur ZFS/Ceph).

Causes sous‑jacentes courantes : cible de sauvegarde hors ligne, NFS handle périmé, datastore PBS indisponible, stockage lent.

Que faire : vérifier les tâches, puis la santé de la cible de sauvegarde, ensuite les snapshots.

snapshot / snapshot-delete

Signification habituelle : création/suppression de snapshot en cours, ou une tentative précédente est morte après avoir posé l’état.

Causes sous‑jacentes courantes : retenues ZFS, opérations Ceph lentes, watchers RBD toujours attachés, I/O en attente.

Que faire : inspecter la liste de snapshots, l’état du backend de stockage et les éventuels holds/watchers.

clone

Signification habituelle : un clonage depuis un template est en cours ou partiellement achevé.

Causes sous‑jacentes courantes : copie/clone de stockage bloquée, latence du stockage en réseau, espace insuffisant.

Que faire : confirmer la tâche de clone, vérifier l’espace et la santé du backend, éviter les modifications manuelles de la config disque tant que le clone est actif.

migrate

Signification habituelle : une migration est en cours ou a échoué sans nettoyage.

Causes sous‑jacentes courantes : nœud cible injoignable, interruptions SSH, problèmes de stockage partagé, interventions HA.

Que faire : trouver l’UPID de migration, vérifier la vision de la VM sur les deux nœuds, et confirmer que les disques ne sont pas actifs des deux côtés.

rollback

Signification habituelle : un rollback de snapshot est en cours, ce qui est intrinsèquement exclusif.

Causes sous‑jacentes courantes : rollback démarré et la VM forcée hors ligne, stockage en difficulté, ou rollback échoué laissant l’état.

Que faire : traiter comme à haut risque. Confirmez la consistance des disques et ne déverrouillez pas à la légère.

Modes de défaillance spécifiques au stockage (ZFS, Ceph, LVM, NFS, iSCSI)

La plupart des tickets « verrou exclusif » sont des tickets stockage déguisés en virtualisation.

ZFS: “dataset busy”, holds, and silent dependencies

ZFS est excellent pour les snapshots. Il est aussi excellent pour vous empêcher de vous tirer une balle dans le pied. Quand la suppression d’un snapshot est bloquée, c’est souvent à cause de :

• des retenues (holds) placées par les outils de sauvegarde (pour empêcher la suppression en cours de sauvegarde)
• des clones dépendant du snapshot
• des datasets occupés à cause de montages ou de processus tenant des références
• de la détresse du pool (latence, périphérique défaillant) rendant les opérations interminables

Ce qu’il faut éviter : détruire manuellement des snapshots sans passer par Proxmox pendant qu’il pense qu’une opération est en cours. Préférez qm delsnapshot après avoir levé le bloqueur ; cela maintient la cohérence des métadonnées Proxmox.

Ceph RBD: watchers, exclusive locks, and “slow ops”

Ceph a son propre concept de qui est attaché à une image RBD. Même si PVE retire un verrou de config, l’image peut être toujours ouverte par une instance QEMU quelque part.

Si un nœud a planté, vous pouvez avoir des « attachments fantômes » : le cluster croit toujours qu’un client détient l’image. Vous verrez des watchers, et vos actions de snapshot/suppression se bloqueront ou échoueront.

Dans les incidents Ceph, l’erreur de verrou est souvent le premier symptôme visible d’une condition plus profonde : recovery/backfill saturant les disques, perte de paquets réseau, ou OSDs instables. Réparer la santé Ceph est fréquemment le déverrouillage le plus rapide.

LVM-thin: activation locks and stuck lvchange

LVM-thin est fiable jusqu’à ce que vous manquiez de métadonnées ou que le VG soit occupé entre nœuds d’une manière inattendue. Si lvs se bloque, vous êtes dans la même catégorie que les problèmes de montage NFS « hard » : des processus bloqués en I/O noyau, pas des échecs userland polis.

NFS: hard mounts, stale handles, and why your kill -9 didn’t work

NFS est un bon choix pour les sauvegardes. C’est aussi une masterclass sur les compromis des systèmes distribués. Avec un montage hard, les processus attendront indéfiniment que le serveur réponde. C’est de la « fiabilité » dans un sens, et « mon cluster est collé à un export mort » dans un autre.

Quand NFS renvoie Stale file handle, vous regardez généralement un événement serveur (reboot, failover, remount, changement d’export). Les processus clients peuvent se bloquer. Les verrous restent « tenus » parce que les tâches ne sortent jamais.

iSCSI / multipath: path loss and D-state QEMU

Les problèmes de chemin de stockage bloc aiment apparaître comme des problèmes de verrou parce que QEMU peut bloquer sur des I/O. Le plan de gestion se bloque ensuite en attendant QEMU ou la fin du stockage. Si vous voyez QEMU en état D, pensez multipath ou SAN avant de penser « bug Proxmox ».

Blague #2 : Les pannes de stockage sont généreuses — elles partagent leur douleur avec toutes les couches au‑dessus, gratuitement.

Trois mini-récits du monde entreprise (comment ça foire en vrai)

Mini-récit 1 : L’incident causé par une fausse hypothèse

L’équipe avait un petit cluster avec Ceph RBD partagé. Un nœud a redémarré pendant une fenêtre de maintenance, et après une VM ne pouvait plus migrer. L’UI affichait « impossible d’obtenir le verrou exclusif », donc l’astreinte a supposé que Proxmox était trop prudent et a lancé qm unlock.

La migration a quand même échoué. Maintenant la config était éditable, donc ils l’ont « corrigée » en détachant et réattachant le disque dans la config VM. Cela a créé un état de config propre en apparence mais désynchronisé de la réalité : l’ancien RBD avait encore un watcher, et les nouvelles tentatives d’attachement ont accumulé des erreurs.

Ils ont passé deux heures à « retenter » et redémarrer des démons, parce que tout le monde aime un rituel quand la cause racine est floue. La vraie cause était visible en quelques minutes : Ceph avait des slow ops et l’image RBD était toujours regardée par un ID client issu du redémarrage du nœud.

Ce qui a changé l’issue n’a pas été une commande maligne. Ce fut la décision d’arrêter de traiter le verrou comme le problème et de le considérer comme une preuve. Une fois Ceph revenu et l’attachement périmé résolu, l’erreur de verrou a disparu sans héroïsme.

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

Une autre entreprise voulait des sauvegardes plus rapides. Quelqu’un a optimisé les montages NFS pour le débit et a mis de grands blocs de lecture/écriture et des réglages agressifs. C’était rapide. Les bons jours.

Puis le serveur NFS a eu un bref événement de bascule. Le montage était hard, ce qui se défend, mais ils n’avaient pas prévu la réalité opérationnelle : les processus de sauvegarde sont passés en sommeil non interruptible en attendant les E/S. Ces tâches tenaient des verrous VM, le nettoyage des snapshots a stagné, et les sauvegardes du lendemain se sont heurtées aux restes d’hier.

À la mi‑journée, plusieurs VMs étaient « verrouillées », et l’équipe stockage se faisait demander pourquoi la virtualisation ne pouvait pas « simplement les déverrouiller ». Ils pouvaient déverrouiller. Ils pouvaient aussi aggraver la prolifération des snapshots en laissant de nouveaux snapshots s’empiler sur une chaîne déjà ratée.

La correction finale n’a pas été de revenir entièrement sur l’optimisation. Ce fut d’ajouter des garde‑fous : surveillance des montages bloqués, isolation du trafic de sauvegarde et s’assurer que l’outil de sauvegarde échoue vite pour libérer les verrous quand le backend est malade.

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

Une organisation financière avait un contrôle des changements strict et, plus important, des habitudes strictes. Ils planifiaient les suppressions de snapshot et les sauvegardes dans des fenêtres claires, et ils avaient une règle : pas de déverrouillages manuels tant que trois vérifications n’étaient pas faites — liste des tâches, état du processus QEMU et santé du stockage.

Une nuit une suppression de snapshot s’est bloquée après qu’un nœud a perdu la connectivité à la cible de sauvegarde. L’astreinte a vu l’erreur de verrou et a suivi la checklist. Les tâches montraient un vzdump en cours avec un PID en état D. L’état du stockage montrait le montage NFS inactif.

Ils ont fait la chose la moins excitante possible : restaurer l’export NFS, remonter proprement, attendre que la tâche coincée se termine, puis relancer la suppression de snapshot via Proxmox. Aucun qm unlock n’était nécessaire. La VM n’a jamais été exposée à un risque additionnel.

C’était si ennuyeux que ça n’avait presque pas l’air d’un succès. C’est le but. Leur pratique a empêché une cascade : pas de déverrouillage forcé, pas d’éditions de config, pas de snapshots partiels laissés derrière, pas de ticket de suivi « pourquoi la chaîne de sauvegarde est cassée ».

Erreurs courantes : symptôme → cause racine → correction

1) « Cannot get exclusive lock (backup) » et vous lancez immédiatement qm unlock

Symptôme : sauvegardes qui échouent, VM verrouillée, et snapshots nommés « vzdump » qui s’accumulent.

Cause racine : cible de sauvegarde hors ligne ou bloquée (NFS/PBS), laissant des tâches vzdump coincées ou échouées en plein snapshot.

Correction : restaurez la connectivité de la cible de sauvegarde ; confirmez l’absence de tâches en cours ; nettoyez les snapshots via Proxmox ; puis seulement déverrouillez si le verrou est obsolète.

2) Le verrou persiste après reboot du nœud

Symptôme : la VM apparaît verrouillée même si « rien ne tourne ».

Cause racine : champ lock: obsolète dans /etc/pve/qemu-server/*.conf issu d’une opération interrompue.

Correction : confirmez qu’aucune tâche ne tourne et qu’aucun processus QEMU n’existe ; ensuite qm unlock <vmid>.

3) Tuer le PID de la tâche ne supprime pas le verrou

Symptôme : vous envoyez SIGTERM/SIGKILL ; le processus reste ; le verrou reste.

Cause racine : le processus est en sommeil non interruptible (D) à cause d’un stall NFS/SAN/Ceph ; le noyau ne le tuera pas tant que l’I/O ne revient pas.

Correction : réparez le chemin stockage/réseau ; remontez NFS ou restaurez les chemins SAN ; ensuite la tâche pourra sortir et libérer les verrous.

4) Verrou de migration qui « ne part pas »

Symptôme : VM verrouillée avec (migrate), mais la migration a échoué des heures auparavant.

Cause racine : migration partiellement complétée laissant de l’état sur source/target ; possiblement VM enregistrée sur les deux nœuds ou disque actif sur la cible.

Correction : vérifiez l’emplacement du processus VM ; assurez‑vous que les disques ne sont pas actifs sur les deux nœuds ; nettoyez les artefacts de migration ; puis déverrouillez l’état obsolète.

5) Suppression de snapshot qui échoue à répétition sur ZFS

Symptôme : le verrou indique snapshot-delete ; la suppression échoue ; le snapshot reste.

Cause racine : retenue ZFS ou dépendance de clone empêche la suppression.

Correction : vérifications zfs holds et zfs get origin ; relâchez les holds seulement quand c’est sûr ; supprimez via Proxmox ensuite.

6) Erreurs de verrou Ceph RBD pendant stop/start

Symptôme : arrêt bloqué ; puis apparaissent des erreurs de « exclusive lock » sur les opérations.

Cause racine : slow ops Ceph ou watchers persistants ; QEMU toujours attaché ou cluster Ceph dégradé.

Correction : stabilisez Ceph (ceph -s) ; confirmez les watchers ; assurez‑vous que QEMU est arrêté proprement ; ensuite procédez.

7) Redémarrer pvedaemon « règle » le problème une fois, puis il revient

Symptôme : les verrous s’effacent brièvement après redémarrage du démon, mais de nouvelles tâches reverrouillent et échouent.

Cause racine : le problème de stockage sous‑jacent persiste ; la réinitialisation du plan de contrôle masque les symptômes.

Correction : arrêtez d’utiliser les redémarrages comme traitement ; instrumentez la santé du stockage ; réparez les montages/cluster d’abord.

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

Checklist A: « La VM est verrouillée et ne démarre pas »

1. Capturez la chaîne d’erreur exacte (type d’opération).
2. Vérifiez le verrou dans la config : grep '^lock:' /etc/pve/qemu-server/<vmid>.conf.
3. Vérifiez les tâches en cours pour la VM : pvesh get /nodes/<node>/tasks --running 1.
4. Si une tâche tourne : inspectez son PID et son état (ps) ; si D, passez par le stockage d’abord.
5. Vérifiez si QEMU tourne déjà : pgrep -a -f "-id <vmid>".
6. Vérifiez l’état du stockage dans PVE : pvesm status.
7. Vérifiez la santé du backend (ZFS/Ceph/NFS) selon l’emplacement des disques/sauvegardes.
8. Uniquement si aucune tâche et aucun QEMU et si le stockage est stable : qm unlock <vmid> et retentez le démarrage.

Checklist B: « Verrou de suppression de snapshot »

1. Listez les snapshots : qm listsnapshot <vmid> et identifiez la cible.
2. Vérifiez la présence de tâches de sauvegarde en cours : vzdump en cours laisse souvent des verrous snapshot-delete.
3. ZFS : vérifiez les holds : zfs holds <dataset>@<snap>.
4. Ceph : vérifiez les watchers : rbd status <image> --pool <pool>.
5. Corrigez le bloqueur backend (holds/watchers/slow ops).
6. Supprimez le snapshot via Proxmox à nouveau (préférable) : qm delsnapshot <vmid> <snapname>.
7. Si Proxmox affiche encore un verrou obsolète et que rien n’est actif : qm unlock <vmid>.

Checklist C: « Verrou de sauvegarde »

1. Confirmez que la cible de sauvegarde est joignable et active : pvesm status.
2. NFS : validez que le montage répond : timeout 3 ls /mnt/pve/<storage>.
3. PBS : vérifiez la connectivité du datastore (côté PVE) et l’authentification.
4. Inspectez l’état de la tâche vzdump et le statut du PID.
5. Résolvez le problème de stockage, laissez la tâche échouer/sortir proprement ou arrêtez‑la si elle peut s’arrêter.
6. Nettoyez les snapshots « vzdump » restants si présents.
7. Relancez une sauvegarde manuelle de validation avant de réactiver les plannings.

Checklist D: « Quand il est réellement sûr d’utiliser qm unlock »

• Aucune tâche en cours ne référence l’ID VM.
• Aucun processus QEMU n’existe pour cet ID VM.
• Le backend de stockage est sain et réactif.
• Aucune opération de snapshot n’est en cours au niveau backend.
• Vous comprenez quelle opération a posé le verrou, et vous acceptez les conséquences du déverrouillage.

Faits intéressants & contexte historique

• Proxmox VE provient d’une culture d’opérations Linux pragmatique : configurations basées fichiers et verrouillage simple sont intentionnels car inspectables sous pression.
• /etc/pve n’est pas un système de fichiers normal : c’est un système de fichiers de cluster (pmxcfs). « Un verrou dans la config » est un état partagé de cluster, pas juste du texte local.
• Le verrouillage est devenu prioritaire à mesure que les clusters ont mûri : la virtualisation sur un seul nœud pouvait « improviser » ; l’orchestration clusterisée ne peut pas.
• La sémantique des snapshots dépend du backend : les snapshots ZFS se comportent différemment des snapshots Ceph RBD, et Proxmox doit en rendre compte dans une seule interface.
• Les montages NFS hard sont un compromis délibéré : ils empêchent la corruption silencieuse des données au prix de « tout se fige quand le serveur disparaît ».
• Les « watchers » de Ceph sont un cadeau de visibilité : ils vous montrent quels clients ont une image ouverte, ce qui explique souvent les échecs de verrou exclusif sans conjecture.
• Le sommeil non interruptible (état D) est une fonctionnalité Linux, pas un bug : c’est le noyau qui refuse de tuer des processus en attente d’un I/O critique.
• HA ajoute une couche de verrou supplémentaire : en HA, une VM peut être « tenue » par la décision du gestionnaire, même si des humains veulent intervenir.

Une maxime opérations (idée paraphrasée) : « L’espoir n’est pas une stratégie », souvent citée en SRE. Traitez les erreurs de verrou de la même façon : vérifiez, puis agissez.

FAQ

1) Que signifie « impossible d’obtenir le verrou exclusif » dans Proxmox ?

Cela signifie que Proxmox a tenté une opération nécessitant un accès exclusif à la config/état de la VM (ou une opération liée) mais a détecté un verrou existant. Le verrou est généralement enregistré dans la config VM (lock:) et/ou tenu par une tâche en cours.

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

Sûr quand le verrou est obsolète : aucune tâche en cours, aucun processus QEMU, et le stockage backend est sain. Dangereux quand une sauvegarde/snapshot/migration est réellement en cours ou bloquée en I/O — le déverrouillage peut vous permettre d’exécuter des opérations conflictuelles.

3) Pourquoi le verrou mentionne « snapshot-delete » alors que j’essaie juste de démarrer la VM ?

Parce que la VM est verrouillée pour une opération de suppression de snapshot en attente ou bloquée, et Proxmox bloque d’autres actions pour éviter un état incohérent. Votre requête de « démarrage » est un dommage collatéral.

4) J’ai tué le processus de sauvegarde mais le verrou est toujours là. Pourquoi ?

Soit le processus n’est pas réellement mort (commun en état D), soit Proxmox a enregistré le verrou dans la config VM et il n’a pas été nettoyé. Confirmez via les listes de tâches et l’état des processus ; puis déverrouillez seulement après avoir vérifié que le stockage ne travaille plus.

5) Quelle est la façon la plus rapide de trouver qui tient le verrou ?

Vérifiez (a) les tâches en cours via pvesh, (b) journalctl pour la dernière tâche touchant la VM, et (c) si QEMU est en cours. Ensuite vérifiez les indicateurs backend : watchers Ceph, holds ZFS, réactivité du montage NFS.

6) L’HA peut‑elle causer un problème de verrou exclusif ?

Oui. Les ressources gérées par HA peuvent être démarrées/arrêtées/migrées par le gestionnaire HA, et des échecs peuvent laisser des opérations « en cours ». Confirmez toujours l’état HA et où la VM est supposée tourner avant d’intervenir manuellement.

7) Pourquoi des problèmes NFS apparaissent comme des verrous VM ?

Parce que les tâches de sauvegarde/snapshot dépendent de la lecture/écriture sur NFS. Avec des montages hard, ces tâches peuvent se bloquer indéfiniment dans le noyau. Proxmox conserve le verrou parce que la tâche ne se termine jamais.

8) L’UI n’affiche aucune tâche en cours, mais le verrou persiste. Et maintenant ?

Regardez directement la config VM pour lock:, et vérifiez les logs pour des échecs antérieurs. Puis inspectez les fichiers de verrou au niveau OS et la santé des démons. Si tout est vraiment inactif, un déverrouillage est raisonnable.

9) Si Ceph est en HEALTH_WARN, dois‑je déverrouiller pour relancer les choses ?

Généralement non. HEALTH_WARN avec slow ops signifie souvent que les I/O sont retardées ; déverrouiller ne fera pas terminer les opérations sous‑jacentes. Stabilisez Ceph d’abord, sinon vous échangez une tâche bloquée contre un tas d’opérations incomplètes.

10) Dois‑je supprimer manuellement la ligne lock: dans 101.conf ?

Évitez‑le à moins d’être en mode recovery et de comprendre les implications de pmxcfs. Préférez qm unlock, qui est la voie supportée et maintient les attentes des outils alignées.

Conclusion : étapes pratiques suivantes

Lorsque Proxmox indique « impossible d’obtenir le verrou exclusif », ne discutez pas avec lui. Interrogez‑le. La raison du verrou vous indique quel sous‑système investiguer, et les gains les plus rapides proviennent de la confirmation qu’une tâche est encore vivante et que le stockage répond réellement.

Étapes suivantes que vous pouvez appliquer dès aujourd’hui :

1. Adoptez l’ordre de diagnostic rapide : tâches → QEMU → stockage → déverrouillage.
2. Ajoutez une règle opérationnelle : pas de qm unlock tant que vous n’avez pas vérifié l’état des tâches et la santé du stockage.
3. Pour les verrous liés aux sauvegardes, traitez la cible de sauvegarde comme une dépendance de production. Supervisez‑la comme telle.
4. Pour Ceph/ZFS, apprenez à lire les indicateurs natifs (watchers, holds). Ils expliquent souvent le problème réel.
5. Rédigez votre propre runbook interne avec vos noms de stockage, pools et modèles de panne — car le prochain verrou arrivera quand vous serez fatigué.