Proxmox Deep Dive Part 1: Architecture and Installation

Lab Environments Part 2 covered Proxmox at survey depth, alongside ESXi and VMware Workstation, as one of three hypervisor foundations. This series goes the other direction: every subsystem of Proxmox VE itself, in enough depth to actually run it well, using the same pve host behind the Sn1per, BloodHound, and FortiManager lab work as the running example throughout.

What Proxmox VE actually is.

Proxmox VE is a Debian Linux distribution with a management layer on top, not a custom OS built from scratch. Proxmox VE 9.2 runs on a Debian 13 “Trixie” base. That matters practically: the underlying system is a real, full Debian install, apt works the way it always does, and anything that runs on Debian can, with care, run on the Proxmox host itself alongside the hypervisor role.

Two virtualization technologies sit on top of that base, and Proxmox treats both as first-class rather than favoring one. KVM (Kernel-based Virtual Machine) provides full hardware virtualization, each VM gets its own kernel, its own complete OS, genuine isolation at the hardware level. LXC provides OS-level containers, processes running directly on the host kernel inside isolated namespaces, no separate kernel, far less overhead. Part 6 covers the actual decision between the two in depth; the point here is that Proxmox is built around both, not a VM tool with containers bolted on.

pmxcfs, the piece that makes clustering possible later.

Proxmox’s configuration lives in /etc/pve, which looks like a normal directory but is actually a FUSE-mounted filesystem backed by pmxcfs (Proxmox Cluster File System). Every node in a cluster runs pmxcfs, and it keeps /etc/pve synchronized across every node in real time using corosync underneath. Writing a change to any node’s /etc/pve propagates it to every other node in the cluster, which is exactly how the web GUI can show the same cluster-wide view from any node’s IP address. Part 7 covers corosync and quorum in depth; the relevant fact for now is that this synchronization mechanism exists from a single-node install onward, it’s just idle until a second node joins.

The web GUI and the API are the same thing, twice.

Every action available in the Proxmox web GUI is a call against the same REST API (pveproxy, listening on 8006) that Terraform, Ansible, and pvesh on the command line all use. Nothing in the GUI has privileged access the API doesn’t. Part 12 goes deep on the permission model and automation; the architectural point here is that there’s no separate “automation-friendly” surface bolted on afterward, the GUI is a client of the same API everything else uses.

The subscription model, in more depth than the overview series covered.

Lab Environments Part 2 already established the headline: the feature set is identical with or without a subscription, HA, live migration, Ceph, the firewall, none of it is gated. What that overview didn’t cover is the repository structure itself. Three repositories exist: Enterprise (paid subscription required, the most conservatively tested packages, recommended for production), No-Subscription (free, no key required, the same packages after a shorter soak period, appropriate for home labs and non-critical use), and Test (bleeding-edge, unstable by design). A fresh install defaults to the Enterprise repository and will fail to update without either a subscription key or manually switching to No-Subscription, which is the first thing worth doing on a homelab install specifically to avoid update errors on day one.

Installation.

Two paths exist. The ISO installer is the common route for a fresh piece of hardware, it partitions the disk (with ZFS, LVM, or a plain filesystem as options directly in the installer, covered in depth in Part 2 and Part 3), sets up networking with a single default bridge, and produces a running node in under twenty minutes. The alternative is installing Debian first and adding the Proxmox VE packages on top, which trades installer convenience for exact control over the base partitioning and package set, useful when Proxmox needs to coexist with an existing Debian configuration rather than owning the whole disk.

The initial network configuration matters more than it looks like it should: the installer creates one Linux bridge (vmbr0) bound to the physical NIC, and every VM and container’s virtual network interface attaches to a bridge, never directly to a physical NIC. That single bridge is exactly what later gets split into per-lab isolated bridges, the same vmbr-sniperlab and vmbr-msflab pattern already running on the pve host behind this site’s Sn1per and BloodHound work. Part 4 covers bridges, VLANs, and the newer SDN stack in full.

Where this series goes next.

Part 2 starts at storage, because it’s the decision that constrains almost everything downstream, whether live migration is possible, whether HA is possible, how VM disk performance actually behaves under load, before a single VM ever gets created.