Thanks to its bountiful set of virtualization features and support for even the most underpowered x86 machines, Proxmox is a terrific home lab platform for tinkering enthusiasts. In fact, I daresay it’s the best way to start your descent into the home server rabbit hole, as Proxmox has a plethora of first-party manuals, community-created guides, and documentation to help you deploy essential virtual machines and containers.

But considering that home labs are meant to be experimentation environments where you learn by breaking things, you’re bound to make a few mistakes along the way. Heck, I still end up with the occasional botched experiment even after spending years with my ever-evolving Proxmox servers. So, I’ve compiled a collection of common pitfalls you could encounter during your early Proxmox days.

Staying on Enterprise repositories

You should switch to No-Subscription repos after installing PVE

When you set up Proxmox on a host machine, the installation wizard adds the Enterprise and Ceph Squid Enterprise repositories as the default sources of packages. But since these repos aren’t accessible unless you drop a premium on a PVE license, you’d run into errors if you update the Proxmox node or install new packages that rely on these repositories. Luckily, Proxmox supports free repositories that are more than usable for the average home labber.

All you have to do is head to the Repositories section within the Updates menu of your PVE node and disable everything with Enterprise under the Components column. Then, you can use the Add button to enable the No-Subscription repository (and Ceph Squid No-Subscription, if you’re planning to deploy a cluster). Or, you can run the PVE Post Install command from the ultra-useful Helper Scripts repos.

Not keeping backups

Use vzdump when you’re new; switch to PBS once you become a veteran

Your Proxmox home lab may be the ideal testing ground for your DIY experiments, but it’s easy to end up with an inaccessible node if you’re not careful. In fact, a single syntax error in the wrong config file is all you need to lose your virtual guests forever. This paranoia gets exponentially worse as you start configuring useful self-hosted services in LXCs and VMs, as you wouldn’t want to be stuck rebuilding everything from scratch.

Fortunately, there are a handful of ways you can back up the (virtual) inhabitants of your PVE node. When you’ve got a single Proxmox instance, vzdump backups are a great way to ensure your virtual guests remain safe during your tinkering experiments, and you can transfer these files to external storage drives to avoid losing them if (or rather, when) your PVE node goes down. Once you’ve got a collection of virtual guests on your workstation, I recommend going down the Proxmox Backup Server route, as it includes everything from storage-efficient deduplication algorithms and incremental backups to live virtual guest restoration, granular recovery, and remote syncs.

Forgetting about documentation tools and monitoring services

They are a godsend for troubleshooting

Even with a 3-2-1 backup setup comprising local and remote Proxmox nodes, there are certain problems that you can’t solve by reverting your virtual guests to their old states via snapshots. If you’ve got dozens of services deployed across multiple virtual guests, you might have a hard time recalling the right VM and LXC when you’re diagnosing some error. Or, you could end up with a broken application that has been unresponsive for days, and you only notice its pitiful state far too late.

That’s why you’ll often find Proxmox tinkerers relying on a couple of management services. Documentation tools, for example, can retain detailed notes about your Proxmox virtual guests, and you can use them as a reference whenever you encounter problems with your VMs and LXCs. Then you’ve got monitoring services that keep an eye on applications, virtual machines, and (even) the underlying Proxmox node 24/7, and ping you as soon as they detect an error. I use a combination of Trilium Notes and BookStack to maintain records of my Proxmox misadventures, while Pulse keeps an eye on my PVE workstations. Sadly, this introduces another issue…

Running mission-critical virtual guests on your experimentation server

High-availability or standalone nodes: Pick your poison

Let’s say you’ve got your documentation and monitoring services on your primary PVE node. If something untoward were to happen during your DIY projects, you’ll lose access to these services alongside the rest of your virtual guest collection. But the real trouble begins when you start running DNS servers, firewall distros, and other tools that, if rendered offline, can cause Internet issues for all your devices, not just the home lab paraphernalia.

There are a couple of ways to fix this problem. The simple solution (and the one I use) involves deploying another Proxmox node on a cheap mini-PC, x86 SBC, or thin client, and relegating your essential services to this system. That way, your secondary workstation will contain the mission-critical utilities that you need 24/7, while your primary PVE server can act as a safe experimentation lab for DIY projects. Alternatively, you could try deploying a high-availability setup involving multiple Proxmox nodes, though clusters present their own challenges for newcomers.

Clustering when you’re a beginner

Unless you have the hardware and skillset, it’s best to avoid clusters

Let me preface this section by adding that clusters are a fun aspect of Proxmox setups, and if properly configured, can ensure your LXCs and VMs get migrated to other nodes when one of them goes down. Unfortunately, clusters require a lot of time and monetary investment, especially once you opt for high-availability setups. For a standard cluster, you’ll need three nodes and distributed storage provisions, so you’ll have to drop a pretty penny on the extra hardware.

Well, you could add a QDevice and rely on a NAS share instead of configuring Ceph on multiple drives, but removing the cluster nodes will be a pain – to the point where it’d be easier to wipe everything and start from scratch. Yeah, I speak from experience. ZFS replication is the easiest HA method, though it's possible to lose some work if your node fails before a replication task is complete.

Heck, I ran my first cluster just for the bravado points, not because I necessarily needed one. I currently have a low-power PVE cluster created from cheap systems, but I only use it to train my DevOps and sysadmin skills. Isolating essential services on a secondary Proxmox node and backing them up at regular intervals is more than enough for my needs – and I’m pretty sure that’s the case for all but the most hardcore tinkerers.