Common Mistakes New Proxmox VE Users Make (And How to Avoid Them)

Introduction

Most Proxmox VE horror stories don't start with a hardware failure. They start with a click that seemed harmless at the time — deleting the wrong storage, resizing a disk and forgetting the guest still needs to catch up, or leaving a firewall rule half-finished at 11 p.m. If you're a few weeks into running Proxmox VE in a homelab or a small office, you've probably already brushed up against one or two of these.

This isn't a list of exotic edge cases. These are the mistakes that show up over and over in the Proxmox forums, in homelab Discord servers, and in support tickets — usually from people who are otherwise pretty capable with Linux. Proxmox VE is friendly enough that you can get a VM running in ten minutes, but a few of its defaults and quirks aren't obvious until they bite you.

We'll go through each mistake, why it happens, and exactly what to do instead. None of this requires you to be a virtualization expert first.

What You Will Learn

• The storage mistake that deletes VM disks without any warning dialog telling you so
• Why your apt update is failing and what it has to do with a subscription you don't have
• Why running everything as root is a habit worth breaking early
• The ZFS assumption that catches almost every first-time user
• How the built-in firewall can lock you out of your own web interface
• Why disk resizes in the Proxmox GUI don't always show up inside the VM
• The backup mistake that only becomes obvious during an actual outage
• A quick checklist you can run through after a fresh install

What Is This Feature?

There's no single feature to explain here — this is more of a field guide. Proxmox VE gives you a lot of power through a fairly clean web interface, and that combination is exactly what causes trouble. A button that looks routine, like Remove next to a storage entry, can carry consequences that a beginner has no way to anticipate on their own.

Each section below covers one specific, recurring mistake: what it looks like when you're about to make it, why it happens, and what the fix or the safer alternative is. Some of these are one-time setup issues. Others are habits that quietly cause problems months down the line.

Why Would You Use It?

Reading this before you've made these mistakes is a lot less painful than reading it after. A weekend spent rebuilding a homelab because local-lvm got deleted, or an afternoon lost because a firewall rule locked out the only way in, is time you don't get back.

None of these fixes are complicated once you know about them. The hard part is knowing they exist in the first place, and that's really the whole point of this guide.

Prerequisites

You don't need a cluster or any special hardware to follow along. What helps is:

