Proxmox «VM is locked (backup/snapshot)»: cómo eliminar un bloqueo de forma segura

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

Un bloqueo de VM en Proxmox es un mecanismo de coordinación. Es un pequeño metadato que dice: “Algo está realizando una operación que no debe solaparse con otras operaciones”. Típicamente ese “algo” es uno de estos:

• backup (vzdump, PBS o integración de terceros)
• snapshot (snapshot de qemu y/o snapshot a nivel de almacenamiento)
• clone (a menudo basado en snapshot)
• migration (live u offline)
• replication (tareas de replicación de Proxmox)

El mensaje suele aparecer cuando intentas:

• iniciar/detener/reiniciar una VM (a veces permitido, a menudo bloqueado según la operación)
• eliminar una VM
• quitar un disco
• tomar otra instantánea
• mover almacenamiento

La regla básica: desbloquear solo cuando puedas demostrar que no hay nada ejecutándose

Un bloqueo obsoleto es molesto. Un desbloqueo prematuro puede ser costoso. Si un backup está transmitiendo activamente el estado del disco y desbloqueas + eliminas el snapshot sobre el que opera, estarás creando una “copia de seguridad” que no es ni consistente ni honesta. Al restaurarla obtendrás un misterio con forma de VM.

Los bloqueos también pueden ser “verdaderos” aunque nada parezca activo en la interfaz. Quizá el proceso worker de Proxmox murió, el nodo se reinició en medio del trabajo, el almacenamiento tuvo un fallo, o una tarea quedó atascada en una espera ininterrumpible del kernel. La interfaz no miente; simplemente no siempre te dice por qué.

Un consuelo seco: los bloqueos rara vez son el problema raíz. Son el síntoma. El problema raíz suele ser latencia en el almacenamiento, un proceso de backup trabado, un snapshot que no puede confirmarse, o un agente invitado congelado que nunca se descongeló.

Broma #1: Un bloqueo de Proxmox es como un cartel de “No molestar” en la puerta de un hotel—excepto que el carro de limpieza es tu arreglo de almacenamiento y pesa varias toneladas.

Guion de diagnóstico rápido (primeras/segundas/terceras comprobaciones)

Este es el bucle de “deja de adivinar”. El objetivo: decidir rápidamente si debes esperar, cancelar o desbloquear.

Primero: confirma el tipo de bloqueo y encuentra la tarea que lo puso

1. Identifica VMID y tipo de bloqueo a partir del error (backup/snapshot/migrate/clone/replicate).
2. Revisa tareas recientes en el nodo y en el clúster.
3. Busca un worker vzdump, pvescheduler, pveproxy, pvestatd o pve-storage relacionado con ese VMID.

Segundo: demuestra si el trabajo sigue en curso

1. Comprueba I/O en el almacenamiento que respalda la VM (ZFS zpool iostat, Ceph rbd status, estadísticas del montaje NFS).
2. Revisa el proceso QEMU y si está bloqueado (ps, top y pistas de estado “D” del kernel).
3. Revisa el progreso de artefactos de snapshot/backup (ingesta de fragmentos en PBS, archivos temporales de vzdump, presencia de snapshot en ZFS).

Tercero: decide la ruta de resolución más segura

• Si una tarea sigue avanzando: espera. Si es crítica, mueve el problema humano (ventana de cambios) en lugar del problema del disco.
• Si la tarea está atascada pero se puede cancelar: detén el trabajo limpiamente (mata el worker correcto, cancela la tarea, elimina una referencia PID obsoleta).
• Si todo está muerto y solo queda el bloqueo: desbloquea y valida inmediatamente los discos de la VM y el estado de los snapshots.

Si dudas entre “desbloquear” y “no hacer nada”, elige “no hacer nada” hasta tener evidencia. Los bloqueos son baratos; la recuperación de datos no lo es.

Datos e historia interesantes que explican el comportamiento actual

