Proxmox or bare metal? What virtualising a home server actually costs

The usual framing is that virtualisation costs you a few percent of CPU performance. That number is real and almost irrelevant. The costs that matter are structural, and so are the benefits.

What you actually gain

Snapshots before you break something. This is the honest headline feature. Taking a snapshot, attempting an upgrade, and rolling back in seconds when it fails changes how willing you are to experiment — and a home server is mostly a place where you experiment.

Isolation between services. A misbehaving application cannot take down the others, and a compromised one is contained to its own guest.

Rebuilds without the install. Replacing a service becomes deleting a container and restoring a backup, not reinstalling an operating system and remembering what you configured eighteen months ago.

Running things that disagree. Two services wanting incompatible versions of the same dependency stop being a problem.

What it costs, specifically

Hardware passthrough is the real tax

Anything needing direct hardware access becomes a project. A GPU for transcoding or inference, a USB device, an HBA for disks — each has to be detached from the host and handed to a guest, which requires IOMMU support, groups that separate cleanly, and sometimes blacklisting a driver so the host does not claim the device first.

When it works it is invisible. When the IOMMU groups do not separate the way you need, the honest answer is often that this hardware cannot be passed through on this motherboard, and you discover that after buying it.

# do the groups separate usefully?
for d in /sys/kernel/iommu_groups/*/devices/*; do
  n=${d#*/iommu_groups/}; echo "group ${n%%/*}: $(lspci -nns ${d##*/})"
done | sort -V | head -30

If the device you want shares a group with the storage controller, passing it through takes the disks with it.

Every problem gains a layer

A service is unreachable. Is it the service, the guest's network, the virtual bridge, the host's interface, or the firewall on either side? Each step is simple; there are now five of them, and this is the cost you pay on every debugging session rather than once at install.

ZFS memory behaviour surprises people

Proxmox defaults to ZFS, and ZFS caches aggressively in ARC. On a machine where you also intend to allocate most of the memory to guests, the two compete, and the symptom is a host that feels fine for a week and then does not.

# what ARC is currently holding, and its target
arc_summary | head -20
# cap it: here, 8 GiB
echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf
update-initramfs -u

Decide the split deliberately rather than discovering it.

The backup you have not restored is not a backup

Proxmox makes backups easy enough that people stop thinking about them, which is exactly when they stop working. A backup job that has succeeded for six months and has never been restored is an untested assumption.

Restore one, to a new VM ID, and boot it. Quarterly is enough. This is the single most valuable habit in the whole arrangement, and it is the one most often skipped.

Containers or virtual machines?

Proxmox offers both, and the choice matters more than the host decision for most workloads.

LXC containers share the host kernel. Near-zero overhead, start in under a second, and memory is used rather than reserved — a container given 4 GB that uses 500 MB leaves the rest available. For ordinary Linux services this is almost always the right choice.

Virtual machines run their own kernel. Necessary for a different operating system, for anything needing its own kernel modules, for Docker-in-guest without friction, and for clean passthrough. The cost is real memory reservation and slower boots.

The practical split: containers by default, VMs when something in the list above forces it.

When bare metal is the better answer

Three cases, and they are more common than virtualisation enthusiasts suggest.

One workload owns the machine. A dedicated NAS, or a box that exists to run a single demanding service. Virtualising it adds complexity and buys nothing — there is nothing to isolate it from.

The hardware resists passthrough. If the thing you bought the machine for cannot be passed through cleanly, run it on the host.

You want to stop thinking about the server. The hypervisor is another thing to patch, upgrade and occasionally troubleshoot. If the appeal of the machine is that it quietly works, a plain Linux install with containers on top is a legitimate and much smaller surface.

That last option — bare metal Linux running Docker or Podman — covers a great deal of what people reach for Proxmox to do, with one layer fewer. Snapshots are the thing it cannot give you, and filesystem-level snapshots cover part of even that.

A decision procedure

1. List what the machine will run. One service, or several that are unrelated?
2. Identify anything needing direct hardware. GPU, HBA, tuner, USB device. Check IOMMU groups before buying if you can.
3. Ask how often you will change things. Frequent experimentation is the strongest argument for snapshots; a static setup is the strongest argument against the extra layer.
4. Decide the memory split between host caching and guests, and cap ARC if using ZFS.
5. Commit to restoring a backup quarterly — or accept that you are running without one.

The honest summary

Virtualise when the machine runs several unrelated things, when you change them often, or when isolation genuinely matters. Stay on bare metal when one workload owns the box, when the hardware fights passthrough, or when you want the fewest moving parts. Neither is the sophisticated answer — the sophisticated answer is the one matching how you will actually use the machine, and for most home servers running three or four stable services, that is closer to bare metal than the internet suggests.