Proxmox VE Homelab Roadmap: What to Set Up, In What Order

Most Proxmox VE problems are not caused by the step someone is currently stuck on. They are caused by a decision made three steps earlier, usually in the installer, usually in under ten seconds. Picking ext4 when you wanted ZFS, sizing a zvol wrong, or filling a standalone box with guests before deciding it should join a cluster are all cheap to get right on day one and genuinely painful to undo later.

This page is the map. It is not another install walkthrough: it lays out the build order, flags the hard-to-reverse choices, and points at the deep guide for each stage.

What Proxmox VE actually is

Proxmox VE is a Debian-based hypervisor distribution that bundles two different virtualization technologies behind one web interface and one API. KVM/QEMU runs full virtual machines with their own kernel. LXC runs system containers that share the host kernel. On top of that sit a clustered configuration filesystem (pmxcfs, mounted at /etc/pve), Corosync for cluster membership, an integrated firewall, a backup engine, and optional Ceph packages.

Two consequences matter from the start. First, it ships its own kernel rather than the stock Debian one, which is why hardware support is generally better than plain Debian and why you take kernel updates from Proxmox repositories, not Debian’s. Second, /etc/pve is a replicated database, not a normal directory. Once a node is in a cluster, that config is shared, which is exactly why cluster join is a one-way door.

The decisions that are expensive to reverse

Work through these before you touch the installer.

Boot and storage filesystem. The installer offers ext4 or XFS with LVM-thin, ZFS in several RAID levels, and Btrfs as a technology preview. This is not a cosmetic choice. An ext4 install gives you a local-lvm thin pool; a ZFS install gives you local-zfs backed by zvols, plus native snapshots, checksums, and send/receive replication between nodes. Changing your mind later means a reinstall or a full guest migration. The trade-offs, including why ZFS wants more RAM, are in Proxmox ZFS storage setup.

volblocksize on ZFS. For zvol-backed VM disks, volblocksize can only be set at creation. Changing it means destroying and recreating the disk, and getting it wrong on a RAIDZ pool costs permanent space amplification.

Cluster membership. A node being joined to a cluster must not hold any guests, because guest IDs could collide, and its /etc/pve is overwritten by the cluster’s copy. Removal is documented, but the removed machine has to be wiped and reinstalled before it can ever rejoin. Decide whether this box is standalone or cluster member before you build guests on it.

Hostname and management IP. Both are woven through certificates, Corosync configuration, and storage definitions. Changing either after clustering is a documented procedure rather than a quick edit.

Everything else on this page is comparatively easy to revisit.

Phase 1: one node you can trust

Start with hardware that actually supports what you plan to do. The published baseline is modest: a 64-bit CPU with virtualization extensions, roughly 2 GB of RAM for the host and Proxmox services before any guest memory, and a fast, reasonably endurable boot device. The real constraints show up later; Proxmox VE hardware requirements covers where the recommended spec diverges from the minimum, including why ECC matters less here than on a dedicated NAS. If you intend to pass through a GPU or an HBA, you need VT-d or AMD-Vi and a board with usable IOMMU grouping, and that is a purchase decision, not a config decision.

Then install. How to install Proxmox VE walks the ISO through to first boot, including the filesystem choice above.

Immediately after first boot, do three things:

1. Fix the repositories. A fresh install enables the enterprise repository, which rejects you without a subscription key, so apt update errors on it and Proxmox updates never arrive. Switch to the no-subscription repository, which Proxmox supports for testing and non-production use, per the Proxmox package repositories documentation.
2. Check the ARC if you installed on ZFS. Left alone, OpenZFS claims a large share of RAM for cache, which starves guests on a hypervisor. Proxmox installers have written a zfs_arc_max of 10 percent of installed RAM, capped at 16 GiB, since Proxmox VE 8.1, but hosts upgraded from older releases keep the much larger upstream default. Read /etc/modprobe.d/zfs.conf rather than assume. Proxmox’s sizing rule is roughly 2 GiB base plus 1 GiB per TiB of pool storage.
3. Prove the backup path on a throwaway guest. vzdump backs up guests, not host configuration, so an empty node has nothing to protect yet. Build one disposable VM, back it up, restore it, and delete it while the stakes are zero.

Phase 2: networking before guests

Networking is the most common source of “I locked myself out” incidents, and it is far easier to design on an empty node. You need vmbr0, when to make a bridge VLAN-aware versus creating per-VLAN bridges, and how a guest NIC’s tag maps to what the switch expects. Proxmox network bridges and VLANs covers Linux bridge versus Open vSwitch and how to apply changes without cutting your own management link.