• Dato 1: La configuración de VM de Proxmox es texto plano, almacenada bajo /etc/pve/ en un sistema de ficheros distribuido (pmxcfs). Eso hace que los bloqueos sean fáciles de representar como una línea en un archivo de configuración.
• Dato 2: pmxcfs es un sistema de archivos de clúster respaldado por Corosync; está diseñado para configuración/estado pequeño, no para datos a granel. Cuando está descontento, las escrituras de configuración (incluidas las actualizaciones de bloqueo) pueden retrasarse o fallar.
• Dato 3: El bloqueo de “backup” suele ser puesto por vzdump (clásico) o por workers relacionados con backup; su intención es evitar solapamientos de snapshot/backup que romperían la consistencia.
• Dato 4: Los snapshots en Proxmox pueden ser “internos de QEMU”, “snapshots de almacenamiento” o una mezcla—dependiendo del tipo de almacenamiento y la configuración. Por eso limpiar un bloqueo sin limpiar el estado del almacenamiento puede dejarte con un snapshot que no puedes borrar.
• Dato 5: El guest-agent usa “freeze/thaw” para mejorar la consistencia de archivos, pero si el agente falta o está colgado, la orquestación del snapshot puede estancarse en lugares sorprendentes.
• Dato 6: Las operaciones de snapshot de QEMU dependen de QMP (QEMU Machine Protocol). Si QEMU está atascado o QMP deja de responder, Proxmox no puede completar el flujo de snapshot y el bloqueo puede permanecer.
• Dato 7: “Backup atascado” a menudo no es un problema de backup. Es un problema de latencia de I/O. Un disco lento o fallando puede hacer que el commit de un snapshot parezca “nada está ocurriendo”. Está ocurriendo, solo muy lentamente.
• Dato 8: En almacenamientos CoW (ZFS, Ceph), los snapshots son baratos de crear y a veces costosos de eliminar—especialmente si muchos bloques cambiaron después del snapshot.
• Dato 9: Históricamente Proxmox soporta múltiples backends de almacenamiento con semánticas distintas (LVM-thin, ZFS, RBD, NFS). Los bloqueos son una abstracción que unifica esa realidad caótica.

Dónde guarda Proxmox los bloqueos y cómo se quedan atascados

El bloqueo suele ser una línea en la configuración de la VM

La mayoría de las veces, el bloqueo se registra en el archivo de configuración de la VM bajo pmxcfs, por ejemplo:

• /etc/pve/qemu-server/101.conf para VMID 101
• /etc/pve/lxc/202.conf para el contenedor 202 (los contenedores también tienen bloqueos)

Típicamente verás algo como:

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

Proxmox establece el bloqueo al inicio de una operación sensible y lo borra al final. Si el worker se bloquea, el nodo se reinicia, pmxcfs no puede confirmar el cambio de configuración o la tarea se mata en un mal momento, el paso de “borrar bloqueo” nunca se ejecuta.

Por qué un bloqueo obsoleto es más seguro que un sistema optimista

Proxmox elige el modo de fallo conservador: si no está seguro, bloquea. Eso enfada a las personas, pero evita que hagas operaciones destructivas mientras podría haber un merge de snapshot en vuelo.

La realidad operativa es: el “bloqueo” no es un bloqueo del kernel. No garantiza que un snapshot esté realmente activo. Solo significa: en algún momento, Proxmox creyó que estaba en curso, y no ha registrado la finalización.

Qué significa realmente un «desbloqueo seguro»

Un desbloqueo seguro no es “ejecutar qm unlock y seguir”. Un desbloqueo seguro es:

1. Encontrar la tarea que puso el bloqueo.
2. Confirmar que ya no se está ejecutando (o que está atascada más allá de la recuperación).
3. Confirmar que la capa de almacenamiento no está en medio de una transacción (commit de snapshot, envío de replicación, flatten de RBD, etc.).
4. Eliminar el bloqueo.
5. Validar que la VM puede arrancar y que las operaciones de snapshot vuelven a ser coherentes.

Tareas prácticas: comandos, salidas y decisiones (12+)

Todos los ejemplos asumen VMID 101 en el nodo pve1. Ajústalos a tu entorno. Los comandos son aburridos a propósito; lo aburrido es como conservas los datos.

Tarea 1: Confirma el bloqueo y su tipo

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

Qué significa: Proxmox cree que hay un flujo de trabajo de backup activo o sin terminar para la VM 101.

Decisión: No desbloquear aún. Encuentra la tarea de backup y confirma el estado.

