Fix a Proxmox VM Stuck in an Error or Locked State

A Proxmox VM marked error or locked is often recoverable, but qm unlock should not be the first command you run. A lock may represent a backup, migration, snapshot, clone, or disk operation that is still active. Removing a legitimate lock can allow two conflicting operations to touch the same VM.

Quick decision tree

1. Confirm the VM ID and status.
2. Identify the lock reason.
3. Check whether the associated task or process is still running.
4. Fix storage, cluster, or resource failures first.
5. Unlock only when the operation is definitely gone.
6. Start the VM and inspect logs.

1. Inspect the VM

Replace 104 with your VM ID:

qm status 104
qm config 104
qm list

Look for a line such as lock: backup.

Also review the Proxmox task log in the web interface under Node → Task History, or inspect recent system logs:

journalctl -b -u pvedaemon -u pvestatd -u pveproxy --no-pager
journalctl -b -p warning..alert --no-pager

2. Confirm the original operation stopped

Check active backup, migration, and QEMU processes:

ps aux | grep -E 'vzdump|qmigrate|qemu-system' | grep -v grep
pvesm status
df -h

In a cluster, also verify quorum and node health:

pvecm status
pvecm nodes

If storage is offline, the cluster lacks quorum, or the task is still running, solve that problem before touching the lock.

3. Remove a stale lock

Only after you have confirmed that no related operation is active:

qm unlock 104
qm status 104

Then start the VM:

qm start 104
qm status 104

4. If it still will not start

Run the start command in the shell so you can see the error directly:

qm start 104

Common causes include:

• an unavailable NFS, iSCSI, Ceph, or local storage volume;
• a full filesystem or thin pool;
• a missing disk or ISO referenced by the VM configuration;
• insufficient memory;
• a cluster without quorum;
• a stale migration state;
• a PCI or USB passthrough device that no longer exists.

Useful checks:

pvesm status
lvs -a
df -h
qm config 104
dmesg --level=err,warn

Do not delete a lock file or edit /etc/pve/qemu-server/104.conf by hand unless you understand the cluster filesystem and have exhausted supported commands.

Why this page gets the order right

The safe fix is not “always run qm unlock.” The safe fix is “prove the lock is stale, then unlock.” That distinction protects backups, migrations, and storage operations from accidental overlap.

Once the VM starts, verify the guest console, network reachability, application health, and the most recent backup. If the underlying issue was shared storage, continue with the Synology NFS guide.