Proxmox «no puede obtener bloqueo exclusivo»: qué retiene la VM y cómo liberarlo

Qué es realmente el bloqueo (y qué no es)

Proxmox VE (PVE) es un sistema multiproceso que hace orquestación de la forma menos glamurosa posible: archivos de bloqueo y tareas serializadas. Eso está bien. Evita que dos operaciones pisen la misma configuración o disco de la VM al mismo tiempo.

Cuando ves “no puede obtener bloqueo exclusivo”, PVE está diciendo: “Intenté tomar un bloqueo para esta VM, pero algo ya lo tiene”. Ese “algo” puede ser:

• una tarea legítima de larga duración (backup, snapshot, replicación, migración)
• una tarea muerta que no liberó el bloqueo (reinicio de demonio, caída del nodo, colapso del almacenamiento)
• un gestor HA o componente de clúster coordinando el acceso
• un bloqueo del backend de almacenamiento (Ceph RBD lock, bloqueo de activación LVM, bloqueo de archivo NFS)
• un proceso QEMU en ejecución que todavía posee el estado runtime de la VM aunque la interfaz esté confundida

Aquí está la parte que confunde a la gente: el bloqueo puede estar en la configuración de la VM, no en el proceso de la VM. “Desbloquear” puede permitirte editar la config mientras una operación de disco sigue en curso. Así es como terminas explicándole a tu yo futuro por qué los discos de la VM parecen arte moderno.

Una verdad seca: un bloqueo es una etiqueta de advertencia. Quitarla no hace que el contenido sea seguro.

Dos clases de bloqueos importan en la práctica:

1. Bloqueos a nivel PVE (típicamente en el estado de configuración de la VM). Bloquean acciones en qm, la UI y la API.
2. Bloqueos a nivel de almacenamiento (Ceph RBD, ZFS “dataset busy”, activación LVM, bloqueos NFS obsoletos). Estos pueden bloquear QEMU, snapshots o backups incluso si PVE parece “desbloqueado”.

Guía rápida de diagnóstico

Si estás de guardia y quieres el camino más corto hasta “esto es seguro arreglar”, haz esto en orden. La idea es localizar el cuello de botella: ¿es una tarea normal, una tarea atascada o un bloqueo de almacenamiento?

Primero: ¿hay una tarea PVE activa para la VM?

• Revisa el historial de tareas para la ID de VM y busca tareas “running”.
• Confirma si hay un backup, snapshot, migración o trabajo de replicación activo.
• Si hay: no desbloquees todavía; decide si esperar, cancelar o matar al worker.

Segundo: ¿QEMU sigue en ejecución (o medio vivo)?

• Busca un proceso kvm/qemu-system-x86_64 para esa ID de VM.
• Comprueba si QMP responde, o si el proceso está atascado en espera de E/S no interrumpible (estado D).
• Si QEMU está vivo: el “bloqueo” suele ser correcto. Si QEMU está atascado: el almacenamiento suele ser el verdadero villano.

Tercero: ¿el almacenamiento está bloqueado?

• ZFS: revisa zpool status, latencia de I/O y operaciones zfs destroy/snapshot atascadas.
• Ceph: revisa la salud del clúster y los locks/watchers de RBD.
• NFS: busca handles de archivo obsoletos y puntos de montaje bloqueados.
• LVM: comprueba la activación de LV y cualquier lvchange/lvs atascado.

Luego: solo entonces considera liberar bloqueos

Si no hay ninguna tarea en ejecución, QEMU no se está ejecutando (o ha desaparecido) y el almacenamiento no realiza operaciones, entonces liberar un bloqueo obsoleto suele ser seguro.

Regla práctica: si hay alguna posibilidad de que una operación de disco esté en vuelo, trata “unlock” como un incidente y no como una solución.

Tareas y comandos: encontrar al poseedor, probar la causa, elegir la solución

Abajo hay tareas prácticas que puedes ejecutar en un nodo PVE. Cada una incluye: un comando, qué significa la salida típica y qué decisión debes tomar.

