How to Fix "VM Won't Start" Errors in Proxmox VE (Common Causes and Fixes)

Introduction

You click Start on a virtual machine in Proxmox VE, and instead of booting, it just... doesn't. Maybe the task log fills with red text. Maybe the VM sits at 0% for a minute and then dies. Maybe it says it started, but the console shows a black screen forever.

None of this is unusual. A VM refusing to start is one of the most common things people run into once they've been running Proxmox for a while, and almost every case traces back to one of a handful of root causes: a locked configuration file, a missing disk, a bad CPU setting, a broken network bridge, or the host simply not having enough resources free. The trick isn't memorizing every possible error string. It's knowing where Proxmox actually tells you what happened, and how to read it.

This guide walks through how VM startup actually works under the hood, then goes case by case through the errors you're most likely to hit and how to fix each one.

What You Will Learn

• How Proxmox actually starts a VM behind the scenes, and where it logs failures
• How to read the Task Log so an error message stops looking like gibberish
• The five most common reasons a VM refuses to start
• Exact commands to diagnose and fix locked VMs, missing disks, CPU mismatches, and network errors
• How to tell a storage problem apart from a configuration problem
• Habits that prevent most of these failures before they happen

What Is This Feature?

When you tell Proxmox VE to start a virtual machine, the web interface doesn't do the heavy lifting itself. It hands the job to a background service called qmeventd and the qm command-line tool, which in turn builds a long kvm command using every setting in that VM's configuration file (memory, disks, network cards, CPU type, and so on) and launches it as a process on the host.

If you've never heard of KVM before: it stands for Kernel-based Virtual Machine, and it's the actual virtualization engine built into the Linux kernel that Proxmox is a management layer on top of. Proxmox VE doesn't reinvent virtualization, it just gives KVM a friendly web interface, a config format, clustering, and storage integration.

Every VM has a configuration file on the host, at /etc/pve/qemu-server/<vmid>.conf. That file lists the disks, network interfaces, RAM, CPU type, and boot order for that specific VM. When you click Start, Proxmox reads that file, checks that the underlying storage and network devices actually exist, and then launches the process. A start failure means one of those checks failed, or the process itself couldn't come up, and Proxmox almost always tells you which one in the Task Log.

Why Would You Use It?

You don't choose to troubleshoot a VM start failure, it chooses you. But understanding this process matters because it turns a scary wall of red text into a two-minute diagnosis. Once you know that 90% of start failures fall into five buckets, you stop guessing and start checking the right thing first.

It also matters because some of these failures look identical from the GUI but have completely different fixes. A VM that won't start because its config is locked needs a totally different fix than one that won't start because its disk image is missing. Guess wrong and you can waste twenty minutes chasing the wrong problem, or worse, start deleting things that were actually fine.

Prerequisites

Before you start digging, make sure you have the following:

• SSH or console access to the Proxmox VE host (root, or a user with enough permission to run qm commands)
• The VM's ID number, shown in the left-hand resource tree, e.g. 100
• A rough idea of what changed recently, if anything: a restore, a clone, a hardware swap, a storage change, or a manual config edit
• Proxmox VE 8.x or 9.x (the commands in this guide apply to both; syntax has been stable across these releases)

You don't need any special packages installed. Everything here uses tools that ship with Proxmox VE by default.

Step-by-Step Tutorial

Work through these steps in order. Most of the time you'll find the answer in the first two or three.

Step 1: Read the actual Task Log, not just the summary

In the Proxmox web interface, click the VM, then open the Task History or the failed task notification, and click on it to expand the full log. The one-line summary at the top, TASK ERROR: start failed, is never the useful part. Scroll to the lines above it, that's where the real reason lives.

If you're on the command line instead, you can get the same information (and often more detail) with:

qm start 100

Replace 100 with your VM's ID. Running the start command directly from the shell prints the error immediately, instead of you having to dig through the GUI's task panel.

Step 2: Check whether the VM is locked

If the log mentions the word lock, or says something like can't lock file '/var/lock/qemu-server/100.conf' - got timeout, the VM's configuration is locked. This happens most often when a backup, snapshot, clone, or migration job was interrupted, or is still technically running in the background.

Check the current lock status:

qm config 100 | grep lock

If that shows a lock entry (like lock: backup), and you're sure no backup or migration is actually in progress right now, clear it with:

qm unlock 100

Then try starting the VM again. This single command fixes a surprising number of stubborn won't-start cases.

Step 3: Confirm the disk actually exists

If the log mentions something like unable to open file or no such logical volume, the VM's configuration is pointing at a disk that Proxmox can't find. This happens after a storage was renamed, a disk was deleted outside the GUI, or a restore didn't fully complete.

Check what storage the VM expects:

qm config 100

Look at the lines starting with scsi0, virtio0, or similar, they show which storage and disk image the VM is using. Then confirm that storage is actually online:

pvesm status

