What you're actually choosing

You run a handful of services at home. A media server, a reverse proxy, maybe a database you don't want on your laptop. At some point you stop installing things directly on one machine and start thinking in terms of guests.

That's the moment Proxmox enters the picture. Not because it's the only option, but because it's the one most people land on after a weekend of reading forum threads.

Proxmox VE is a Debian-based hypervisor. It ships as a complete install image, takes over the whole disk, and gives you a web interface on port 8006. The current stable line is 8.x, built on Debian 12. Version 9 is on the way with Debian 13 underneath, so if you're installing today, check which release you're pulling before you wipe a disk.

The thing that makes Proxmox interesting is that it does two kinds of virtualization at once. KVM for full virtual machines, where each guest has its own kernel. And LXC for containers, where guests share the host kernel and use a fraction of the memory. You get both from the same dashboard. That's not a small thing.

What you're actually choosing

If you've looked at alternatives, you've probably seen VMware ESXi, XCP-ng, or plain libvirt on a Debian box.

ESXi is polished and has been the default in enterprise for two decades. It's also been through a licensing earthquake since Broadcom bought VMware, and the free tier is a shadow of what it was. If your employer pays for it and you have support contracts, that's a different conversation than the one you're having at home.

XCP-ng is the open source successor to XenServer. It's solid, has a commercial backer, and the Xen hypervisor has a security record that's hard to argue with. The tradeoff is a smaller community and fewer tutorials when something goes sideways at 11pm.

Plain libvirt with KVM on Debian or Ubuntu is the minimal path. You get exactly what you install, no web UI unless you add one (Cockpit, Virt-Manager, Kimchi), and you own every decision. It's more work and it teaches you more. Some people want that. Most don't, once they have three VMs and a storage pool to keep straight.

Proxmox sits between those. It's opinionated enough to be usable on day one and open enough that you can drop to a shell and do anything. The cost is that you're adopting its opinions. Its storage model, its cluster model, its backup format.

The storage model is where people get stuck

Proxmox separates storage into named locations, each with a list of content types it's allowed to hold. ISO images, VM disks, container templates, backups, snippets. You manage them with `pvesm`.

```bash pvesm add dir backup-store --path /mnt/backup --content backup,iso pvesm set backup-store --content backup,iso,vztmpl pvesm status ```

That last command is the one you'll run most. It tells you which storages exist, how full they are, and whether they're active.

The reason this trips people up is that Proxmox won't let you put a VM disk on a storage that isn't marked for `images`. You'll create a storage, try to make a VM, and wonder why the dropdown is empty. It's not a bug. It's the content-type system doing its job.

If you want to free a specific file, `pvesm free local:iso/archlinux-2025.08.01-x86_64.iso` removes it. To drop a whole storage definition, `pvesm remove backup-store`. Neither touches the underlying data on disk, which is either reassuring or alarming depending on how you read it.

Containers versus VMs, and when the line matters

LXC containers start in under a second and idle at a few megabytes of RAM. A Debian container with a web server uses less memory than the browser tab you're reading this in.

```bash pct list pct create 100 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst --rootfs local-lvm:4 --memory 512 pct start 100 pct enter 100 ```

That creates a container with 4GB of disk and 512MB of RAM. You can grow the disk later without rebooting:

```bash pct resize 100 rootfs 20G ```

The catch is that LXC containers share the host kernel. You can't run a different kernel inside one, and you can't run Windows in one. If you need either of those, you need a VM.

VMs are heavier. A minimal Debian VM wants 1GB of RAM just to be comfortable, and booting takes ten seconds instead of one. In exchange you get a real kernel boundary, hardware passthrough, and the ability to run anything that runs on x86.

The honest rule: containers for services you control, VMs for everything else. If you're not sure which side of the line you're on, you're on the VM side.

Clustering is where the complexity budget gets spent

A single Proxmox node is easy. Add a second and you're in cluster territory, and cluster territory has opinions.

```bash pvecm create homelab pvecm add 192.168.1.11 pvecm status ```

That's the whole ceremony. What it buys you is live migration, a shared view of all guests, and quorum-based decisions about which nodes are alive.

What it costs you is a dependency on quorum. With two nodes, if one goes down, the surviving node loses quorum and stops being able to make changes. You need a third vote, either a full node or a lightweight qdevice. This is the single most common way people break their homelab cluster.

If you're running one node, don't cluster it. There's nothing to gain and a lot to lose. `pvecm delnode` removes a node from a cluster, but only if the cluster still has quorum, so plan your exit before you need it.

Firewall and API: the parts you'll ignore until you need them

`pve-firewall` compiles rules from a set of config files and applies them at the datacenter, node, and guest level.

```bash pve-firewall status pve-firewall compile pve-firewall simulate ```

The `simulate` subcommand is underrated. It tells you how a given packet would be handled without changing anything live. If you've ever locked yourself out of a firewall by pushing a bad rule, you'll appreciate it.

`pvesh` is the API from the command line. Every path in the web interface is a path here.

```bash pvesh get /nodes pvesh get /nodes/pve/qemu pvesh ls / pvesh usage /pools ```

If you're scripting anything, this is where you live. The web UI is a thin layer over the same API, so anything you can click, you can call.

The desktop clients are a separate decision

Field Monitor is a GNOME remote-desktop client that speaks RDP, SPICE, and VNC. It connects to Proxmox VMs directly and can start, stop, and restart them from the client. If you're on a GNOME desktop and you want one app for all your VM consoles, it's a reasonable pick.

Snowglobe is a lighter viewer. It talks to running QEMU instances over DBus, supports keyboard, mouse, and multi-touch, and does nothing else. It's GPL-3.0-or-later, maintained by Bilal Elmoussaoui, and installs from Flathub:

```bash flatpak install flathub com.belmoussaoui.snowglobe ```

Neither is required. The web console in Proxmox works fine for occasional use. These matter when you're in a VM all day and want a native window.

What it costs you

Proxmox is free to install and use. The subscription is optional and buys you the enterprise repository, which is more tested than the no-subscription repo you get by default. Running without a subscription is legal and common. You'll see a nag dialog on login and you'll pull updates from a repo that occasionally ships a regression.

The real cost is learning its model. Storage content types, cluster quorum, the difference between a node and a guest, where backups live and how retention works. None of it is hidden, but none of it is optional either.

If you want a hypervisor that you install and forget, Proxmox will fight you on that. If you want one that you can grow into, that lets you start with one node and end with three and a shared storage pool, it's the shortest path from here to there.

The version you install today will look different in two years. Check `pveversion -v` before you file a bug, and read the release notes before you upgrade a cluster. The upgrade path from 8.x to 9.x will involve Debian 12 to 13, and that's not a thing you do on a Tuesday afternoon with production running.