For several years the EchoLinux lab ran as a collection of separate Debian hosts on dedicated hardware. The move to Proxmox VE happened gradually: first as an experiment to see whether KVM overhead was acceptable, then as a permanent consolidation once it became clear that the flexibility was worth the modest complexity increase. This article covers the reasoning, the practical setup decisions, and where Proxmox surprised us compared to expectations.
What Proxmox VE is
Proxmox Virtual Environment is an open-source hypervisor distribution based on Debian. It ships a web management interface, a command-line toolset, and integrates KVM for full virtual machines and LXC for system containers. The community edition is free; the subscription provides access to the stable package repository (the non-subscription repository is also available and usable but shows a nag in the web UI).
KVM VMs versus LXC containers
This is the most important decision when running Proxmox. The right answer depends on what you are running:
| KVM VM | LXC Container | |
|---|---|---|
| Kernel | Isolated (own kernel) | Shared (host kernel) |
| Init system | Full systemd | Full systemd |
| Overhead | ~100–200 MB RAM minimum | ~20–50 MB RAM minimum |
| Storage | Virtual disk image (qcow2 or raw) | Bind mounts or ZFS dataset |
| USB passthrough | Full QEMU device emulation | Requires cgroup access |
| GPU passthrough | VFIO/IOMMU supported | Not practical |
| Network isolation | Full (separate MAC, separate ARP) | Full (veth pair) |
| Best for | Any OS, GPU workloads, full isolation | Linux services, density |
Our current rule of thumb: run KVM VMs for anything that requires a different kernel (non-Debian, custom patches), any workload doing USB or PCIe passthrough, and anything where you want the strongest possible isolation boundary. Run LXC for the majority of long-running Linux services (web servers, databases, DNS, monitoring), where the memory density advantage is significant and the shared kernel is acceptable.
Initial setup
Installing Proxmox
Download the Proxmox VE ISO from proxmox.com/downloads and boot
from it. The installer is straightforward. On the “management interface”
screen, assign a static IP on your management VLAN. Set a strong root password.
After first boot, add the no-subscription repository and update:
sed -i 's|^deb https://enterprise.proxmox.com/debian/pve|#deb https://enterprise.proxmox.com/debian/pve|' /etc/apt/sources.list.d/pve-enterprise.list cat >> /etc/apt/sources.list <<EOF deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription EOF apt update && apt full-upgrade -y
Storage pools
Proxmox supports several storage backends. For a single-host homelab the common choices are:
- LVM-thin on NVMe: fast, thin-provisioned, good for VM disks. Supports snapshots. Default if you have a single NVMe.
- ZFS: excellent if you have spare RAM (ZFS ARC benefits significantly). Supports native datasets for LXC, ZVOL for VMs, built-in scrubbing, and snapshot/send for replication. Recommended if you have 4+ GB of RAM to spare for ARC.
- Directory on a bind-mounted ext4/xfs partition: simple, works for ISO storage and backups. Slower for VM disks.
Create a ZFS pool if using ZFS:
# Single disk (no redundancy) for lab use: zpool create -f rpool /dev/nvme0n1 # Two-disk mirror for production: zpool create -f datapool mirror /dev/sdb /dev/sdc # Add to Proxmox storage: pvesm add zfspool local-zfs --pool rpool --content vztmpl,images,rootdir
Networking
Proxmox creates a Linux bridge (vmbr0) over your primary NIC.
For VLAN-aware networking, enable the VLAN-aware option on the bridge and
attach VM and container NICs to specific VLANs:
# /etc/network/interfaces example:
auto vmbr0
iface vmbr0 inet static
address 192.168.10.5/24
gateway 192.168.10.1
bridge-ports enp3s0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
In the VM/container network configuration, set the VLAN tag to the desired VLAN ID. The bridge handles 802.1Q tagging transparently.
Creating and managing VMs
# Create a VM from command line (or use the web UI) qm create 100 --name debian12 --memory 2048 --cores 2 --net0 virtio,bridge=vmbr0,tag=20 --ostype l26 --bios ovmf --efidisk0 local-zfs:1 qm importdisk 100 /var/lib/vz/template/iso/debian-12.5.0-amd64-netinst.iso local-zfs qm set 100 --scsi0 local-zfs:vm-100-disk-0 qm set 100 --boot c --bootdisk scsi0 qm start 100
LXC containers
# Download a template pveam update pveam available | grep debian pveam download local debian-12-standard_12.2-1_amd64.tar.zst # Create a container pct create 200 local:vztmpl/debian-12-standard_12.2-1_amd64.tar.zst --hostname dns-server --memory 256 --net0 name=eth0,bridge=vmbr0,ip=192.168.20.53/24,gw=192.168.20.1,tag=20 --rootfs local-zfs:8 --unprivileged 1 pct start 200 pct enter 200
Backups
Proxmox has built-in backup to local or remote storage. For VM backups:
# Back up VM 100 to local storage vzdump 100 --storage local --mode snapshot --compress gzip # Schedule in web UI: Datacenter > Backup > Add
For off-site replication, ZFS send/receive to a remote host is efficient:
zfs snapshot rpool/data/vm-100-disk-0@$(date +%Y%m%d) zfs send rpool/data/vm-100-disk-0@20240501 | ssh backup-host zfs receive tank/proxmox-backups/vm-100
What surprised us
A few things were better or worse than expected after running Proxmox for a year:
- Better: The web UI is genuinely good. Task history, real-time metrics, and snapshot management all work reliably and are fast.
- Better: LXC container density is remarkable. Twelve containers on a 16 GB host with headroom for burst is realistic for lightweight services.
- Worse: Cluster setup complexity. If you run a single node, everything is straightforward. Adding a second node involves quorum management and shared storage, which adds significant operational overhead for a home lab.
- Neutral: The no-subscription repository is stable and we have had no incidents from using it over a year. The nag dialog in the web UI is mildly annoying.