You click Start on a virtual machine in Proxmox VE, and instead of booting, the task log turns red. No console, no boot screen, just a wall of text ending in something like TASK ERROR: start failed: QEMU exited with code 1. If you're new to Proxmox, that message tells you almost nothing on its own, and it's easy to assume the VM itself is corrupted.
Most of the time it isn't. A VM that won't start is almost always a Proxmox host-side problem: a missing disk image, a storage volume that isn't active, a resource limit the host can't satisfy, or a config file pointing at hardware that's no longer there. The VM's actual operating system is usually fine and untouched.
This guide walks through the real error messages you'll see in the Proxmox task log, what each one actually means, and how to fix it. We'll work through this the way you'd troubleshoot it live: check the log first, then work outward from the VM config to the storage layer to the host itself.
What You Will Learn
- Where to find the actual error message Proxmox is hiding behind the task log
- How to read and decode the most common
TASK ERRORandkvm:messages - Why storage-related failures are the single biggest cause of a VM refusing to start
- How to check whether the host itself is out of RAM, disk space, or CPU resources it needs to hand the VM
- How to spot a broken or hand-edited VM config file, and how to fix it safely
- When the fix is on the VM side versus the Proxmox host side
What Is This Feature?
When you click Start on a VM, Proxmox isn't starting an operating system directly. It's launching a background process called QEMU, which is the actual virtualization engine doing the work. Proxmox's job is to read the VM's configuration file, translate every setting into a long QEMU command line, and hand that command to the Linux kernel's KVM module, which is what gives QEMU near-native CPU speed.
That config file lives at /etc/pve/qemu-server/<VMID>.conf, and it defines everything about the VM: how much RAM it gets, which disk images it uses, what network card it presents, and so on. A "won't start" failure means QEMU either couldn't be launched at all, or it launched and immediately exited because something in that config didn't check out. The task log is Proxmox showing you QEMU's own exit message, usually cut short.
Why Would You Use It?
Understanding this matters because it changes how you troubleshoot. If you think of a VM as a black box, a failed start feels like a mystery. Once you know it's really "Proxmox tried to run a QEMU command and the command failed," you can go find the exact reason instead of guessing. Every fix in this guide comes down to the same idea: find the real error text, match it to a known cause, fix that one thing, and try again.
It also saves you from the instinct to reboot the whole Proxmox host "just in case." That fixes almost nothing here and costs you the uptime of every other VM and container running on the node. Ninety percent of the time, the actual fix takes under two minutes once you know where to look.
Prerequisites
- A Proxmox VE 8.x or 9.x host you have root or admin access to
- SSH access to the host, or use of the built-in >_ Shell button in the web UI (Datacenter → your node → Shell)
- The VMID of the virtual machine that won't start (shown next to its name in the left-hand tree)
- Comfort running a handful of read-only commands in a terminal — nothing here is destructive until you knowingly change something
Step-by-Step Tutorial
Step 1: Read the full error, not just the last line
In the Proxmox web UI, click the VM, then open its Task History tab (or check the notification bell in the top-right corner right after a failed start attempt). Click the failed VM start task to open the full log. The web UI often truncates the display, so widen the panel or scroll — the real cause is usually two or three lines above the final TASK ERROR line.
You can also get the same information faster from the shell:
qm start 100Replace 100 with your actual VMID. Running the start command directly from the CLI prints the exact same error QEMU produced, without any UI truncation, which makes it much easier to search for or paste elsewhere.
Step 2: Check for a missing or unavailable disk image
This is the most common cause by a wide margin, especially after moving storage around, renaming a storage pool, or restoring a VM from backup. Look for a message like:
kvm: -drive file=/dev/pve/vm-100-disk-0,if=none,id=drive-scsi0...: Could not open '/dev/pve/vm-100-disk-0': No such file or directoryThis means the config file references a disk that Proxmox can't find on the storage backend it expects. Check which storages are actually active:
pvesm statusAny storage listed with a status other than active needs attention before the VM can use it. If the storage exists but the specific disk doesn't, list what's actually there:
pvesm list local-lvmSwap local-lvm for whichever storage your VM's disk is supposed to live on. If the disk really is gone (deleted, or the storage was reformatted), your only path forward is restoring the VM from a backup.
Step 3: Check whether the storage is even mounted or online
If you're using NFS, CIFS, ZFS, or an iSCSI-backed storage and the underlying share or pool went offline, every VM depending on it will fail to start with a variation of "Could not activate storage." Confirm the storage is actually reachable:
pvesm status
zpool statusA ZFS pool showing DEGRADED or UNAVAIL, or an NFS mount that's timed out, will block every VM on that storage. Fixing the underlying storage (remounting the share, replacing a failed disk, re-importing the pool) resolves the start failure as a side effect — there's nothing to fix on the VM itself.
Step 4: Rule out a host resource shortage
QEMU refuses to start a VM if the host can't actually give it the RAM the config demands. You'll see something like:
kvm: failed to initialize KVM: Cannot allocate memoryCheck what's actually free on the host:
free -hIf other VMs and the host itself have already claimed most of the RAM, either shut something down first or lower this VM's memory allocation in Hardware → Memory. This is especially common on homelab boxes with 16 or 32 GB total, where two or three VMs with generous RAM assignments can eat the whole budget quickly, even with memory ballooning enabled.
Step 5: Check host disk space
A full storage volume causes a similar failure, because QEMU can't even allocate space for the swap or temp files it needs to launch. Check root filesystem and storage usage:
df -hIf local or local-lvm shows 100% used, you'll need to free up space — remove old ISO images and unused backups, or extend the volume — before any VM using that storage will start.
Step 6: Look for a broken or hand-edited config file
If someone (possibly past-you) edited the VM's config file directly, a stray character or an unsupported combination of settings can stop QEMU cold. View the raw config:
cat /etc/pve/qemu-server/100.confLook for anything obviously wrong — a device referencing hardware no longer in the machine (common after removing a PCI passthrough card), a duplicate line, or a setting that doesn't match your current Proxmox version. If you recently attempted a PCI passthrough setup, that's a frequent cause; try commenting out the hostpciX line with a # and starting the VM again to confirm.
Step 7: Check for a VMID conflict or duplicate lock
If two processes tried to touch the same VM at once (for example, a backup job was still running when you clicked Start), you'll see a lock-related message instead of the errors above. That's a different, narrower problem with its own fix — we cover it in a separate guide on "VM is Locked" errors, including the full explanation of qm unlock.
Commands Explained
| Command | What it does |
|---|---|
qm start <vmid> | Starts a VM from the CLI and prints the full, untruncated error if it fails. |
pvesm status | Lists every storage pool configured on the host and whether Proxmox considers it active. |
pvesm list <storage> | Shows the actual disk images and files present on a given storage pool. |
zpool status | Reports the health of any ZFS pools on the host, including degraded or offline disks. |
free -h | Shows current RAM usage on the host in human-readable form (GB/MB). |
df -h | Shows free and used disk space for every mounted filesystem. |
cat /etc/pve/qemu-server/<vmid>.conf | Prints the VM's raw configuration file so you can inspect it directly. |
Common Errors
"kvm: -drive file=...: Could not open '...': No such file or directory" — the VM's disk image is missing from the storage Proxmox expects it on. Usually caused by moving or deleting storage without updating the VM config.
"kvm: failed to initialize KVM: Cannot allocate memory" — the host doesn't have enough free RAM to satisfy the VM's memory setting. Lower the allocation or free up RAM elsewhere.
"TASK ERROR: start failed: command '/usr/bin/kvm ...' failed: exit code 1" — a generic wrapper message. The real cause is always a few lines above it in the same log; that's the line you need to act on.
"Could not activate storage 'X', zvol not found" — the ZFS zvol backing the disk doesn't exist, often after a pool was recreated or a snapshot rollback removed it.
"no space left on device" — the host's root filesystem or the storage volume is full. Check with df -h before doing anything else.
Troubleshooting
If none of the errors above match what you're seeing, work through this order:
- Confirm the exact error text with
qm start <vmid>from the shell — don't rely on the web UI's shortened log. - Check
pvesm statusfor anything not marked active. - Check
free -handdf -hfor resource exhaustion on the host. - Compare the VM's config against a working VM of the same type to spot anything unusual.
- Check
journalctl -xeright after a failed start attempt — it sometimes catches lower-level kernel or KVM messages the task log doesn't show.
If the VM was working fine yesterday and nothing was changed on purpose, check whether an automatic Proxmox update ran overnight, or whether a scheduled backup job left a stale lock behind. Both are more common causes of "it just stopped working" than actual hardware failure.
Best Practices
Keep VM configs untouched by hand wherever possible — use the web UI or qm set instead of editing the .conf file directly, since the UI validates settings before writing them. If you do need to hand-edit a config, make a backup copy of the file first with a simple cp.
Don't overcommit host RAM to the point where every VM's maximum allocation, added together, exceeds physical memory. A little headroom for the host itself (2 GB minimum, more on ZFS systems since ZFS's ARC cache wants RAM too) avoids a whole category of these failures.
Check storage health before it becomes a start failure — a quick zpool status or pvesm status once a week on a homelab box catches degraded disks long before a VM refuses to boot because of one.
Frequently Asked Questions
Why does my VM show as running in the UI but never actually boots?
That's usually a display or boot-order problem rather than a start failure — the process launched fine but the guest OS itself isn't booting correctly. Check the VM's console directly and confirm the boot disk is first in the boot order under Options → Boot Order.
Can a failed start damage my VM's data?
No. A start failure means QEMU never successfully attached to the disk, so nothing on the virtual disk itself gets touched. Your data is exactly as it was before you clicked Start.
Does restarting the whole Proxmox host fix these errors?
Rarely, and it costs you the uptime of everything else on the node. It only helps in the narrow case where a kernel-level resource (like a stuck ZFS pool import) is genuinely wedged — that's worth confirming first with zpool status or pvesm status rather than rebooting on a guess.
I see "TASK ERROR" but no other text at all. What now?
Run qm start <vmid> directly from the shell instead of the web UI — it prints the complete QEMU error without truncation, and that's almost always the missing detail.
Conclusion
A VM that won't start looks alarming the first time you see it, but the cause is almost always mundane: a missing disk, a full or offline storage pool, or a host that's out of RAM. Once you get in the habit of reading the actual error line instead of just the final TASK ERROR, most of these take a couple of minutes to diagnose and fix.
Save the sequence from this guide — check the log, check storage, check host resources, check the config — and you'll have a reliable checklist for the next time a VM refuses to cooperate, whether that's next week or a year from now.