Tarea 2: Encuentra tareas recientes que hagan referencia al 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:",

Qué significa: Hubo una tarea vzdump para la VM 101.

Decisión: Saca el log y mira si terminó, falló o sigue en ejecución.

Tarea 3: Lee el log de la tarea (la verdad más rápida en 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

Qué significa: La tarea indica “running” y no ha registrado finalización. Puede estar realmente en ejecución o estar atascada.

Decisión: Verifica si el proceso existe y si está haciendo progreso.

Tarea 4: Comprueba si hay un worker vzdump ejecutándose

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

Qué significa: Un proceso vzdump está vivo.

Decisión: No desbloquees. Siguiente: determina si progresa o está colgado.

Tarea 5: Observa archivos temporales de backup para ver movimiento (comportamiento clásico 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

Qué significa: Hay un archivo temporal. Si su tamaño aumenta con el tiempo, el backup progresa.

Decisión: Mide el tamaño dos veces (o usa watch). Si sigue creciendo, espera. Si se queda, investiga el estado del almacenamiento y del proceso.

Tarea 6: Comprueba si el archivo temporal sigue creciendo

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_12_04.vma.zst.tmp 95182411264 2025-12-26 01:18:27.000000000 +0000

Qué significa: Este es un punto en el tiempo. Ejecútalo de nuevo tras 30–60 segundos.

Decisión: Si tamaño y mtime no cambian, trata la tarea como posiblemente atascada y pasa a comprobaciones de almacenamiento.

Tarea 7: Comprueba salud del proceso VM y respuesta de QEMU

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

Qué significa: La VM sigue en ejecución; las copias de seguridad en modo snapshot a menudo mantienen la VM en marcha mientras se snapshottea.

Decisión: Si el backup está atascado, no reinicies la VM “para arreglarlo”. Así conviertes un backup atascado en un backup atascado más una VM atascada.

Tarea 8: Busca estado “D” del kernel en hilos de backup o 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 ...

Qué significa: El proceso vzdump está en estado D (sleep ininterrumpible), normalmente esperando I/O (NFS, disco, ZFS, Ceph, etc.). Matarlo puede no funcionar hasta que el I/O regrese.

Decisión: No empieces con kill -9. Primero encuentra el cuello de botella de I/O.

Tarea 9: Identifica en qué almacenamiento está el disco de la VM

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

Qué significa: El disco está en el almacenamiento ZFS local-zfs. Las semánticas de snapshot/eliminación dependen de ZFS.

Decisión: Comprueba la salud del pool ZFS y el estado de snapshots antes de considerar desbloquear.

Tarea 10: Comprueba salud del pool ZFS (prueba rápida de humo por corrupción)

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

Qué significa: ZFS no reporta errores conocidos.

Decisión: Si el pool está degradado, detente aquí y trátalo como un incidente de almacenamiento. Desbloquear no te salvará.

Tarea 11: Revisa I/O y latencia de 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

Qué significa: Hay escrituras en curso; el backup puede estar progresando (commit de snapshot, actividad en zvol, etc.). Esto no garantiza que sea el backup, pero argumenta en contra de “no hay nada ocurriendo”.

Decisión: Si ves I/O constante y sin errores, prefiere esperar en lugar de intervenir forzosamente.

Tarea 12: Comprueba si existe metadata de snapshot en Proxmox

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

Qué significa: Existe un snapshot. Los backups en modo snapshot suelen crear un snapshot y luego eliminarlo/confirmarlo.

Decisión: Si el backup está atascado y el snapshot permanece, tendrás que manejar la limpieza del snapshot con cautela tras detener la tarea.

Tarea 13: Busca el bloqueo en el archivo de configuración de la VM (no edites aún, solo observa)

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

Qué significa: El bloqueo está registrado en el estado de configuración.

Decisión: Prefiere qm unlock 101 sobre ediciones manuales de archivos. Las ediciones manuales son para cuando pmxcfs está roto o estás en modo incidente con un registro de cambios.

Tarea 14: Cancelar una tarea en ejecución limpiamente (cuando sea seguro y necesario)

Si la tarea está realmente atascada y el negocio exige acción, puedes detener la tarea. Primero intenta una terminación suave.

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

Qué significa: Sigue en estado D; no puede manejar señales porque está bloqueado en I/O.

Decisión: No escales a kill -9 como “plan”. Arregla la condición de I/O (NFS caído, ruta de almacenamiento inestable, Ceph bloqueado, etc.) o acepta esperar.

Tarea 15: Una vez que la tarea ha desaparecido, quita el bloqueo de la forma soportada

cr0x@server:~$ qm unlock 101

Qué significa: La línea de bloqueo debería eliminarse de la configuración si no hay restricciones internas que lo impidan.

Decisión: Comprueba inmediatamente la configuración y el estado de snapshots. Si existen snapshots, trátalos antes de declarar victoria.

Tarea 16: Confirma que el bloqueo se ha eliminado y que las operaciones de la VM vuelven a funcionar

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

Qué significa: Proxmox ya no bloquea operaciones basadas en ese bloqueo.

Decisión: Valida la lista de snapshots, ejecuta una operación pequeña (como qm status, qm agent ping si está disponible) y planifica un nuevo backup pronto.

Peculiaridades por almacenamiento (ZFS, LVM-thin, Ceph RBD, NFS)

ZFS: «La creación de snapshot fue instantánea; la eliminación tarda una eternidad»

Los snapshots de ZFS son referencias de metadatos. Crearlos suele ser instantáneo. Eliminarlos puede requerir liberar muchos bloques, especialmente si la VM escribió mucho después del snapshot. Ese “backup atascado” podría estar en la fase de limpieza del snapshot.

Qué hacer: confirma I/O, confirma la presencia del snapshot y solo desbloquea después de haber detenido la tarea y asegurado que no hay un zfs send/receive o snapshot destroy en ejecución.

LVM-thin: merges y agotamiento de metadatos

Los snapshots y merges de LVM-thin son otra bestia. Si el thin pool tiene poca metadata libre, los merges pueden ir a paso de tortuga o fallar. Puedes ver un bloqueo que parece no tener relación con el problema real.

Qué hacer: comprueba el uso del thin pool y la metadata antes de realizar acciones que forcen merges. Si la metadata está ajustada, el movimiento correcto puede ser “extender la metadata del thin pool” y dejar que termine.

Ceph RBD: los bloqueos de Proxmox no son los únicos bloqueos

Ceph tiene sus propios watchers/locks, además de operaciones de snapshot y flatten en RBD. Proxmox puede estar bloqueado porque Ceph está lento o porque hay una operación RBD pendiente en el clúster.

Qué hacer: verifica el estado de RBD y vigila operaciones atascadas. Un desbloqueo en Proxmox no cancela una operación en Ceph.

NFS como destino de backup: tu backup solo está vivo mientras monte

Un modo de fallo común: un tropiezo en NFS. El proceso vzdump entra en estado D, Proxmox mantiene el bloqueo y la interfaz muestra una tarea “running” para siempre. El nodo puede parecer bien. No lo está.

Qué hacer: trata el montaje NFS como una dependencia. Revisa estadísticas de montaje, busca timeouts en el servidor y prepárate para resolver la ruta de almacenamiento en lugar de “arreglar Proxmox”.

Tres microhistorias corporativas desde las trincheras del bloqueo

Microhistoria 1: El incidente causado por una suposición equivocada

El equipo tenía una creencia ordenada: “Si la GUI de Proxmox no muestra una tarea en ejecución, no hay nada corriendo”. No era una suposición irracional—hasta que llegaron a un nodo con latencia intermitente de pmxcfs en una mañana intensa.

Una VM estaba bloqueada “(snapshot)”. El ingeniero de guardia revisó la lista de tareas en la GUI, no vio nada obvio y ejecutó qm unlock. La VM arrancó, lo que pareció una victoria. Luego borraron un snapshot que “debía ser antiguo”.

Lo que realmente ocurría: un commit de snapshot aún estaba en progreso en la capa de almacenamiento. La vista de gestión no lo reflejaba bien porque el worker que lo inició había muerto y el sistema de archivos del clúster fue lento para actualizar el estado de la tarea. El borrado compitió con el commit y el disco de la VM quedó con metadata de snapshot inconsistente en Proxmox y un estado a medias en el almacenamiento.

La siguiente prueba de restauración falló de forma sutil y dolorosa: la VM arrancó, pero los datos de la aplicación estaban inconsistentes entre tablas. No hubo corrupción evidente. Solo datos equivocados. Tomó más tiempo detectarlo que provocarlo.

La solución duradera fue cultural: el runbook cambió de “desbloquear si la GUI está quieta” a “desbloquear solo después de probar que el worker desapareció y el almacenamiento no está en vuelo”. También añadieron el hábito de revisar tareas por CLI y verificar listas de snapshots antes de tocar algo destructivo.

Microhistoria 2: La optimización que se volvió contra ellos

Un equipo de plataforma quiso backups más rápidos. Pasaron de backups en stop-mode a snapshot-mode en todas partes, activaron compresión y arrancaron todos los jobs a la vez “para terminar antes de las horas de negocio”. En papel era limpio: menos downtime, backups más rápidos, gente feliz.

En realidad, los backups en snapshot-mode trasladaron la carga, no la eliminaron. La ventana de backup ahora golpeaba el almacenamiento y la red simultáneamente. En las peores mañanas, la latencia de Ceph subió, los guest agents se congelaron en algunas VMs y varios backups se estancaron en la limpieza de snapshots.

A las 9 a. m., un puñado de VMs estaban bloqueadas. La reacción instintiva fue desbloquearlas para que los equipos pudieran desplegar. Ese “arreglo” funcionó—hasta que el sistema de backup empezó a reportar archivos inútiles porque la cadena de snapshots quedó hecha un lío.

Lo que salió mal no fue snapshot-mode en sí. Fue la concurrencia. Trataron los backups como cargas de CPU cuando son cargas de almacenamiento. Después de escalonar horarios, limitar la paralelización por backend de almacenamiento y fijar timeouts/alertas para “bloqueo mayor de X”, los incidentes casi desaparecieron.

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

Un entorno financiero tenía exactamente una virtud: disciplina. Cada cambio requería un ticket. Cada ticket requería una precomprobación. Y cada precomprobación exigía verificar backups y estado de snapshots.

Un día, una VM mostró “locked (backup)”. El ingeniero de guardia no la desbloqueó. Leyó el log de la tarea, vio un backup atascado en estado D y escaló a almacenamiento. Almacenamiento encontró un servidor NFS haciendo una actualización del kernel con un plan de reinicio demasiado optimista.

Cuando NFS se recuperó, el proceso vzdump terminó, el bloqueo se limpió automáticamente y el snapshot desapareció como se esperaba. No fue necesario ningún desbloqueo manual. La ventana de cambio se movió, la gente se quejó y los datos de la VM se mantuvieron intactos.

Esa historia no suena heroica porque no lo es. Es lo que quieres: operaciones aburridas y repetibles que te protegen de tu propia urgencia.

Listas de comprobación / planes paso a paso

Plan A: El predeterminado seguro (la mayoría de los casos)

1. Identifica el bloqueo: qm config <vmid> | grep '^lock:'
2. Encuentra la tarea: consulta tareas recientes en el nodo; localiza el UPID de vzdump/snapshot/migrate/replicate.
3. Lee el log de la tarea: si sigue registrando y progresando, espera.
4. Valida el estado del proceso: confirma si existe un proceso worker; revisa estado D.
5. Valida salud del almacenamiento: comprobaciones ZFS/Ceph/LVM/NFS según el backend.
6. Si progresa: espera y comunica.
7. Si está atascado por una dependencia: arregla la dependencia (almacenamiento/red), no el bloqueo.
8. Si la tarea está muerta y el almacenamiento es estable: desbloquea con qm unlock.
9. Validación post-desbloqueo: revisa snapshots; arranca la VM; ejecuta una pequeña validación de I/O; programa un nuevo backup.

Plan B: Debes intervenir (tarea atascada, impacto empresarial)

1. Confirma que la VM no está en medio de migración/replicación. Si lo está, detente y reevalúa.
2. Confirma que ningún proceso de backup esté escribiendo salida activamente (crecimiento de archivo temporal, ancho de banda de almacenamiento).
3. Intenta una cancelación/terminación suave del proceso worker o de la tarea (no kill -9 primero).
4. Si el proceso está en estado D: arregla la ruta de I/O. Matarlo no funcionará hasta que la llamada del kernel retorne.
5. Después de que el worker desaparezca y el almacenamiento esté estable, desbloquea con qm unlock <vmid>.
6. Limpia artefactos de snapshot (elimina snapshots sobrantes solo después de saber que no hay merges/commits en ejecución).
7. Documenta lo ocurrido. Olvidarás los detalles más rápido de lo que crees.

Plan C: pmxcfs o el estado del clúster está roto (raro, picante)

1. Confirma quórum del clúster y salud de pmxcfs en el nodo.
2. Evita editar /etc/pve/ directamente a menos que entiendas el alcance del daño.
3. Restaura la salud del clúster primero. Si el estado de configuración no puede escribirse, los comandos de desbloqueo pueden “tener éxito” en espíritu pero no en realidad.
4. Una vez pmxcfs sea estable, vuelve a ejecutar el flujo normal.

Broma #2: “Solo desbloquéalo” es el equivalente virtualizador de “simplemente reinicia prod”—a veces correcto, con frecuencia limitador de carrera.

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

1) “El bloqueo no se limpia, pero el backup parece terminado”

Síntoma: existe el archivo de archive de vzdump; la GUI todavía dice bloqueado (backup).

Causa raíz: la tarea falló durante limpieza o pasos post-backup; la línea de bloqueo no se eliminó por un crash del worker o fallo de escritura en pmxcfs.

Solución: verifica que no haya ningún job en ejecución; confirma que la lista de snapshots esté limpia; ejecuta qm unlock; luego valida los backups con una prueba de restauración (no solo “el archivo existe”).

2) “Lo desbloqueé, ahora los snapshots no se pueden borrar”

