How to Fix a Locked VM in Proxmox VE

A locked VM in Proxmox VE is one of the most common issues administrators encounter. The lock mechanism exists to prevent conflicting operations — for example, you should not be able to delete a VM while it is being backed up. However, locks can sometimes persist after the originating process has finished or crashed, leaving you unable to manage the VM. This guide explains why locks happen and how to resolve them safely.

Understanding VM Lock Types

Proxmox uses several lock types, each tied to a specific operation. When a VM is locked, you will see a padlock icon in the web UI and an error like VM is locked (backup) when trying to perform actions. The most common lock types are:

• backup — Applied during vzdump backup jobs
• migrate — Applied during live or offline migration
• snapshot — Applied during snapshot creation or rollback
• clone — Applied during a VM clone operation
• rollback — Applied during a snapshot rollback
• disk — Applied during disk import or move operations

Step 1: Check the Current Lock Status

Before removing a lock, identify which lock is applied and whether the originating process is still running.

# Check the VM configuration for a lock entry
qm config 100 | grep lock

# Check if any related process is still running
ps aux | grep -E "vzdump|qm|qemu" | grep 100

# View the VM status via the API
pvesh get /nodes/$(hostname)/qemu/100/status/current

If the process that created the lock is still running, wait for it to finish. Removing a lock while a backup or migration is in progress can corrupt data.

Step 2: Unlock the VM with qm unlock

Once you have confirmed the originating process is no longer running, unlock the VM using the qm command-line tool:

# Unlock a QEMU/KVM virtual machine
qm unlock 100

# For LXC containers, use pct instead
pct unlock 200

After unlocking, verify the lock is gone:

qm config 100 | grep lock
# No output means the lock has been removed

Step 3: Manually Removing Lock Files

In rare cases, the qm unlock command may not work — for example, if the cluster filesystem is in an inconsistent state. You can manually edit the VM configuration file to remove the lock entry:

# VM configs are stored in /etc/pve/qemu-server/
cat /etc/pve/qemu-server/100.conf | grep lock

# Remove the lock line from the configuration
# Look for a line like: lock: backup
sed -i '/^lock:/d' /etc/pve/qemu-server/100.conf

# For LXC containers
sed -i '/^lock:/d' /etc/pve/lxc/200.conf

Be cautious with manual edits to /etc/pve/ — this is a cluster filesystem (pmxcfs), and changes propagate across all nodes.

Dealing with Backup Locks

Backup locks from vzdump are the most frequent culprit. If a backup job is interrupted (by a power failure, OOM kill, or manual stop), the lock can remain.

# Check for orphaned vzdump processes
ps aux | grep vzdump

# If vzdump is stuck, kill it gracefully first
kill $(pgrep -f "vzdump.*100")

# Wait a moment, then unlock
sleep 5
qm unlock 100

# Check for leftover temporary backup files
ls -la /var/lib/vz/dump/ | grep tmp

If you use automated backup schedules, ensure your backup storage has sufficient space. A full storage target is a common reason for vzdump to fail mid-backup and leave locks behind.

Dealing with Migration Locks

Migration locks occur during live or offline migration between cluster nodes. If the target node goes offline mid-migration, the lock persists on the source.

# Check cluster status first
pvecm status

# If the migration failed, unlock on the source node
qm unlock 100

# Verify the VM is not registered on the target node
ssh target-node "qm list" | grep 100

Force Stopping a Locked VM

Sometimes a VM is both locked and unresponsive. You need to force stop it before unlocking:

# Try a graceful shutdown first (sends ACPI signal)
qm shutdown 100 --timeout 60

# If that fails, force stop the VM
qm stop 100 --skiplock

# The --skiplock flag bypasses the lock for this operation
# Now remove the lock
qm unlock 100

# As a last resort, kill the QEMU process directly
kill -9 $(cat /run/qemu-server/100.pid)

The --skiplock flag is available on most qm subcommands and is essential when a locked VM needs immediate intervention.

Preventing Future Lock Issues

To minimize lock-related problems in your Proxmox environment:

• Monitor backup jobs — Set up email notifications for vzdump failures so you catch stuck locks early
• Ensure adequate resources — Backup processes that get OOM-killed are a top cause of orphaned locks
• Keep Proxmox updated — Lock handling has improved significantly across releases
• Use a management dashboard — Tools like ProxmoxR let you monitor VM status from your phone, making it easy to spot locked VMs before they become a problem

Understanding the lock mechanism helps you resolve these issues confidently. Always verify that the originating process has finished before removing a lock, and prefer qm unlock over manual config edits when possible.