Task 1: Identificar el mensaje exacto de bloqueo y la operación

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

Qué significa: el bloqueo no es genérico; te indica qué categoría de operación lo tiene (aquí: snapshot-delete).

Decisión: busca tareas de eliminación de snapshot, no solo “algún bloqueo aleatorio”. Esto también sugiere implicación del almacenamiento.

Task 2: Comprobar la config de la VM por un campo lock

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

Qué significa: PVE registró un bloqueo en la propia config de la VM. A menudo es un residuo de una tarea interrumpida.

Decisión: no elimines esta línea a ciegas todavía. Primero confirma si alguna tarea sigue en ejecución o si el almacenamiento aún está trabajando.

Task 3: Encontrar tareas recientes que mencionen la ID de la VM en los logs del nodo

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

Qué significa: tienes una operación que falló. Las fallas pueden dejar bloqueos dependiendo de dónde ocurrió el fallo.

Decisión: pivotar al subsistema que falla (aquí: storage de backup). Si el almacenamiento sigue inaccesible, desbloquear no ayudará—simplemente fallarás de una manera más creativa.

Task 4: Listar tareas en ejecución y filtrar por la 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:

Qué significa: una tarea todavía aparece marcada como en ejecución. Puede estar realmente corriendo, atascada o simplemente no limpiada.

Decisión: inspecciona ese UPID y decide si esperar, cancelar o matar al proceso worker.

Task 5: Inspeccionar el estado de una tarea (y ver si está realmente viva)

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"}

Qué significa: PVE cree que PID 10783 sigue en ejecución y por tanto mantiene el bloqueo válido.

Decisión: verifica que el PID exista y que no esté atascado en espera de E/S indefinidamente.

Task 6: Verificar que el PID de la tarea existe y ver qué hace

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

Qué significa: el estado D significa sueño no interrumpible, usualmente bloqueado por E/S. Matarlo puede no funcionar hasta que la E/S responda.

Decisión: deja de tratar esto como “un problema de bloqueo de Proxmox”. Es un problema de almacenamiento o red. Ve a la sección de comprobaciones de almacenamiento antes de matar nada.

Task 7: Comprobar si QEMU sigue ejecutándose para esa 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 ...

Qué significa: el runtime de la VM está vivo. Aunque el bloqueo de config parezca obsoleto, el proceso de VM podría estar en medio de un snapshot o tener dispositivos adjuntos.

Decisión: no hagas qm unlock como primer movimiento. Determina si la VM está sana y qué acción está bloqueada.

Task 8: Preguntar a Proxmox cuál cree que es el estado de la VM

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

Qué significa: PVE aún la considera en ejecución. Eso suele bloquear ciertas operaciones exclusivas (como snapshot delete) por diseño.

Decisión: si tu objetivo es “iniciar VM”, persigues el problema equivocado. Si tu objetivo es “eliminar snapshot”, necesitas resolver la tarea de snapshot, no el runtime de la VM.

Task 9: Revisar el árbol de snapshots e identificar el nombre atascado

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

Qué significa: los nombres de snapshot importan. Los snapshots “vzdump” suelen quedar por fallos de backup.

Decisión: si hay un snapshot “vzdump” presente y los backups fallan, arregla primero el almacenamiento de backups y luego elimina el snapshot limpiamente.

Task 10: Intentar cancelar la tarea de forma graciosa (cuando corresponda)

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

Qué significa: solicitaste detener. Puede seguir colgando si el proceso está en estado D.

Decisión: si se detiene rápido, perfecto. Si no, la depuración de almacenamiento es obligatoria. Evita escalar a SIGKILL sin entender en qué está bloqueado.

Task 11: Cuando no hay tarea en ejecución, desbloquear con seguridad a nivel PVE

cr0x@server:~$ qm unlock 101

Qué significa: eliminó la entrada lock: de la config de la VM. Esto no soluciona bloqueos de almacenamiento ni procesos QEMU atascados.

Decisión: haz esto solo tras confirmar que no hay operación activa. Tras desbloquear, reintenta la acción bloqueada y vigila los logs.