Síntoma: la eliminación de snapshot falla o se cuelga; Proxmox muestra árbol de snapshots inconsistente.

Causa raíz: desbloqueaste mientras la confirmación/merge a nivel de almacenamiento aún se ejecutaba, o dejaste snapshots de almacenamiento que Proxmox ya no rastrea correctamente.

Solución: vuelve a comprobar operaciones de almacenamiento; para ZFS, lista snapshots y evalúa si hay destroy en progreso; para Ceph, revisa estado/operaciones RBD; solo entonces elimina o reconcilia snapshots.

3) “La tarea de backup se ejecuta para siempre y no puede matarse”

Síntoma: el proceso muestra estado D; las señales no funcionan.

Causa raíz: I/O bloqueado (NFS inalcanzable, rutas de disco, Ceph colgado o kernel esperando almacenamiento).

Solución: arregla la dependencia de I/O. Si es NFS, restablece conectividad o vuelve a montar tras estabilizar; si es Ceph, arregla salud del clúster; si son discos locales, revisa hardware y dmesg. Luego deja que el proceso retorne y termine.

4) “VM locked (snapshot) después de guest-agent freeze”

Síntoma: la operación de snapshot empezó; la VM sigue bloqueada; el guest parece congelado.

Causa raíz: el guest-agent de QEMU no respondió al thaw, o el freeze expiró a mitad del flujo.

