Proxmox VE Troubleshooting: 5 Errors I Hit and Fixed

Proxmox VE runs most of my homelab now. VMs, containers, GPU passthrough for Ollama, the whole stack. But the first month was rough. I hit five distinct failures that each looked like something different was broken when the actual problem was somewhere else entirely. Posting what I found so you don’t spend three hours on the wrong fix.

VM Hangs on Boot with Error “device mapper” Messages

First real problem. Spin up a Debian VM, let it run for a day, reboot it. VM hangs on boot. Console shows repeated errors about device mapper and LVM not activating. No clear error code, just stuck at initramfs.

I assumed corrupted disk. Wasn’t. I blamed the storage backend (local LVM). Wrong again.

The actual issue: VM had a snapshot. Proxmox was trying to boot from a snapshot that had become inconsistent after I’d killed the VM hard during shutdown. Snapshots in Proxmox LVM are not rollback points like in VMware. They’re point-in-time copies, and if the guest OS doesn’t know about the snapshot layer, things break.

Fix was straightforward but not obvious. SSH into the Proxmox node and remove the snapshot:

lvremove /dev/pve/vm-100-disk-1_snap-name

Then boot the VM normally. It came up clean. The lesson: check for snapshots before you blame anything else. Use lvs on the node to list them.

Container Networking Fails After Node Reboot

Set up an LXC container, runs fine for weeks. Node reboots for a kernel update. Container comes back up but has no network. Can’t ping the gateway, can’t reach anything outside. The container thinks it has an IP address though. Ifconfig shows eth0 with a valid lease.

Most people blame DHCP. I did too. Spent an hour reconfiguring the DHCP scope on my router. Not the issue.

Real problem: the veth (virtual ethernet) interface on the host side had gotten into a bad state. Proxmox creates a host-side veth for each container network interface, and sometimes after a reboot, these interfaces don’t come back up properly even though the container side looks fine.

The fix required stopping the container, then on the Proxmox host:

ip link delete vethi0

Then restart the container. Proxmox will recreate the veth pair and DHCP will actually work this time. Before you do this, check that the veth exists and is down:

ip link show | grep veth

If you see a veth that’s DOWN instead of UP, that’s your culprit.

Storage Deadlock: “No Space Left on Device” When Disk Isn’t Full

This one cost me an afternoon. VM storage shows 87% full on a ZFS pool. Everything runs, then suddenly I get “no space left on device” errors even though the pool clearly has 13% free. Can’t allocate new snapshots, can’t resize disks, can’t do anything.

ZFS has a reserved space system that’s easy to miss. By default, ZFS reserves some capacity for internal metadata and recovery operations. If your pool gets too fragmented or if metadata overhead is high, that reserved space can become unreachable, making the filesystem think it’s out of space before it actually is.

Diagnosis:

zfs list -o space

Look at the USEDSNAP column. If snapshots are consuming more than you expect, that’s eating your reserved space. Also check USEDDS and USEDCHILD.

My fix involved two things. First, I deleted old snapshots that had accumulated:

zfs list -t snapshot -r pve

Then delete the ones you don’t need:

zfs destroy pve/vm-100-disk-0@snap-20240115

Second, I adjusted the reservation. This is less common but sometimes necessary:

zfs set reservation=0 pve

That freed up about 4% of space immediately. I should have cleaned up snapshots sooner.

GPU Passthrough Device Not Appearing in VM

Added an NVIDIA GPU to passthrough, configured it in the VM settings, started the VM. Device doesn’t show up. lspci inside the VM returns nothing for the GPU. IOMMU is enabled, VFIO modules are loaded on the host, everything looks correct.

The error that should have told me something was wrong never appeared. The VM just started as if the GPU was there, then the guest OS couldn’t find it.

Problem turned out to be IOMMU grouping. My motherboard (an older Asus board with an 8th-gen Intel chip) grouped the GPU with some other PCI devices. Proxmox can’t isolate just the GPU; it has to pass through the entire group, which included devices the VM needed for other things.