Task 12: Comprobar disponibilidad de almacenamiento en PVE (la aburrida comprobación “¿está montado?”)

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

Qué significa: el storage de backup está inactivo. Las tareas que dependen de él pueden colgar o fallar y dejar bloqueos.

Decisión: arregla la conectividad del almacenamiento primero. Si desbloqueas mientras el storage sigue caído, el próximo intento de backup/snapshot volverá a bloquear y romper.

Task 13: NFS específico: comprobar salud del montaje y riesgo de “stale file handle”

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

Qué significa: un montaje NFS “hard” con handle obsoleto puede colgar procesos en estado D. Eso incluye vzdump y limpieza de snapshots.

Decisión: remedia la condición NFS (reinicio del servidor/export, volver a montar). No mates la tarea esperando que funcione. Volverá a atascarse.

Task 14: Ceph específico: comprobar la salud del clúster rápidamente

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

Qué significa: “slow ops” se correlaciona con snapshots/migraciones atascadas y timeouts de bloqueo porque la finalización de I/O se retrasa.

Decisión: resuelve la lentitud de Ceph (red, OSD, backfill, recovery) antes de manipular bloqueos. De lo contrario solo acelerarás tu ciclo de fallos.

Task 15: Ceph RBD lock/watchers: ver quién está adjunto

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

Qué significa: algún cliente (probablemente un nodo PVE) todavía tiene el disco abierto. Los snapshots u operaciones exclusivas pueden bloquearse.

Decisión: identifica ese cliente y confirma que QEMU realmente se detuvo. Si es un nodo muerto, puede que necesites limpiar attachments obsoletos a nivel de clúster—con cuidado.

Task 16: ZFS específico: confirmar salud del pool y buscar operaciones de larga duración

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  -

Qué significa: el pool está sano; existe un snapshot. Si la eliminación está atascada, suele ser por un hold, dependencia de clone o un stall de E/S en otra parte.

Decisión: busca clones/holds antes de forzar cualquier cosa.

Task 17: ZFS holds: encontrar por qué un snapshot no se borra

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

Qué significa: hay un hold explícito. Proxmox (o un script) lo colocó para evitar borrados accidentales durante el backup.

Decisión: elimina el hold solo si la tarea de backup está confirmadamente muerta y el snapshot es seguro de eliminar.

Task 18: Quitar un hold de ZFS (quirúrgico, no casual)

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

Qué significa: eliminaste el bloqueador que impedía la eliminación. Ahora la eliminación del snapshot puede continuar.

Decisión: ejecuta inmediatamente el borrado vía Proxmox otra vez (preferible) para que el estado de PVE permanezca consistente.