Solución: revisa el estado del agente dentro de la VM y en Proxmox; considera deshabilitar el freeze de archivos para esa carga de trabajo o arreglar el servicio del agente; desbloquea solo después de confirmar que no hay merge/commit de snapshot pendiente.

5) “Los bloqueos ocurren cada noche a la misma hora”

Síntoma: incidentes de bloqueo recurrentes durante la ventana de backup.

Causa raíz: demasiada concurrencia, saturación del destino de backup o mantenimiento periódico del almacenamiento que choca con backups.

Solución: escalona jobs, limita ancho de banda realista, reduce backups paralelos por nodo/almacenamiento y añade alertas para tareas que superen tiempo esperado.

6) “qm unlock funciona, pero la GUI todavía muestra bloqueado”

Síntoma: la CLI declara éxito; la UI sigue bloqueando operaciones.

Causa raíz: retraso en la propagación de pmxcfs/estado del clúster o cache de la GUI del nodo; a veces desbloqueaste en un nodo no autorizado durante un problema de clúster.

Solución: verifica el archivo de configuración en el filesystem del clúster, confirma quórum y revisa desde el nodo que hospeda la VM. Si el clúster está enfermo, arréglalo primero.

Preguntas frecuentes (preguntas reales a las 2 a. m.)

1) ¿Es siempre seguro ejecutar qm unlock <vmid>?