The firewall is worth enabling early and understanding properly, because Proxmox has three levels (datacenter, node, guest) and rules quietly do nothing until every enable flag in the chain is set. That fools a lot of people into thinking they are protected. Proxmox firewall configuration covers safe defaults that will not lock you out of the web UI on port 8006.

Phase 3: pick the right guest type, then stop hand-building

For each workload, decide LXC or VM. Containers share the host kernel, boot in seconds, and carry almost no memory overhead. Virtual machines bring their own kernel and are the answer whenever you need a non-Linux OS, a different kernel, PCI passthrough, or stronger isolation. Proxmox LXC vs VM covers privileged versus unprivileged containers and the cases where passthrough forces your hand.

Once you are creating your third VM by hand, build a template instead. Proxmox cloud-init templates shows how to import a distribution cloud image once and clone configured guests in seconds, with SSH keys, network settings, and hostname injected at boot.

Passthrough is the classic late-stage surprise. IOMMU groups are fixed by your board and CPU rather than by anything you configure in Proxmox, and some GPUs will not reset cleanly between guest reboots. Proxmox GPU passthrough covers VFIO binding and the AMD reset problem before you buy the card.

If your storage lives on a separate box, read Proxmox VE vs TrueNAS SCALE for which platform belongs on bare metal, and why HBA passthrough is not optional in that design.

Phase 4: backups you have actually restored

Snapshots are not backups. They live on the same pool as the data and disappear with it. Proxmox snapshots explained covers what they are genuinely good for and which storage types support them at all; how vzdump’s stop, suspend, and snapshot modes differ in downtime and consistency is in Proxmox backup strategy.

Once you have more than a couple of guests, Proxmox Backup Server is a real upgrade: chunk-level deduplication and incremental backups make daily retention far cheaper than repeated vzdump archives, and verify jobs catch bit rot in the backup store itself. Whatever you run, schedule a real restore test. A backup that has never been restored is a hypothesis.

Phase 5: clustering, then high availability

Cluster only when you have a reason: live migration, one management pane, or shared configuration. Quorum arithmetic decides everything here. A cluster needs a majority of votes to be writable, which is floor(n/2) + 1. Two nodes is the trap: two votes means quorum requires both, so a single node failure freezes /etc/pve on the survivor. Three nodes, or two nodes plus a QDevice on a Raspberry Pi or NAS, is the working minimum. Corosync also wants a dedicated low-latency link, which is a cabling decision. See Proxmox cluster setup, and the Proxmox port reference for the corosync and live-migration ranges that must stay open between nodes. To sanity-check node count and failover headroom before buying, use the Proxmox cluster sizer.

High availability is a separate, stricter layer on top. It needs shared storage or ZFS replication, and it fences unhealthy nodes with a hardware or software watchdog, so a node that loses quorum resets itself with your guests on it. Replication-based HA also loses everything written since the last sync. Proxmox high availability covers what HA genuinely protects against and what it cannot save you from.

Shared storage at cluster scale usually means Ceph. The hard floor is three nodes, pools default to size 3 with min_size 2, and Proxmox asks for at least 10 Gbps dedicated to Ceph traffic. Three nodes work but run degraded through every maintenance reboot, so build five if resilience is the point. Proxmox Ceph vs ZFS replication covers when that operational cost is worth paying and when scheduled ZFS replication is the better answer.

When things break

The failures that bite hardest are boring and repetitive: a full root filesystem from backups dumped to local, lost quorum after a switch reboot, guests that will not start after a storage rename. Proxmox troubleshooting is the page to bookmark now rather than search for at 2 a.m.

Arriving from VMware rather than from nothing? Start with Proxmox VE vs VMware ESXi instead, which covers where feature parity is genuine and where there is no equivalent.

Suggested reading order

For a new single node: hardware requirements, install, ZFS storage, networking, firewall, ports, LXC vs VM, snapshots, cloud-init templates, backup strategy.

For an existing node you want to harden: backup strategy, Backup Server, firewall, ports, troubleshooting.

For scaling out: cluster setup, high availability, Ceph versus ZFS replication.

Build in that order and most of the hard-to-reverse decisions land correctly the first time.

Related across the network

• iSCSI Troubleshooting: Login, Timeout and Path Errors — iscsihub.com
• OpenMediaVault NAS Planning: Disks, Filesystems, Shares — openmediavaultlab.com