1
2

qm unlock 102
qm delsnapshot 102 initial_snapshot --force

--force removes the snapshot from the configuration file even if the disk snapshot no longer exists or fails to delete. For containers it is the same with pct unlock and pct delsnapshot 102 <name> --force.

The error

1

TASK ERROR: VM is locked (snapshot-delete)

And if you look at the previous attempt in the task log, the underlying failure is usually that the storage no longer has that 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

Why it happens

Deleting a snapshot is two steps: first the snapshot of each disk is destroyed on the storage (zfs destroy, lvremove, rbd snap rm, internal qcow2 snapshot), then the [name] section is removed from /etc/pve/qemu-server/102.conf. Meanwhile Proxmox writes lock: snapshot-delete into that file.

If the first step fails, the lock stays and every retry dies at the same point. Typical causes:

• Someone removed the snapshot on the storage from outside (zfs destroy, a replication or pruning policy).
• The task was interrupted (node reboot, storage that dropped halfway).
• The disk was moved to another storage and the snapshot stayed on the old one.

Procedure

1. Confirm there is no live task for that VM: in the GUI, the node’s Tasks, the delete task must be finished or failed. A qm unlock while the task is running can corrupt the snapshot.

2. Remove the lock and force the delete:

   1 2 3

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

3. Check the config: no lock: and no snapshot section.

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

4. Clean whatever is left on the storage (space that does not free itself):

   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 on a directory or NFS (VM powered off) 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

   If the snapshot included RAM there is also a vm-102-state-initial_snapshot volume on the same storage; --force tries to delete it, and if it could not, remove it by hand.

Plan B: edit the .conf

If it will not go even with --force, Proxmox staff themselves say the file can be edited by hand. In /etc/pve/qemu-server/102.conf:

1. Delete the lock: snapshot-delete line.
2. Delete the whole snapshot section: from [initial_snapshot] to the next [...] header or the end of the file.
3. If another section (the current one or a child snapshot) has parent: initial_snapshot, remove that line or point it at the grandparent if there was a chain.

Save, and qm config 102 must answer without complaints. Then the storage cleanup from step 4.

Other locks

qm unlock works for any lock left hanging; the rule is the same: first confirm the task that set it is dead.

Traps

• qm is per node. In a cluster, run everything on the node where the VM lives; the .conf is shared, but ZFS/LVM cleanup is local.
• A ZFS hold blocks zfs destroy and triggers exactly this scenario; check with zfs holds before blaming Proxmox. Details in protect a snapshot with hold.
• Space does not come back on its own. --force cleans the config, not the storage; step 4 is not optional if you care about the space.

References: Proxmox forum threads 37567 and 38248.