No. Es seguro cuando el bloqueo está obsoleto: no hay worker en ejecución, no hay operación de almacenamiento en curso y has verificado el estado de snapshots/backups. De lo contrario es ruleta con mejor marca.

2) ¿Cuál es la diferencia entre “locked (backup)” y “locked (snapshot)”?

“backup” típicamente significa que un flujo de backup (a menudo basado en snapshot) está activo. “snapshot” normalmente indica que una operación de snapshot está activa (crear/eliminar/rollback). Cualquiera puede involucrar snapshots a nivel de almacenamiento.

3) ¿Puedo simplemente borrar la línea lock: de /etc/pve/qemu-server/<vmid>.conf?

Puedes, pero no deberías salvo que sea necesario. Usa qm unlock para que Proxmox haga la contabilidad interna correcta. Las ediciones manuales son para cuando los servicios de gestión están rotos y tienes un plan de incidente.

4) La tarea dice “running” pero no hay proceso. ¿Qué hago ahora?

Asume que el worker murió. Verifica que no haya actividad de almacenamiento en curso y comprueba si existen snapshots. Si realmente está muerto y estable, desbloquea y luego limpia snapshots con cuidado.

5) ¿Por qué un bloqueo de backup impide un reinicio o apagado?

Porque los backups en modo snapshot dependen de un estado de disco consistente, y reiniciar/apagar puede interrumpir la creación/commit del snapshot. Proxmox bloquea para mantener coherencia en el flujo de almacenamiento.