If the storage shows as inactive or missing entirely, that's your problem, not the VM itself. You'll need to bring the storage back online (re-mount an NFS share, re-import a ZFS pool, and so on) before the VM can start.

Step 4: Check for a CPU type mismatch

This one shows up a lot after restoring a backup onto different hardware, or after a motherboard or CPU swap. The error usually mentions something like the CPU is incompatible with host CPU or references a specific CPUID flag. It happens because the VM was configured to use a specific CPU model (like a named Intel or AMD CPU type) that the new host's physical CPU doesn't actually support.

Check the current CPU setting:

qm config 100 | grep cpu

The safest fix for a homelab or single-node setup is switching to the generic x86-64-v2-AES or plain kvm64 CPU type, which works across nearly all modern hardware:

qm set 100 --cpu x86-64-v2-AES

This trades a small amount of CPU feature exposure for compatibility. For a cluster where every node has identical CPUs, you can safely use host instead, which passes through every feature of the physical CPU for the best performance.

Step 5: Check networking and available resources

If the log mentions unable to create tap interface or references a bridge like vmbr0, the VM's network device is pointing at a bridge that doesn't exist or isn't up. Confirm your bridges with:

ip a

and cross-check against what the VM expects in Hardware > Network Device in the GUI.

If instead the failure is about memory, something like kvm: failed to initialize KVM: Cannot allocate memory, check how much RAM the host actually has free:

free -h

If the host is nearly out of memory, either free some up by stopping other VMs, or lower this VM's allocated memory in Hardware > Memory.

Commands Explained

Common Errors

These are the messages you'll actually see in the Task Log, and what each one really means.

Troubleshooting

If none of the steps above turned up an obvious cause, a couple of things are worth trying before you assume something is seriously broken.

Run qm showcmd 100 --pretty and read through the full command line Proxmox is building. Sometimes a setting looks fine in the GUI but resolves to something odd underneath, particularly with passthrough devices or custom arguments added manually to the config file.

Check the system logs for anything QEMU itself logged outside the task panel:

journalctl -u qmeventd -n 100

and

tail -n 200 /var/log/syslog

These often catch hardware-level issues, like a PCI passthrough device that's no longer present, that the Task Log summarizes too briefly to be useful on its own.

If the VM was working fine yesterday and nothing was intentionally changed, check whether an automatic Proxmox VE update ran overnight. Kernel updates occasionally shift PCI addressing for passthrough devices, which breaks VMs using GPU or USB passthrough until the hardware ID mapping in the config is updated.

Best Practices

A few habits cut down how often you'll see this problem at all.

Don't manually edit /etc/pve/qemu-server/<vmid>.conf while the VM might be mid-operation. If a backup or snapshot is running, wait for it to finish. Editing a config file that's actively locked is one of the most common ways people end up with a stuck lock in the first place.

For anything more than a single node, standardize on x86-64-v2-AES as your default CPU type rather than host, unless every node in the cluster has genuinely identical CPUs. It saves you from CPU mismatch errors the day you migrate or restore onto different hardware.

Keep an eye on host memory with free -h before spinning up new VMs, especially in a homelab where it's easy to over-allocate RAM across guests that don't all need to run at once.

Finally, before restoring an old backup or cloning a VM onto new hardware, check its CPU type and storage target first. It takes thirty seconds and avoids the exact failures covered above.

Frequently Asked Questions

Why does my VM say it's running but the console is just black?

That's usually not a start failure at all, it's a display or boot order issue. Check that the boot order actually lists the disk first, not the CD-ROM, under Options > Boot Order.

Is it safe to run qm unlock if I'm not sure why the VM is locked?

Check first that no backup, snapshot, or migration is actually in progress for that VM. If nothing is running, unlocking is safe. If something is genuinely mid-operation, wait for it to finish instead.

My VM worked fine before I restored it from a backup taken on a different machine. What broke?

Almost always the CPU type. Restoring across different physical hardware is the single most common trigger for CPU incompatibility errors.

Do I need to reboot the whole Proxmox host to fix a stuck VM?

Almost never. Everything in this guide is fixable while the host keeps running normally. Rebooting the host is a last resort, not a first step.

How do I know if it's a storage problem versus a VM configuration problem?

Run pvesm status. If the storage the VM depends on shows as inactive, it's a storage problem. If storage is fine but qm config points somewhere that doesn't exist, it's a configuration problem.

Conclusion

A VM that refuses to start feels alarming the first time it happens, mostly because the error text doesn't explain itself. Once you know where to look, though, it almost always comes down to a lock, a missing disk, a CPU mismatch, a network bridge, or a resource shortage. Work through the Task Log first, run qm config to see what the VM actually expects, and cross-check that against what's really there on the host.

None of these fixes are destructive, and none of them require guesswork once you know the five usual suspects. Bookmark this page. You'll probably need it again the next time you clone a VM onto new hardware or restore an old backup.