Install

Download the Proxmox VE ISO from proxmox.com, write it to a USB stick (use Etcher / Rufus), boot the target hardware. The installer is straightforward:

  1. Accept the EULA.
  2. Pick the install disk(s). For ZFS root: select multiple disks + ZFS RAID-1 (mirror) or RAID-10. For ext4: single disk works.
  3. Hostname (FQDN: pve1.lab.example.com), root password, email.
  4. Network config: static IP recommended (DHCP works but you'll change it later anyway).

After install + reboot, the web UI is at https://<ip>:8006. Login as root@pam.

The first config tweaks

Out of the box, Proxmox subscribes to the enterprise apt repo (which requires a paid subscription). For homelab use, switch to no-subscription:

# SSH into the Proxmox host
ssh root@pve1

# Disable the enterprise repos
sed -i 's|^deb|# deb|' /etc/apt/sources.list.d/pve-enterprise.list
sed -i 's|^deb|# deb|' /etc/apt/sources.list.d/ceph.list

# Enable the no-subscription repo
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" \
    > /etc/apt/sources.list.d/pve-no-subscription.list

apt update
apt full-upgrade -y

# Optional: silence the "no subscription" nag on login
# (Search community wiki for the current one-liner; it varies by version.)

Storage layout

Set up storage under Datacenter → Storage. Common types:

  • Directory — a path on the local filesystem. Holds ISOs, container templates, VM disks (as raw / qcow2 files). Simple but no snapshot support for raw.
  • ZFS — a ZFS dataset. Native snapshots + replication + compression. Recommended for local.
  • LVM-Thin — thin-provisioned LVM. Faster than directory; supports snapshots.
  • NFS / CIFS — remote share for ISOs, backups, and (with caveats) VM disks.
  • Ceph — the recommended shared storage for HA clusters (see Ceph tutorial).
  • iSCSI — block storage over the network (see iSCSI tutorial).

Create a VM

Click "Create VM" in the top-right of the web UI:

  1. General: Name, VM ID (auto-incremented).
  2. OS: ISO image (upload one to a storage area first: Storage → ISO Images → Upload).
  3. System:
    • Machine: q35 (modern; better PCIe support)
    • BIOS: OVMF (UEFI) for modern OSes; SeaBIOS for legacy
    • SCSI Controller: VirtIO SCSI single
    • Add EFI Disk if OVMF
    • QEMU Agent: enable (install the agent in the guest after install)
  4. Disks: Storage location, size, format. SSD emulation + Discard for SSDs.
  5. CPU: Cores. Type: host gives the guest the host's CPU features (best performance; not portable across CPU generations).
  6. Memory: RAM. Enable "Ballooning Device" so unused VM memory can return to the host.
  7. Network: Bridge (default: vmbr0 — the host's main bridge). Model: VirtIO (paravirtualized; fastest).

Click "Finish." Boot the VM via the Console action; install the OS normally.

Post-install: install the guest agent

# Inside a Debian / Ubuntu VM
sudo apt install qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

# Inside a Windows VM: install virtio-win drivers + qemu-ga
# (https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/)

The agent enables filesystem-consistent snapshots, IP-address visibility in the web UI, and graceful shutdown.

LXC containers (lighter than VMs)

For Linux-only workloads where you don't need a separate kernel, LXC containers are dramatically lighter than full VMs. "Create CT" instead of "Create VM"; pick a container template (downloadable from Datacenter → CT Templates → Templates: a curated list of distro images).

LXC containers boot in seconds, use less RAM, and the host can see their filesystem directly via /var/lib/lxc/<id>/rootfs/.

Limits:

  • No separate kernel (workloads needing kernel modules don't work in LXC; need a VM).
  • Docker-in-LXC works with "Privileged" mode but is fiddlier than just running Docker in a VM.
  • Less isolation than a VM — one less security boundary.

Backups

Per-VM / per-CT backup config under the Backup tab. Or via Datacenter → Backup, schedule a recurring backup job:

  • Storage: a directory or NFS that has "VZDump backup file" in the storage config.
  • Mode: Snapshot (live, fast), Suspend (briefly pause), Stop (full shutdown).
  • Compression: zstd is the modern choice.
  • Retention: prune-rules (keep daily 7, weekly 4, monthly 12).

For better backup with deduplication, install Proxmox Backup Server on a separate host — chunk-level dedup, encrypted, much more efficient than vzdump alone.

Clustering

For multi-host Proxmox, create a cluster (Datacenter → Cluster → Create Cluster on the first host, then "Join Cluster" on the others using the join info). 3+ nodes recommended for proper Corosync quorum.

Once clustered:

  • One unified web UI manages all nodes.
  • VMs can live-migrate between nodes (if storage is shared or replicated).
  • HA: configure VMs as HA-managed; if a node fails, they restart on a surviving node.

ZFS replication: cheap HA without Ceph

For 2-3 node clusters where Ceph is overkill, ZFS replication sends incremental snapshots between nodes on a schedule:

# Per VM: Replication → Add → Target node + interval (1 min, 15 min, 1 hour)
# Proxmox uses zfs send/recv under the hood

On node failure: the replicated VM exists on the surviving node at the last replication point; restart it there. Data loss = the time since last replication (down to a minute).

GPU passthrough

For VMs that need a real GPU (gaming, ML training, transcoding):

  1. Enable IOMMU in BIOS + kernel cmdline (intel_iommu=on or amd_iommu=on).
  2. Blacklist the host driver for the target GPU.
  3. Bind to vfio-pci.
  4. Add the PCI device to the VM's hardware list.

The Proxmox wiki has the definitive walkthrough; AMD GPUs are usually straightforward, NVIDIA consumer cards may need extra args to avoid "Code 43" in Windows guests.

Templates + cloud-init

For repeatable VM deployment:

  1. Install a base VM (Debian / Ubuntu cloud image).
  2. Convert it to a template (right-click → Convert to template).
  3. Clone it; each clone takes seconds (linked or full clone).
  4. Cloud-init configures hostname, network, SSH keys, packages on first boot.

Combine with Terraform / OpenTofu (see that tutorial) and the bpg/proxmox provider for fully-IaC VM provisioning.

What Proxmox doesn't do

  • Not a Kubernetes platform — run K8s inside Proxmox VMs (Talos in that tutorial is a perfect fit).
  • Not designed for very large clusters (>~20 nodes). For that scale, OpenStack or VMware vSphere territory.
  • No vMotion-equivalent over WAN; live-migration is LAN.

Alternatives in the homelab hypervisor space

  • XCP-ng — the Citrix Hypervisor / Xen-based competitor. Smaller community than Proxmox in 2026.
  • Incus / LXD — container + VM management without a hypervisor layer; cleaner for container-focused work, less polished UI.
  • OpenStack — way bigger; for serious clouds.
  • ESXi free — effectively dead post-Broadcom for new homelabs.

For "I want one box (or three) running multiple VMs / containers with a real UI, backups, and a clean upgrade story," Proxmox is the right size in 2026.