Proxmox

Sooner or later almost every Proxmox host grows a USB device that needs to talk to one specific guest. A Zigbee or Z-Wave radio for Home Assistant, a TV tuner for a media server, a serial adapter for a UPS, a security dongle for some old piece of software that still checks for one. Getting that device into the right VM or container is usually simple the first time and then mysteriously stops working after the next reboot, because the setup that worked was tied to something that wasn’t actually stable. Here’s how passthrough actually works for both VMs and LXCs, and where the stability problem comes from. ...

Every Proxmox host ships with snapshots built in, and they’re so easy to take that it’s tempting to treat them as your backup strategy. Click “Snapshot” before a risky change, click “Rollback” if it goes wrong, done. That workflow is genuinely useful, and you should use it. It is also not a backup, and conflating the two is one of the more common ways homelab operators discover, at the worst possible moment, that they had less protection than they thought. ...

Proxmox ships with a real, iptables-backed firewall built into the platform, and most homelabs never turn it on. It’s not enabled by default at any level, so unless you’ve gone looking for it in the UI, there’s a good chance your VMs and containers are sitting behind nothing but whatever VLAN segmentation you’ve set up, if any. That’s often fine. It stops being fine the moment you’re running something internet-facing, or you want one VM to be reachable only from your management network and nowhere else, or a compromised guest shouldn’t be able to freely talk to everything else on its VLAN just because they share a broadcast domain. This is what the built-in firewall is actually for, and it’s worth understanding the shape of it before you flip it on. ...

The Proxmox-vs-ESXi comparison on this site already covers why so many homelabbers are moving off VMware since the Broadcom licensing changes gutted the free ESXi tier. This one skips the “should I switch” question and gets into the part that actually trips people up: what breaks when you move a real VM from ESXi to Proxmox, and how to get ahead of it instead of debugging a guest that won’t boot at 11pm. ...

Every homelab operator hits the same wall eventually: you need a fifth Ubuntu VM for some new service, and the thought of walking through another OS installer, setting the hostname, adding your SSH key, and running updates makes you want to just leave the last one running forever instead. Cloud-init templates fix this. Build the template once, and every new VM after that is a clone plus a few lines of config, done in under a minute instead of fifteen. This is the same workflow cloud providers use to spin up instances on demand, and Proxmox supports it natively, no extra tooling required to get the basics working. ...

Ceph shows up in every “how do I get real shared storage for my Proxmox cluster” conversation, and for good reason, it’s the one option that’s fully native, fully integrated into the Proxmox web UI, and genuinely production-grade software running underneath some very large real-world deployments. It’s also the option most likely to leave a home cluster worse off than before you added it, because Ceph’s design assumptions (plenty of nodes, plenty of network, plenty of dedicated drives) don’t bend easily to a 3-node home lab built from whatever hardware was on hand. Here’s what Ceph actually is inside Proxmox, what it needs to run well, and when it’s the right call instead of the simpler alternatives. ...

Buying the right GPU for your homelab is one decision. Getting Proxmox to actually hand that GPU to a VM or container is a separate one, and it’s where a lot of people get stuck, because Proxmox actually supports two completely different ways to do it, and picking the wrong one for the job means either a fight with IOMMU groups you didn’t need to have, or a container that can’t do what you needed a full GPU for. Here’s what each path actually requires, and how to pick between them. ...

Proxmox makes joining a second node to a cluster look almost too easy, one command on the joining node and you’re done, centralized management across both boxes in the web UI. What that quick setup doesn’t make obvious is how much more you need to build on top of it before a cluster gives you the thing most people actually want from one: automatic failover when a node dies. This is the gap that catches people, they cluster two or three nodes, assume they now have redundancy, and find out during an actual outage that a VM doesn’t restart anywhere because nothing was wired up to make that happen. Here’s what clustering actually gets you, what it costs, and an honest read on whether it’s worth doing in a home setup versus running solid standalone nodes. ...

Proxmox sets up a single bridge during install, vmbr0, hands every VM and container a virtual NIC on it, and most homelabs never touch networking again after that. That’s fine right up until you want to keep your NAS traffic off the same broadcast domain as a VM you don’t fully trust, or you add a second NIC and aren’t sure whether to bond it or split it out, or you’re staring at a VLAN dropdown in the VM hardware tab with no idea what happens if you fill it in wrong. None of this is complicated once you see the shape of it, but Proxmox’s networking config is also one of the few places where a bad change locks you out of the box that’s hosting the config, so it’s worth understanding before you’re mid-edit over SSH. ...

Proxmox hands you two completely different ways to run a workload, LXC containers and full VMs, and the “New CT” and “Create VM” buttons sit right next to each other in the UI like the choice barely matters. It matters. Pick the wrong one for a given workload and you’ll either waste resources you didn’t need to waste, or hit a wall six months in when something a container fundamentally can’t do turns out to be exactly what you needed. Here’s how to actually decide, workload by workload, instead of defaulting to whichever one you set up first. ...