1
2

qm unlock 102
qm delsnapshot 102 initial_snapshot --force

--force quita el snapshot del archivo de configuración aunque el snapshot del disco ya no exista o falle al borrarse. En contenedores es lo mismo con pct unlock y pct delsnapshot 102 <nombre> --force.

El error

1

TASK ERROR: VM is locked (snapshot-delete)

Y si miras el intento anterior en el log de tareas, el fallo de fondo suele ser que el storage ya no tiene ese snapshot:

1
2

could not find any snapshots to destroy; check snapshot names.      # ZFS
Failed to find logical volume "pve/snap_vm-102-disk-0_initial_snapshot"   # LVM-thin

Por qué pasa

Borrar un snapshot son dos pasos: primero se destruyen los snapshots de cada disco en el storage (zfs destroy, lvremove, rbd snap rm, snapshot interno del qcow2) y después se quita la sección [nombre] de /etc/pve/qemu-server/102.conf. Mientras tanto Proxmox escribe lock: snapshot-delete en ese archivo.

Si el primer paso falla, el lock se queda y cada reintento muere en el mismo punto. Causas típicas:

• Alguien borró el snapshot en el storage por fuera (zfs destroy, una política de replicación o de limpieza).
• La tarea se interrumpió (reinicio del nodo, storage que se cayó a mitad).
• El disco se movió a otro storage y el snapshot se quedó en el anterior.

Procedimiento

1. Confirma que no hay una tarea viva para esa VM: en la GUI, Tasks del nodo, la tarea de borrado tiene que estar terminada o fallida. Un qm unlock con la tarea corriendo puede corromper el snapshot.

2. Quita el lock y fuerza el borrado:

   1 2 3

   qm unlock 102 qm listsnapshot 102 qm delsnapshot 102 initial_snapshot --force

3. Comprueba el config: sin lock: y sin la sección del snapshot.

   1	grep -nE '^(lock:|\[|parent:)' /etc/pve/qemu-server/102.conf

4. Limpia lo que haya quedado en el storage (espacio que no se libera solo):

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

   # ZFS zfs list -t snapshot -r rpool/data | grep vm-102 zfs destroy rpool/data/vm-102-disk-0@initial_snapshot # LVM-thin lvs | grep snap_vm-102 lvremove pve/snap_vm-102-disk-0_initial_snapshot # Ceph RBD rbd snap ls cephpool/vm-102-disk-0 rbd snap rm cephpool/vm-102-disk-0@initial_snapshot # qcow2 en directorio o NFS (VM apagada) qemu-img snapshot -l /var/lib/vz/images/102/vm-102-disk-0.qcow2 qemu-img snapshot -d initial_snapshot /var/lib/vz/images/102/vm-102-disk-0.qcow2

   Si el snapshot incluía la RAM, además existe un volumen vm-102-state-initial_snapshot en el mismo storage; --force intenta borrarlo, y si no pudo, quítalo a mano.

Plan B: editar el .conf

Si ni con --force sale, el propio staff de Proxmox indica que se puede editar el archivo a mano. En /etc/pve/qemu-server/102.conf:

1. Borra la línea lock: snapshot-delete.
2. Borra la sección completa del snapshot: desde [initial_snapshot] hasta la siguiente cabecera [...] o el final del archivo.
3. Si otra sección (la actual o un snapshot hijo) tiene parent: initial_snapshot, quita esa línea o apúntala al abuelo si había cadena.

Guarda y qm config 102 tiene que responder sin quejarse. Después, la limpieza del storage del paso 4.

Otros locks

qm unlock sirve para cualquier lock que quedó colgado; la regla es la misma: primero confirma que la tarea que lo puso está muerta.

Trampas

• qm es por nodo. En un clúster, ejecuta todo en el nodo donde vive la VM; el .conf es compartido, pero la limpieza de ZFS/LVM es local.
• Un hold de ZFS impide el zfs destroy y dispara justo este escenario; revisa con zfs holds antes de culpar a Proxmox. Detalle en proteger un snapshot con hold.
• El espacio no vuelve solo. --force limpia el config, no el storage; el paso 4 no es opcional si te importa el espacio.

Referencias: hilos del foro de Proxmox 37567 y 38248.