The debug step that mattered:

for iommu_group in $(find /sys/kernel/iommu_groups/ -maxdepth 1 -mindepth 1 -type d); do echo "IOMMU group $(basename $iommu_group):"; lspci -s $(cat $iommu_group/devices/* | awk -F: '{print $2}' | tr 'n' ',' | sed 's/,$/n/') 2>/dev/null || cat $iommu_group/devices/*; done

Ran that and found my GPU (01:00.0) was grouped with 01:00.1 (audio function of the same card) and also with some root port that the chipset needed. Couldn’t separate them.

Real solution: use ACS override. On the Proxmox host, edit /etc/default/grub and add iommu=pt to the kernel command line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt pcie_acs_override=downstream,multifunction"

Then update grub and reboot:

update-grub && reboot

After that, the IOMMU groups became finer-grained and I could pass through just the GPU without the audio function or the root port. ACS override is a security consideration though. Only use it if you’re running your own hardware and you’re not concerned about DMA attacks between VMs.

High RAM Usage on Node with Idle VMs

Last issue. After a few weeks, the Proxmox node itself starts consuming 60% of system RAM even though all my VMs are reporting low memory usage. Top shows no process eating the memory. It’s just gone.

This was ZFS page cache, not a leak. ZFS will aggressively cache reads and writes in host RAM if it’s available. On a homelab system where you’re not running mission-critical workloads and you do care about getting spare RAM back to your VMs, this can be annoying.

Not a bug, but it surprised me. Checked Arc cache size:

cat /proc/spl/kstat/zfs/arcstats | grep c_max

That number is how much RAM ZFS is allowed to use for caching. By default, it’s roughly 50% of system RAM. You can lower it if you want to prioritize VM memory:

echo 8589934592 > /sys/module/zfs/parameters/zfs_arc_max

That sets it to 8GB. Add it to /etc/modprobe.d/zfs.conf to make it permanent:

options zfs zfs_arc_max=8589934592

Then rebuild initramfs and reboot. After that, RAM usage stabilized at a reasonable level and the VMs had more breathing room.

When to Check Logs vs Hardware

All five of these had something in common: the error message didn’t point to the actual cause. Device mapper hangs didn’t mention snapshots. Networking failures didn’t mention veth states. Storage full errors didn’t mention fragmentation. GPU missing didn’t show IOMMU errors. RAM consumption showed no obvious culprit.

If Proxmox is behaving oddly, check three places in this order. First, the Proxmox node logs:

journalctl -u pveproxy -u pvedaemon -f

Second, guest OS logs if the guest is running. Third, low-level kernel state using the commands I listed above. Most of the time it’s the second or third place, not the first.

FAQ

Does Proxmox VE require enterprise support to run in a homelab?

No. Proxmox VE is free for homelabs and small installations. You only need a subscription if you want commercial support or access to the enterprise repository. The community repository has all the same packages, just with a slight update delay.

How much RAM does Proxmox VE need to run?

The Proxmox node itself needs about 2-4GB. Beyond that, it depends on your VMs and containers. Most homelabs run fine on 32-64GB total, with Proxmox using 4GB and the rest split among guests.

Can you run Proxmox VE and other hypervisors on the same machine?

Not at the same time. Proxmox requires KVM at the kernel level, which conflicts with other bare-metal hypervisors. You can run one or the other, not both simultaneously.

What’s the difference between Proxmox VE and Proxmox Backup Server?

Proxmox VE is the hypervisor (runs VMs and containers). Proxmox Backup Server is a separate appliance for centralized backup and disaster recovery. You can use both together but they’re different tools with different purposes.

Can Proxmox VE run on a Raspberry Pi?

No. Proxmox requires x86-64 CPU architecture and full virtualization support (Intel VT or AMD-V). Raspberry Pi uses ARM and doesn’t support the hypervisor features Proxmox needs.

Explore Proxmox VE in our AI Homelab Toolkit.