Running Proxmox on bare metal: a practical setup guide

Proxmox VE is the foundation of my homelab. Every service — the Samba AD controller, Authentik, Forgejo, TrueNAS, the monitoring stack — runs as either an LXC container or a KVM virtual machine on a single Proxmox node. One physical machine, a clean web UI, a full REST API, and the flexibility to run anything from a 64MB Alpine container to a full Windows Server VM.

This article covers the practical decisions behind a useful Proxmox setup: disk layout, network configuration, LXC versus KVM, and the small adjustments that make day-to-day operation smooth.

Hardware considerations

Proxmox runs on any x86-64 machine, but a few things make a meaningful difference:

ECC RAM — Proxmox is often used with ZFS, and ZFS is adamant about ECC. Without it, silent memory corruption can propagate to your storage. For a homelab this is a recommendation, not a hard requirement, but if you're using ZFS RAIDZ you should take it seriously.
Multiple disks — at minimum, separate the Proxmox OS drive from your VM/container storage. Two NVMe slots or a NVMe + SATA combination works well.
IOMMU support — if you plan to pass through a GPU or NIC to a VM, check that your CPU and motherboard support IOMMU (Intel VT-d / AMD-Vi) and that it is enabled in the BIOS.
Network ports — a second NIC is useful for separating management traffic from VM traffic, and essential if you want to bond links or create a dedicated storage network.

Installation

Proxmox installs from a bootable ISO onto a dedicated drive. During installation:

Use ZFS (RAID1) for the OS drive if you have two identical drives for the system — it gives you OS-level redundancy and snapshot support on /var/lib/pve
Use ext4 on a single drive if simplicity matters more than redundancy for the OS
Set a strong root password; this is the administrative account for the entire hypervisor

After first boot, disable the enterprise repository and enable the no-subscription repository if you are not purchasing a Proxmox subscription:

# /etc/apt/sources.list.d/pve-enterprise.list
# Comment out the enterprise line, then add:
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
apt update && apt dist-upgrade

Disk layout

I separate storage concerns into three tiers:

| Tier | Device | Purpose | |---|---|---| | OS | NVMe (single or ZFS mirror) | Proxmox itself, VM configs | | Fast storage | NVMe or SSD ZFS pool | VM disks, databases, containers | | Bulk storage | HDD ZFS RAIDZ2 | Backups, media, NFS shares |

The fast pool uses a mirrored pair of NVMe or SATA SSDs — IOPS matter for running databases and containers. The bulk pool uses RAIDZ2 (equivalent to RAID6) across four or more drives, accepting lower IOPS in exchange for capacity and double-drive fault tolerance.

Add both pools to Proxmox under Datacenter → Storage after creation with zpool create.

Network design

The default Proxmox install creates a single Linux bridge (vmbr0) on the first physical NIC. For a homelab this is fine to start, but VLAN-aware bridging unlocks proper network segmentation:

# /etc/network/interfaces — VLAN-aware bridge
auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports enp3s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

With bridge-vlan-aware yes, each VM and container can be tagged to a specific VLAN from the Proxmox UI. The physical NIC connects to a managed switch trunk port. pfSense handles inter-VLAN routing and firewall rules.

LXC containers vs KVM virtual machines

This is the most consequential daily decision in Proxmox. The rule I follow:

Use LXC when:

The workload is a Linux service (Nginx, databases, Git, monitoring agents)
You want minimal overhead — an LXC container starts in under a second and uses no extra memory for a kernel or init system
You need dense packing — ten LXC containers on a node that could host three KVM VMs

Use KVM when:

The workload requires its own kernel (custom kernel modules, eBPF, io_uring-heavy workloads)
You are running Windows
You need hardware passthrough (GPU, USB controller, NIC)
You want stronger isolation guarantees between tenants

In practice: Samba AD, Authentik, Forgejo, NGINX, monitoring stack — all LXC. Windows Server, any VM requiring GPU passthrough — KVM.

Snapshots and backups

Proxmox has built-in snapshot and backup tooling. Snapshots are cheap on ZFS — creating one takes milliseconds and uses copy-on-write to track changes. Use them before any major change:

# From the CLI
pct snapshot <vmid> pre-upgrade --description "Before apt dist-upgrade"
qm snapshot <vmid> pre-upgrade

For backups, Proxmox Backup Server (PBS) is the purpose-built companion tool. It deduplicates across backups and across VMs, making it far more storage-efficient than raw dump backups. A PBS instance running as an LXC container on the same node can back up all other containers and VMs to the bulk ZFS pool — or to an off-site location via the WireGuard tunnel.

Post-install checklist

[ ] Enable IOMMU in BIOS and kernel cmdline (intel_iommu=on or amd_iommu=on)
[ ] Configure NTP (chronyc sources should show a reachable server)
[ ] Set up Proxmox Backup Server and schedule daily backups
[ ] Create a non-root PAM user for daily management; use root only when necessary
[ ] Join the node to your Samba AD domain for centralised authentication
[ ] Configure email alerts (Datacenter → Notifications) so you hear about failed backups and ZFS scrub errors

Stack

Proxmox VE · ZFS · LXC · KVM · pfSense · Proxmox Backup Server