Task 19: Comprobar quién está bloqueando /var/lock a nivel OS (raro pero 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

Qué significa: el propio demonio tiene el descriptor de archivo. Eso puede ocurrir durante operaciones legítimas—o cuando el demonio está atascado.

Decisión: si pvedaemon está bloqueado (y las tareas están atascadas), puede ser apropiado reiniciarlo de forma controlada, pero solo después de entender en qué está esperando.

Task 20: Reiniciar los demonios de gestión (último recurso, pero a veces correcto)

cr0x@server:~$ systemctl restart pvedaemon pveproxy pvestatd

Qué significa: reiniciaste el plano de control. Esto puede limpiar bloqueos obsoletos y la contabilidad de tareas. No desatascará E/S del kernel bloqueada.

Decisión: haz esto cuando: (1) confirmaste que QEMU y el almacenamiento están bien, (2) las tareas están fantasma, y (3) el estado HA/clúster es estable. Si no, estarás reiniciando el panel mientras el motor arde.

Chiste #1: Desbloquear una VM sin comprobar el almacenamiento es como apagar la alarma de humo porque hace ruido. El ruido para; el problema no.

Tipos de bloqueo en Proxmox: qué suele significar cada uno

La cadena de razón del bloqueo (la parte entre paréntesis) es tu pista. Trátala como una hipótesis inicial, no como un veredicto.

backup / vzdump

Suele significar: hay un job de backup en ejecución o que se estrelló a mitad de camino, a menudo dejando un snapshot detrás (especialmente en ZFS/Ceph).

Causas subyacentes comunes: storage de backup offline, NFS con handle obsoleto, datastore PBS inalcanzable, almacenamiento lento.

Qué hacer: revisar tareas, luego la salud del target de backup y después los snapshots.

snapshot / snapshot-delete

Suele significar: creación/eliminación de snapshot en progreso, o un intento previo que murió después de establecer el estado.

Causas subyacentes comunes: holds de ZFS, operaciones lentas de Ceph, watchers RBD todavía adjuntos, I/O pendiente.

Qué hacer: inspeccionar la lista de snapshots, el estado del backend de almacenamiento y cualquier hold/watcher.

clone

Suele significar: un clone desde plantilla está en ejecución o parcialmente completado.

Causas subyacentes comunes: copia/clone de almacenamiento atascado, latencia en storage en red, espacio insuficiente.

Qué hacer: confirmar la tarea de clone, verificar espacio y salud del backend, evitar editar manualmente la config de discos mientras el clone está activo.

migrate

Suele significar: una migración está en curso o falló y no limpió estado.

Causas subyacentes comunes: nodo destino inalcanzable, interrupciones SSH, problemas con storage compartido, intervenciones HA.

Qué hacer: localizar el UPID de migración, verificar la vista de la VM en ambos nodos y confirmar que los discos no estén activos en ambos lados.

rollback

Suele significar: un rollback de snapshot está en progreso, lo que es inherentemente exclusivo.

Causas subyacentes comunes: rollback iniciado y la VM forzada a apagarse, almacenamiento con problemas, o rollback que falló y dejó estado.

Qué hacer: trátalo como alto riesgo. Confirma la consistencia de discos y no desbloquees a la ligera.

Modos de fallo específicos de almacenamiento (ZFS, Ceph, LVM, NFS, iSCSI)

La mayoría de tickets “cannot get exclusive lock” son tickets de almacenamiento con disfraz de virtualización.

ZFS: “dataset busy”, holds y dependencias silenciosas

ZFS es excelente con snapshots. También es excelente impidiendo que te hagas daño. Cuando la eliminación de snapshot está bloqueada, suele ser por:

• holds colocados por la herramienta de backup (para que no borres a mitad de backup)
• clones que dependen del snapshot
• datasets ocupados por montajes o procesos que mantienen referencias
• problemas en el pool (latencia, dispositivo fallando) que hacen que las operaciones tarden una eternidad

Qué debes evitar: destruir snapshots manualmente sin informar a Proxmox mientras este aún piensa que hay una operación en curso. Prefiere usar qm delsnapshot después de haber despejado el bloqueador subyacente; mantiene la metadata de Proxmox consistente.

Ceph RBD: watchers, locks exclusivos y “slow ops”

Ceph tiene su propio concepto de quién está adjunto a una imagen RBD. Incluso si PVE quita un bloqueo de config, la imagen puede seguir abierta por una instancia QEMU en algún lugar.

Si un nodo se estrelló, puedes tener “attachments fantasma”: el clúster todavía cree que un cliente mantiene la imagen. Verás watchers y tus acciones de snapshot/eliminación se detendrán o fallarán.

En incidentes de Ceph, el error de bloqueo suele ser el primer síntoma visible de una condición más profunda: recovery/backfill saturando discos, pérdida de paquetes de red o OSDs inestables. Arreglar la salud de Ceph es frecuentemente el “desbloqueo” más rápido.

LVM-thin: locks de activación y lvchange atascado

LVM-thin es fiable hasta que te quedas sin metadata o el VG está ocupado entre nodos de forma no prevista. Si lvs cuelga, estás en la misma categoría que problemas de montaje NFS “hard”: procesos bloqueados en E/S del kernel, no fallos amables de userland.

NFS: montajes hard, stale handles y por qué tu kill -9 no funcionó

NFS es una buena opción para backups. También es una lección magistral en trade-offs de sistemas distribuidos. Con un montaje hard, los procesos esperarán para siempre a que el servidor responda. Eso es “fiabilidad” en un sentido, y “mi clúster está pegado a un export muerto” en otro.

Cuando NFS devuelve Stale file handle, normalmente estás viendo un evento en el servidor (reboot, failover, remount, cambio de export). Los procesos cliente pueden quedarse wedgeados. Los bloqueos permanecen “retenidos” porque las tareas nunca salen.

iSCSI / multipath: pérdida de camino y QEMU en estado D

Los problemas de paths de block storage adoran aparecer como problemas de bloqueo porque QEMU puede bloquear en E/S. El plano de gestión entonces bloquea esperando a QEMU o a la finalización del almacenamiento. Si ves QEMU en estado D, piensa en multipath o SAN antes de pensar “bug de Proxmox”.

Chiste #2: Los outages de almacenamiento son generosos: comparten su dolor con cada capa encima, gratis.

Tres mini-historias del mundo corporativo (cómo sale mal en la vida real)

Mini-historia 1: El incidente causado por una suposición errónea

El equipo tenía un clúster pequeño con Ceph RBD compartido. Un nodo fue reiniciado durante una ventana de mantenimiento, y después una VM no pudo migrar. La UI mostró “no puede obtener bloqueo exclusivo”, así que el on-call supuso que Proxmox era conservador y ejecutó qm unlock.

La migración siguió fallando. Ahora la config era editable, así que “lo arreglaron” desvinculando y volviendo a vincular el disco en la config de la VM. Eso creó un estado de config aparentemente limpio que ya no estaba sincronizado con la realidad: la imagen RBD antigua todavía tenía un watcher, y los nuevos intentos de adjunción acumularon errores.

Pasaron dos horas “reintentando” y reiniciando demonios, porque a todos les encanta un ritual cuando la causa raíz no está clara. La causa real era visible en minutos: Ceph tenía slow ops y la imagen RBD aún estaba watchada por un client ID del nodo reiniciado.

Lo que cambió el resultado no fue un comando ingenioso. Fue la decisión de dejar de tratar al bloqueo como el problema y empezar a tratarlo como evidencia. Una vez Ceph se recuperó y el attachment obsoleto se resolvió, el error de bloqueo desapareció sin heroicidades.

Mini-historia 2: La optimización que salió mal

Otra empresa quería backups más rápidos. Alguien afinó los montajes NFS para throughput y ajustó tamaños de lectura/escritura grandes y configuraciones agresivas. Era rápido. En días buenos.

Entonces el servidor NFS tuvo un breve failover. El montaje era hard, lo cual es defendible, pero no planearon la realidad operativa: los procesos de backup quedaron en sueño no interrumpible esperando E/S. Esas tareas mantuvieron locks de VM, la limpieza de snapshots se atascó y los backups del día siguiente colisionaron con los restos del día anterior.

Para media mañana, varias VMs estaban “bloqueadas”, y el equipo de storage recibía preguntas de por qué la virtualización no podía “simplemente desbloquearlas”. Podían desbloquear. También podían empeorar la acumulación de snapshots permitiendo que nuevos snapshots se apilaran sobre una cadena ya fallida.

La solución eventual no fue deshacer toda la afinación. Fue añadir medidas de protección: monitorización de montajes colgados, aislar el tráfico de backup y asegurar que la herramienta de backup falle rápido para liberar locks cuando el backend esté enfermo.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una organización financiera tenía control de cambios estricto y, más importante, hábitos estrictos. Programaban eliminaciones de snapshot y backups con ventanas claras, y tenían una regla: no desbloquear manualmente hasta hacer tres comprobaciones—lista de tareas, estado del proceso QEMU y salud del almacenamiento.

Una noche una eliminación de snapshot se atascó tras perder un nodo conectividad con el target de backup. El on-call vio el error de bloqueo y siguió la checklist. Las tareas mostraron un vzdump en ejecución con un PID en estado D. El estado del almacenamiento mostró el montaje NFS inactivo.

Hicieron lo menos excitante posible: restauraron el export NFS, volvieron a montar correctamente, esperan a que la tarea atascada saliera y luego volvieron a ejecutar la eliminación de snapshot a través de Proxmox. No fue necesario ningún comando de desbloqueo. La VM nunca corrió riesgo adicional.

Era tan aburrido que casi no se sintió como éxito. Ese es el punto. Su práctica evitó una cascada: no hubo unlock forzado, no hubo ediciones de config, no quedaron snapshots parciales, no hubo ticket de seguimiento de “por qué se rompió la cadena de backups”.

Errores comunes: síntoma → causa raíz → solución

1) “Cannot get exclusive lock (backup)” y corres inmediatamente qm unlock

