What to Check When a Proxmox VM Will Not Start

A failed Proxmox VM start is most useful as evidence before it becomes a repair attempt. Preserve the exact task error. Identify which node and storage the VM expects. Change only the layer named by that evidence. Repeatedly pressing Start can replace a useful first failure with several less informative follow-up errors.

This decision path covers a QEMU virtual machine that appears stopped and will not start. It does not assume the guest disk is damaged. Many start failures occur before the guest operating system runs at all. Guest-level recovery commands are usually premature.

Capture the failed task before changing anything

Open the failed task at the bottom of the Proxmox web interface and save its complete output. Record the time, node, and VM ID. Also record the final status and first specific error. The last line may say that a start failed. An earlier line often identifies the missing volume, active lock, unavailable device, or cluster condition that matters.

The current pvenode reference provides a second route when the browser view is incomplete. For VM 104, list finished error tasks with:

pvenode task list --errors --vmid 104

Then read the selected task with pvenode task log UPID:.... Do not paste a sample UPID into a command. Use the identifier returned by the node. A controlled shell attempt with qm start 104 can also expose the start error directly, but run it once and retain the output instead of looping.

Write down what changed immediately before the failure. Relevant changes include a node reboot, storage outage, restore, migration, snapshot operation, package update, CPU or machine-type edit, and passthrough-device change. If an update was involved, compare the sequence with the Proxmox update checklist rather than mixing rollback guesses into the VM diagnosis.

Confirm the VM state and its control path

Check the current state and configuration before editing either one:

qm status 104
qm config 104
qm pending 104

The qm reference defines qm status as the VM status view. It defines qm config as the configuration including pending changes and qm pending as the current and pending values together. Compare the active configuration with the expected boot disk, storage IDs, CPU type, machine type, memory, firmware disk, TPM state disk, network bridges, and any mapped host devices. Do not remove an unfamiliar entry merely because it appears close to the error.

On a cluster, run pvecm status and confirm the cluster is quorate. Proxmox documents that automatic guest startup waits for quorum after node boot. Forcing the expected vote count changes the cluster safety model and is not a routine VM-start fix.

If the VM is managed by HA, inspect ha-manager status. Proxmox notes that normal qm start and qm stop requests are forwarded to the HA stack and handled asynchronously. Check the requested state, assigned node, quorum line, local resource manager state, and any recovery activity before issuing separate manual actions.

Treat a lock as evidence, not the diagnosis

Proxmox uses VM locks to prevent incompatible actions during online migration, snapshots, and backups. A lock after an interrupted job may be stale, but the lock can also be protecting work that is still active.

Find the task that created it. Review running and recent tasks on the source and destination nodes when a migration was involved. Confirm that the process has ended and that no backup, snapshot deletion, rollback, replication, or migration is still touching the VM. Only then consider:

qm unlock 104

The official qm guidance is explicit: remove a lock manually only when the action that set it is no longer running. The --skiplock start option is restricted to root, but bypassing a lock does not establish that concurrent storage work is safe. It should not be the first response to a generic lock message.

Verify every referenced storage and volume

Run pvesm status on the node that should start the VM. Every storage ID referenced by the active configuration must be enabled and accessible there. For a specific store, pvesm list STORE --vmid 104 can list volumes allocated to the VM. Compare that inventory with each disk line in qm config 104, including EFI, TPM, Cloud-Init, and attached ISO entries.

Separate these conditions rather than calling all of them a missing disk:

The storage definition exists, but its network share or underlying pool is offline.
The storage is available on another node but not the node selected to run the VM.
The configuration points to a volume that is absent or was renamed outside Proxmox.
The pool is full or its backend cannot complete activation.
An optional ISO or passthrough reference is unavailable even though the main boot disk exists.

Do not create an empty replacement volume with the missing name. That can make the configuration look complete while disconnecting it from the actual guest data. Restore access to the original backend, correct a verified configuration mismatch, or follow a documented restore path. If capacity is the issue, use the Proxmox storage-full checks before deletion. If a disk recently moved, compare its current location with the storage-move verification sequence.

Match configuration errors to host resources

When the task names memory, CPU features, machine type, firmware, or a mapped device, investigate that exact resource. Check node memory and load before reducing the VM allocation. Compare current and pending values, because a pending change may explain why the next start behaves differently from the last successful boot.

A VM moved between unlike nodes deserves a focused comparison. Review its configured CPU type and required flags, machine type, PCI or USB mappings, local storage, and bridge names against the destination. Proxmox VE 9.2 includes cluster-wide visibility for supported CPU flags, but that visibility is a planning aid rather than proof that every passthrough device or local path exists on the selected node.

Do not solve a named-device failure by removing several devices at once. Preserve the original configuration, change one verified dependency, and retry once. If the VM configuration itself is uncertain, keep an independent backup or recoverable copy outside the affected pool. The backup destination comparison explains the difference between a convenient local copy and a recovery path that survives storage loss.

Retry once, verify the guest, and record the cause

After correcting the evidenced problem, start the VM once and follow the new task to completion. If it fails differently, preserve that log as a new branch of the diagnosis. Do not keep stacking configuration edits around changing symptoms.

A successful QEMU start proves only that the virtual machine process launched. Open the console, confirm firmware finds the intended boot device, and check the guest operating system, filesystems, networking, and application service. Review the host and guest logs for I/O or device errors. A VM that starts into the wrong disk or without an expected data volume is not recovered.

Record the failed task, confirmed cause, exact correction, final configuration, and verification result. If a stale lock followed a power interruption, if a storage mount was missing after reboot, or if an HA placement exposed a node-specific dependency, convert that cause into a monitoring or maintenance action. The next failure should produce an alert or a known checklist rather than another round of speculative edits.

Sources

Primary sources were reviewed October 1, 2026 against Proxmox VE 9.2 documentation. This is documentation-based troubleshooting guidance. It does not claim that LabGremlin reproduced a specific VM start failure or validated a repair on a production system.