6) ¿Cómo sé si un backup está “haciendo progreso”?

Revisa logs de tarea para salida continua, comprueba archivos temporales que crecen y revisa estadísticas de I/O del almacenamiento. Si todo está plano largo tiempo y ves estado D, sospecha de I/O bloqueado.

7) Si desbloqueo, ¿cancelará el backup/snapshot?

No. Desbloquear solo quita la barrera de Proxmox. El proceso subyacente (si sigue en ejecución) continuará y las operaciones de almacenamiento pueden seguir en curso. Por eso es peligroso desbloquear temprano.

8) ¿Qué debo hacer después de desbloquear un bloqueo obsoleto?

Valida la lista de snapshots (qm listsnapshot), asegúrate de que la VM arranca, revisa la salud del almacenamiento y programa un nuevo backup pronto. También revisa por qué la tarea se atascó para evitar recurrencias.

9) ¿Puede un problema de quórum del clúster causar bloqueos atascados?

Sí. Si pmxcfs no puede confirmar actualizaciones de configuración por quórum o problemas del filesystem, las tareas pueden no registrar finalización correctamente. Arregla la salud del clúster primero; si no, pelearás con fantasmas.

10) ¿Cuál es la comprobación de sentido común más rápida antes de hacer algo arriesgado?

Encuentra el UPID, lee su log y confirma si existe un proceso relacionado. Si no puedes vincular el bloqueo a una tarea muerta, no estás listo para desbloquear.

Siguientes pasos que puedes aplicar hoy

Cuando Proxmox dice “VM is locked (backup/snapshot)”, trátalo como un interbloqueo de seguridad, no como una molestia. Tu trabajo no es borrar el mensaje; tu trabajo es mantener el estado consistente.

Haz esto a continuación, en orden:

1. Operativiza el guion de diagnóstico rápido: log de tarea → estado del proceso → estado del almacenamiento.
2. Estandariza “cuándo está permitido desbloquear”: sin worker en ejecución, sin operaciones de almacenamiento en curso, lista de snapshots entendida.
3. Reduce recurrencia: escalona backups, limita concurrencia por backend de almacenamiento y alerta sobre tareas que excedan tiempo esperado.
4. Practica restauraciones: la verdadera medida del éxito de un backup es una prueba de restauración, no un archivo en disco.

Una cita para mantenerte honesto—idea parafraseada de Richard Cook (ingeniería de resiliencia): El éxito y el fracaso a menudo provienen del mismo trabajo cotidiano; la confiabilidad es cómo gestionas ese trabajo.