• A working Proxmox VE install — this guide is written against Proxmox VE 9.2, but almost everything here applies to 8.x as well
• Root or admin access to the web interface (https://your-server-ip:8006)
• SSH access to the host, since a few of the fixes are easier from a terminal than from the GUI
• At least one VM or LXC container already created, so the examples make sense

If you're still on the installer screen, it's worth finishing setup first and coming back to this once you have something running.

Step-by-Step Tutorial

Mistake 1: Deleting local-lvm to "free up space"

This is the one that catches people the fastest. On a default Proxmox VE install, the local disk is split into two storage entries: local, which holds ISOs, templates, and backups, and local-lvm, which holds your actual VM and container disks. New users see local-lvm sitting at 80% full, assume it's some kind of cache, and remove it from Datacenter → Storage to "clean things up."

That single click detaches the storage that your running VMs depend on. Existing disks don't get deleted from the underlying LVM volume group immediately, but Proxmox loses track of them, and any VM trying to write to that disk starts throwing I/O errors.

The fix is simple once you know it: leave local-lvm alone. If you're actually low on space, check what's eating it with pvesm status and lvs, and either add a second disk, extend the volume group, or move a few large VM disks off to different storage instead of touching the pool your VMs boot from.

Mistake 2: Never switching off the Enterprise repository

Every fresh Proxmox VE install ships with the Enterprise repository enabled by default, and that repository requires a paid subscription key to actually pull updates from. If you don't have one — and most homelab users don't — running apt update gives you a wall of 401 errors and nothing installs.

We've got a full walkthrough of this specific fix elsewhere on the site, so I won't repeat every step here. The short version: disable the pve-enterprise source and add the free pve-no-subscription repository instead. It's a two-minute edit, and it's the very first thing worth doing after installation, before you install anything else.

Mistake 3: Doing everything as root, all the time

Proxmox VE logs you in as root@pam by default, and it's tempting to just keep using that account for everything — creating VMs, managing storage, even day-to-day SSH sessions. It works, right up until a typo in a script run as root does something a normal user account never could.

Proxmox has proper role-based access control built in. Creating a second user with a scoped role — say, someone who can start and stop VMs but not touch storage or networking — takes about five minutes under Datacenter → Users and Datacenter → Roles. Even in a single-admin homelab, having a non-root account for day-to-day SSH work means one less way to accidentally nuke something.

Mistake 4: Assuming a single-disk ZFS pool gives you redundancy

ZFS is a filesystem that also acts as a storage manager — it can pool multiple disks together, checksum every block it writes, and catch silent corruption that a traditional filesystem would never notice. A lot of new users pick ZFS during install because they've heard it's "safer," then install it on a single disk and assume they're protected against a drive failure.

They're not. A single-disk ZFS pool (a "stripe" of one) gives you checksums and self-healing for corruption, but if that one disk dies, everything on it is gone, same as any other filesystem. Redundancy comes from the pool layout — mirror (two or more disks holding copies of each other) or RAIDZ (parity across three or more disks) — not from ZFS itself. If you only have one disk, ZFS is still a reasonable choice for its checksumming, just don't expect it to survive a drive failure.

Mistake 5: Enabling the firewall without a rule to match, then losing access

The Proxmox VE firewall is disabled by default at the datacenter level, which is good, because turning it on without preparation is how people lock themselves out of their own web UI. Flip the firewall on at Datacenter → Firewall with no explicit rules, and the default policy on the host can end up blocking port 8006 — the port the web interface itself runs on.

If you want firewalling, add an explicit rule allowing your management IP (or subnet) to reach TCP port 8006 and port 22 for SSH before you enable the firewall, not after. If you do get locked out, you can still reach the host over SSH or the physical console and run pve-firewall stop to shut it off while you fix the rules.

Mistake 6: Resizing a disk in Proxmox and stopping there

The Resize disk option under a VM's Hardware tab grows the virtual disk at the hypervisor level — but it does not touch the partition table or filesystem inside the guest. New users resize a disk from 32 GB to 100 GB, log into the VM, run df -h, and see it's still showing 32 GB total. Nothing is wrong; the extra space is just sitting there unallocated inside the guest.

You need one more step inside the VM: extend the partition (with growpart on Linux, or Disk Management on Windows) and then grow the filesystem on top of it (resize2fs for ext4, xfs_growfs for XFS, or the GUI wizard on Windows). It's two extra commands, but they're easy to forget because the Proxmox side of the job looks complete.

Mistake 7: Not testing a backup until you actually need it

Setting up a backup job in Proxmox is easy — a few clicks under Datacenter → Backup and you've got a nightly vzdump job running. The mistake isn't skipping backups; most people do set them up. The mistake is never actually restoring one until the day a VM is corrupted and they need it to work.

Storage can fill up silently, a backup target can go offline, or a job can quietly fail for weeks without anyone noticing the red X in the task log. Pick one VM you don't mind experimenting with and actually run a restore from a recent backup every so often. It takes ten minutes and it's the only way to know your backups are real.

Mistake 8: Skipping the QEMU Guest Agent, then fighting graceful shutdowns

The QEMU Guest Agent is a small service that runs inside a VM and talks back to the Proxmox host — it's what lets Proxmox ask a VM to shut down cleanly, report its actual IP address in the GUI, and coordinate filesystem freezes during backups. Without it, Proxmox has to fall back to a hard power-off when you click Shutdown, which is basically the same as pulling the plug.

If you skip installing it, you'll notice VMs that take forever to "shut down" (really they're being force-killed after a timeout), an empty IP address field in the summary tab, and backups that aren't filesystem-consistent. It's a five-minute install (qemu-guest-agent package inside the guest, plus enabling the agent option on the VM's hardware tab) that fixes all three.

Commands Explained

Command	What it does
pvesm status	Shows every configured storage on the host, its type, and how much space is used and free.
lvs	Lists LVM logical volumes, useful for checking what's actually consuming space on local-lvm.
pve-firewall stop	Stops the Proxmox firewall service immediately — a lifeline if a bad rule locks you out.
growpart /dev/sda 1	Extends partition 1 on /dev/sda to fill any newly added space, without touching existing data.
resize2fs /dev/sda1	Grows an ext4 filesystem to match the size of its underlying partition after a resize.
xfs_growfs /	Same idea as resize2fs, but for XFS filesystems — note it takes a mount point, not a device.
zpool status	Shows the layout and health of a ZFS pool, including whether it's a stripe, mirror, or RAIDZ.
qm set <vmid> --agent enabled=1	Turns on the QEMU Guest Agent option for a VM so Proxmox knows to expect it.

Common Errors

A few messages show up constantly once you know what to search for:

• "Could not activate storage 'local-lvm', volume group 'pve' does not exist" — usually means local-lvm got removed or the underlying volume group was altered. Check vgs and lvs to see what's actually left on disk.
• "401 Unauthorized" during apt update — the classic sign the Enterprise repository is still enabled without a subscription key attached.
• "TASK ERROR: command 'dm-... ' failed" during a VM start — often a leftover lock or a storage volume that Proxmox thinks is in use by another process; a reboot or qm unlock <vmid> usually clears it.
• VM stuck on "Shutting down" for 30+ seconds before force-stopping — no guest agent installed, so Proxmox is waiting out its ACPI shutdown timeout before giving up.

Troubleshooting

If you've already made one of these mistakes, most of them are recoverable:

Accidentally removed local-lvm from the storage list? Go back to Datacenter → Storage → Add → LVM-Thin and re-add it pointing at the same volume group and thin pool — the underlying data usually survives even though Proxmox temporarily lost track of it.

Locked out by the firewall? Get physical or IPMI/iDRAC console access, log in locally, and run pve-firewall stop, then fix your rules before re-enabling it.

Resized a disk but the guest still shows the old size? You didn't do anything wrong — just finish the job with growpart and resize2fs (or the Windows equivalent) as described above.

Backup job silently failing? Check Datacenter → Backup for the task history and look at the actual log for the failed run — it's almost always a full storage target or an expired NFS/SMB mount.

Best Practices

• Right after install: switch to the no-subscription repository before doing anything else.
• Create at least one non-root user for daily SSH and GUI work.
• Before enabling the firewall, add an allow rule for your management IP on ports 8006 and 22.
• Install the QEMU Guest Agent in every VM as part of your standard build process, not as an afterthought.
• Test-restore a backup on a throwaway VM at least once a quarter.
• Know your ZFS pool layout — run zpool status and confirm it says "mirror" or "raidz" if redundancy actually matters to you.

Frequently Asked Questions

Is Proxmox VE actually free to use?

Yes. The no-subscription repository is fully functional and stable — the paid subscription mainly buys you the Enterprise repository (slightly more conservative update pace) and access to Proxmox's commercial support.

Can I recover a VM disk after deleting local-lvm from the storage list?

Usually, yes, as long as you only removed the storage entry and didn't also run lvremove on the volumes themselves. Re-add the storage pointing at the same volume group.

Do I need ZFS to use Proxmox VE?

No. ext4 on LVM-Thin (the default) works fine for most homelab and small business setups. ZFS is worth it if you want checksumming, snapshots at the storage layer, or plan to use multiple disks in a mirror or RAIDZ.

Why does my VM's IP address show blank in the Proxmox summary tab?

That field is populated by the QEMU Guest Agent. If it's not installed and enabled inside the VM, Proxmox has no way to ask the guest for its address.

How often should backups actually run?

For most homelabs, nightly is plenty. For anything you'd genuinely be upset to lose — a small business file server, say — pair nightly backups with more frequent snapshots if your storage supports them.

Conclusion

None of these mistakes are exotic, and none of them mean you're bad at this. They're just the sharp corners that Proxmox VE doesn't warn you about up front. Fix the repository, leave local-lvm alone, add a non-root user, and actually test a restore once — do those four things and you'll have already sidestepped the mistakes that cause the most support forum posts.

The rest comes with time. Proxmox rewards a bit of caution early on, and after your first month or two of running it, most of this becomes second nature.