Síntoma: backups fallando, VM bloqueada y snapshots llamados “vzdump” acumulándose.

Causa raíz: target de backup offline o colgado (NFS/PBS), dejando tareas vzdump atascadas o fallando a mitad de snapshot.

Solución: restaura la conectividad del storage de backup; confirma que no hay tareas en ejecución; limpia snapshots vía Proxmox; desbloquea solo si está obsoleto.

2) El bloqueo persiste después de reiniciar el nodo

Síntoma: la VM aparece bloqueada aunque “nada esté corriendo”.

Causa raíz: campo lock: obsoleto en /etc/pve/qemu-server/*.conf por una operación interrumpida.

Solución: confirma que no hay tareas en ejecución y que no existe proceso QEMU; luego qm unlock <vmid>.

3) Matar el PID de la tarea no limpia el bloqueo

Síntoma: envías SIGTERM/SIGKILL; el proceso permanece; el bloqueo sigue.

Causa raíz: el proceso está en espera no interrumpible de I/O (D) por un stall NFS/SAN/Ceph; el kernel no lo matará hasta que regrese la E/S.

Solución: arregla el storage/ruta de red; vuelve a montar NFS o restaura paths SAN; entonces la tarea podrá salir y liberar bloqueos.

4) Bloqueo de migración que “no desaparece”

Síntoma: VM bloqueada con (migrate), pero la migración falló hace horas.

Causa raíz: migración parcialmente completada dejó estado en origen/destino; posiblemente la VM está registrada en ambos nodos o disco activo en destino.

Solución: verifica ubicación del proceso de VM; asegúrate de que los discos no estén activos en ambos nodos; limpia artefactos de migración; luego desbloquea el estado obsoleto.

5) Eliminación de snapshot falla repetidamente en ZFS

Síntoma: el bloqueo indica snapshot-delete; la eliminación falla; el snapshot permanece.

Causa raíz: hold de ZFS o dependencia de clone impide la eliminación.

Solución: usa zfs holds y zfs get origin para revisar; libera holds solo cuando sea seguro; borra vía Proxmox después.

6) Errores de bloqueo Ceph RBD durante stop/start

Síntoma: stop cuelga; luego aparecen errores de “exclusive lock” en operaciones.

Causa raíz: slow ops en Ceph o watchers persistentes; QEMU sigue adjunto o el clúster Ceph está degradado.

Solución: estabiliza Ceph (ceph -s); confirma watchers; asegura que QEMU esté detenido limpiamente; luego procede.

7) Reiniciar pvedaemon “lo arregla” una vez, luego vuelve

Síntoma: los bloqueos se limpian brevemente tras reiniciar el demonio, pero nuevas tareas vuelven a bloquear y fallar.

Causa raíz: el problema subyacente de almacenamiento persiste; el reinicio del plano de control enmascara síntomas.

Solución: deja de usar reinicios como tratamiento; instrumenta la salud del storage; arregla montajes/clúster antes.

Listas de verificación / plan paso a paso

Checklist A: “La VM está bloqueada y no arranca”

1. Captura el string exacto de error (tipo de operación).
2. Comprueba el bloqueo en config: grep '^lock:' /etc/pve/qemu-server/<vmid>.conf.
3. Revisa tareas en ejecución para la VM: pvesh get /nodes/<node>/tasks --running 1.
4. Si hay una tarea en ejecución: inspecciona su PID y estado (ps); si está en D, prioriza storage.
5. Comprueba si QEMU ya está en ejecución: pgrep -a -f "-id <vmid>".
6. Comprueba el estado del storage en PVE: pvesm status.
7. Revisa la salud del backend (ZFS/Ceph/NFS) según dónde vivan los discos/backups.
8. Solo si no hay tareas, no hay QEMU y el storage está estable: qm unlock <vmid> y reintenta el arranque.

Checklist B: “Bloqueo de eliminación de snapshot”

1. Lista snapshots: qm listsnapshot <vmid> e identifica el objetivo.
2. Busca tareas de backup en curso: vzdump en ejecución suele dejar locks snapshot-delete.
3. ZFS: comprueba holds: zfs holds <dataset>@<snap>.
4. Ceph: comprueba watchers: rbd status <image> --pool <pool>.
5. Arregla el bloqueador del backend (holds/watchers/slow ops).
6. Elimina el snapshot desde Proxmox otra vez (preferible): qm delsnapshot <vmid> <snapname>.
7. Si Proxmox sigue mostrando bloqueo obsoleto y no hay nada activo: qm unlock <vmid>.

Checklist C: “Bloqueo por backup”

1. Confirma que el target de backup es alcanzable y está activo: pvesm status.
2. NFS: valida que el montaje responda: timeout 3 ls /mnt/pve/<storage>.
3. PBS: comprueba conectividad del datastore (desde PVE) y autenticación.
4. Inspecciona el estado del task vzdump y el estado del PID.
5. Resuelve el problema de almacenamiento, deja que la tarea falle/salga limpiamente o detenla si puede detenerse.
6. Limpia snapshots “vzdump” sobrantes si están presentes.
7. Reejecuta un backup manual para validar antes de reactivar los horarios.

Checklist D: “Cuándo es realmente seguro usar qm unlock”

• No hay referencias de tareas en ejecución a la ID de VM.
• No existe proceso QEMU para esa ID de VM.
• El backend de almacenamiento está sano y responde.
• No hay operación de snapshot en curso a nivel de backend.
• Entiendes qué operación puso el bloqueo y aceptas las consecuencias de desbloquear.

Datos interesantes y contexto histórico

• Proxmox VE surge de una cultura operativa Linux pragmática: configuraciones basadas en archivos y locking simple son intencionales porque son inspeccionables bajo presión.
• /etc/pve no es un sistema de archivos normal: es un sistema de archivos de clúster (pmxcfs). “Un bloqueo en la config” es estado compartido del clúster, no solo texto local.
• El locking se volvió crucial a medida que los clústeres maduraron: la virtualización en nodo único podía “improvisar”; la orquestación en clúster no puede.
• La semántica de snapshots depende del backend: los snapshots ZFS se comportan distinto de los snapshots Ceph RBD, y Proxmox debe mapear ambos a una única historia en la UI.
• Los montajes NFS hard son un trade-off deliberado: previenen corrupción silenciosa de datos a costa de “todo se cuelga cuando el servidor desaparece”.
• Los “watchers” de Ceph son un regalo de visibilidad: te permiten ver qué clientes tienen una imagen abierta, lo que a menudo explica fallos de bloqueo exclusivo sin adivinanzas.
• El sueño no interrumpible (estado D) es una característica de Linux, no un bug: es el kernel negándose a matar procesos que esperan rutas críticas de I/O.
• HA añade otra capa de locking: en setups HA, una VM puede ser “retenida” por la decisión del gestor, incluso si los humanos quieren intervenir.

Una frase de operaciones (idea parafraseada): “La esperanza no es una estrategia”, citada en círculos SRE. Trata los errores de bloqueo igual: verifica, luego actúa.

Preguntas frecuentes

1) ¿Qué significa “no puede obtener bloqueo exclusivo” en Proxmox?

Significa que Proxmox intentó una operación que requiere acceso exclusivo a la config/estado de la VM (o una operación relacionada) pero detectó un bloqueo existente. El bloqueo normalmente está registrado en la config de la VM (lock:) y/o lo mantiene una tarea en ejecución.

2) ¿Es seguro ejecutar qm unlock <vmid>?

Es seguro cuando el bloqueo está obsoleto: no hay tareas en ejecución, no existe proceso QEMU y el almacenamiento backend está sano. Es inseguro cuando un backup/snapshot/migración está realmente en curso o atascado en E/S—desbloquear puede permitir operaciones conflictivas.

3) ¿Por qué el bloqueo dice “snapshot-delete” cuando solo intento arrancar la VM?

Porque la VM está bloqueada para una operación de eliminación de snapshot pendiente o atascada, y Proxmox bloquea otras acciones para prevenir un estado inconsistente. Tu petición de “arrancar” es daño colateral.

4) Maté el proceso de backup pero el bloqueo sigue. ¿Por qué?

O el proceso no murió realmente (común en estado D), o Proxmox registró el bloqueo en la config de la VM y no se limpió. Confirma con listas de tareas y estado de procesos; luego desbloquea solo tras verificar que el almacenamiento no sigue trabajando.

5) ¿Cuál es la forma más rápida de encontrar quién tiene el bloqueo?

Revisa (a) tareas en ejecución vía pvesh, (b) journalctl para la última tarea que tocó la VM, y (c) si QEMU está en ejecución. Luego comprueba indicadores del backend: watchers de Ceph, holds de ZFS, respuesta del montaje NFS.

6) ¿Puede HA causar un problema de bloqueo exclusivo?

Sí. Recursos gestionados por HA pueden iniciarse/detenerse/migrarse por el gestor HA, y fallos pueden dejar operaciones “en progreso”. Confirma siempre el estado HA y dónde debería estar corriendo la VM antes de intervenir manualmente.

7) ¿Por qué problemas NFS aparecen como bloqueos de VM?

Porque las tareas de backup/snapshot dependen de leer/escribir en NFS. Con montajes hard, esas tareas pueden bloquear indefinidamente en el kernel. Proxmox mantiene el bloqueo porque la tarea nunca sale.

8) La UI no muestra tareas en ejecución, pero el bloqueo persiste. ¿Ahora qué?

Mira directamente la config de la VM por lock:, y revisa logs por fallos previos. Después verifica archivos de bloqueo a nivel OS y la salud de los demonios. Si todo está realmente inactivo, desbloquear es razonable.

9) Si Ceph está en HEALTH_WARN, ¿debería desbloquear igual para mover las cosas?

Normalmente no. HEALTH_WARN con slow ops suele indicar que la I/O se retrasa; desbloquear no hará que las operaciones subyacentes terminen. Estabiliza Ceph primero, o cambiarás un task bloqueado por una pila de tareas a medio terminar.

10) ¿Borro alguna vez la línea lock: manualmente de 101.conf?

Evítalo a menos que estés en modo recuperación y entiendas las implicaciones de pmxcfs. Prefiere qm unlock, que es la vía soportada y mantiene las expectativas de las herramientas alineadas.

Conclusión: pasos prácticos siguientes

Cuando Proxmox dice “no puede obtener bloqueo exclusivo”, no discutas con él. Interrógalo. La razón del bloqueo te indica qué subsistema investigar, y las victorias más rápidas vienen de confirmar si una tarea sigue viva y si el almacenamiento responde realmente.

Siguientes pasos que puedes aplicar hoy:

1. Adopta el orden de diagnóstico rápido: tareas → QEMU → almacenamiento → unlock.
2. Añade una regla operativa: no ejecutar qm unlock hasta haber comprobado el estado de tareas y la salud del storage.
3. Para bloqueos relacionados con backups, trata el target de backup como una dependencia de producción. Monitorízalo como tal.
4. Para Ceph/ZFS, aprende los indicadores nativos (watchers, holds). Suelen ser la explicación real.
5. Escribe tu propio runbook interno con los nombres de storage, pools y patrones de fallo—porque el próximo bloqueo ocurrirá cuando estés cansado.