Understand Proxmox
like water.
A hands-on course that takes you from "what even is a hypervisor" to fluently reading a Proxmox cluster's architecture, storage, networking, and CLI — with simulations you can actually click, drag, and break.
What Proxmox actually is
Not a black box. Not an appliance. It's Debian Linux, wearing a very good web interface.
Proxmox VE (Virtual Environment) is free, open-source virtualization software you install directly on a physical server (this is called "bare metal" — no host OS underneath it). Once installed, it lets you carve that one machine into many independent virtual machines and containers, each with their own OS, resources, and network identity — and manage all of it, plus other Proxmox servers, from one web dashboard.
The trick to understanding Proxmox quickly is this: it is not a proprietary format you have to learn from scratch. Underneath, a Proxmox node is a Debian Linux server. VMs run on QEMU/KVM — the same virtualization stack used by big cloud providers. Containers run on LXC. Networking is plain Linux bridges. Storage is ZFS, LVM, or Ceph — all mainstream, well-documented Linux technology. Proxmox's actual product is the glue: a clustering layer, a web UI/API, a scheduler, and sane defaults, stitched over tools that already exist. That's why, when something breaks, you can always drop to a shell and debug it like any Linux box.
🖥️Type-1-ish hypervisor
Installs directly on hardware (no host OS to maintain separately), like ESXi — but it's a full Linux distribution you can SSH into, apt update, and inspect.
🧱Two guest types
Full VMs (QEMU/KVM) for any OS and strong isolation, and lightweight LXC containers for Linux workloads that don't need a separate kernel.
🆓Free & open source
The entire platform is AGPLv3. A paid Enterprise subscription buys you a more conservative update repo and official support — nothing is feature-gated.
🔗Clusters natively
Group multiple physical nodes into one cluster, managed from a single pane of glass, with live migration and optional automatic failover (HA) between them.
🗄️Storage-agnostic
Plugs into local disks, ZFS pools, LVM, NFS/CIFS shares, iSCSI, or a distributed Ceph cluster — pick what fits your hardware and scale.
🔌API-first
Every button in the UI calls the same REST API you can script against — with Perl, Python, Terraform, Ansible, or plain curl.
If you remember one sentence: Proxmox = Debian + (QEMU/KVM for VMs, LXC for containers) + Corosync/pmxcfs for clustering + a web UI/API layered on top of all of it. Everything else in this course is detail on that one sentence.
Architecture, layer by layer
Click any block in the diagram to see what it does and how it connects to the rest of the stack.
Virtual machines vs. containers
The single most important decision you'll make per-workload. Here's how to make it correctly.
🖥️ Virtual Machine (QEMU/KVM)
- ✅ Run any OS — Windows, BSD, a different Linux kernel version
- ✅ Strongest isolation — separate kernel means a VM crash/exploit can't touch the host kernel
- ✅ Live migration between nodes, snapshots of full state including RAM
- ⚠️ Higher overhead — boots its own kernel, emulates virtual hardware
- ⚠️ Slower to provision and slightly heavier on resources
📦 Container (LXC)
- ✅ Starts in ~1 second — no kernel boot, no hardware emulation
- ✅ Much lower memory/CPU overhead — near-native performance
- ✅ Feels like a lightweight VPS; can be unprivileged for extra isolation
- ⚠️ Must run Linux, and share the host's kernel version
- ⚠️ Weaker isolation boundary than a VM (kernel is shared attack surface)
| Use case | Recommended | Why |
|---|---|---|
| Windows server / desktop | VM | Containers can't run a non-Linux kernel at all. |
| Lightweight Linux service (nginx, Postgres, app server) | Container | Fast boot, tiny footprint, easy to template and scale out. |
| Untrusted / multi-tenant workload | VM | Kernel-level isolation matters more than the perf cost. |
| pfSense / OPNsense firewall appliance | VM | These are BSD-based and need PCI passthrough for NICs — needs a VM. |
| Home-lab "just run 20 small services" | Container | Resource efficiency lets modest hardware run far more workloads. |
| Needs GPU/PCI passthrough | Usually VM | Cleaner passthrough model; some GPU-in-LXC setups exist but are fiddlier. |
Installing Proxmox VE
The real installer is a guided ISO wizard. Here's the walkthrough in plain language, in order.
1Prepare the target machine
64-bit CPU with virtualization extensions enabled in BIOS/UEFI (Intel VT-x/VT-d or AMD-V/AMD-Vi — enable VT-d/AMD-Vi too if you'll ever want PCI passthrough). At least one disk to install onto, and ideally a second for VM storage.
2Write the ISO & boot it
Download the official Proxmox VE ISO, write it to a USB stick, boot the target machine from it, and choose "Install Proxmox VE."
3Pick a target disk & filesystem
Choose ext4 for simplicity, or ZFS (mirror/RAIDZ) if you want built-in snapshots, checksumming, and software RAID on the boot disk itself.
4Set locale, password, network
Give the root account a password, set the node's hostname/FQDN and a static IP — Proxmox really wants a stable IP, since the cluster filesystem and web UI depend on it.
5Reboot into the web UI
After install, the console shows a URL like https://192.168.1.50:8006. Open it in a browser (self-signed cert warning is expected on first run) and log in as root.
6Sort out the update repo
Fresh installs point at the Enterprise repo, which needs a subscription key. For free use, switch to the "no-subscription" repository in Node → Updates → Repositories (or edit the .list files directly), then apt update && apt upgrade.
7Add storage
Datacenter → Storage → Add whatever backend you're using (Directory, LVM-thin, ZFS, NFS...) so VM disks and ISOs/backups have somewhere to live.
8Upload an ISO & create your first VM
Upload an installer ISO to a storage's ISO content type, then Create VM in the top-right — walk the wizard (General → OS → System → Disks → CPU → Memory → Network → Confirm).
Proxmox releases move fast and access tiers/URLs change — always check the current official Proxmox VE documentation for the exact download link and version-specific installer steps before you actually install.
The web UI, live
This is a simulated Proxmox dashboard — real interaction, fake data. Click nodes in the tree, start/stop guests, and watch the resource graphs move.
Storage backends
Proxmox doesn't force one storage technology — it abstracts over many. Choosing right depends on your hardware and how many nodes need to see the same data.
| Backend | Shared across nodes? | Snapshots | Thin provisioning | Best for |
|---|---|---|---|---|
| Directory | No | No* | Depends on file format | ISOs, backups, templates, simple single-node setups |
| LVM (thick) | On shared LUN only | No | No | Simple, predictable block storage |
| LVM-thin | No | Yes | Yes | Fast local storage with snapshots on a single node |
| ZFS (local) | No (unless replicated) | Yes | Yes | Data integrity, snapshots, compression on local disks |
| NFS / CIFS | Yes | Backend-dependent | Usually | Simple shared storage from a NAS |
| iSCSI | Yes | No (raw LUN) | No | Block-level shared storage from a SAN |
| Ceph (RBD/CephFS) | Yes | Yes | Yes | Distributed, self-healing, scale-out shared storage for larger clusters |
*Directory storage snapshots are possible only if the underlying filesystem (e.g. ZFS mounted as a directory) supports it.
🧊ZFS in one breath
A filesystem + volume manager combo. Checksums every block (catches silent corruption), pools disks into mirrors or RAIDZ1/2/3, and snapshots are cheap copy-on-write — no separate LVM layer needed.
🕸️Ceph in one breath
Spreads data as replicated (or erasure-coded) objects across many disks on many nodes. Survives whole-node failure by design. Needs at least 3 nodes and reasonable networking (10GbE+ recommended) to perform well.
💧Thin provisioning, honestly
You can allocate more virtual disk space than you physically have, as long as it's not all written yet. Powerful, but monitor real usage — running out of backing space mid-write can crash guests.
Networking, built from Linux primitives
Drag pieces onto the canvas to build a network: NIC → Bridge → VM. Add a bond for redundancy, or a VLAN to segment traffic.
Drag onto canvas
Drag a piece onto the canvas to place it. Toggle "Connect mode," then click two pieces in a row to link them. Click a piece to remove it.
🔀Bridge (vmbr)
A software Ethernet switch living on the host. Physical NICs and VM/CT virtual NICs plug into it exactly like ports on a real switch — this is how a VM gets onto your LAN.
🔗Bonding
Two or more NICs combined into one logical link. active-backup gives failover only; LACP (802.3ad) needs switch support but gives failover + combined throughput.
🏷️VLANs
Tag traffic with an 802.1Q VLAN ID so one physical link can carry several isolated logical networks — e.g. a "management" VLAN and a "guest" VLAN on the same cable.
🕸️SDN
Proxmox's newer layer for defining zones/VNets/subnets once at the Datacenter level and having it consistently applied across every node in the cluster — instead of hand-editing /etc/network/interfaces everywhere.
Clustering & High Availability
Click a node to take it offline and watch quorum — and HA's response — update live.
💓Corosync
Nodes constantly exchange heartbeats over Corosync (ideally on a dedicated, low-latency link). This is the raw signal quorum and cluster membership are computed from.
🗳️Quorum
Each node normally gets one vote. The cluster needs strictly more than half of total votes online to remain "quorate" and allow config changes — this is what prevents split-brain.
🚑HA manager
For guests flagged HA-managed, if their node disappears and the cluster is still quorate, the HA stack fences the dead node and restarts the guest elsewhere automatically.
Backup & restore
Snapshots are not backups. Here's the actual safety net, and the three ways vzdump can take it.
📸Snapshot mode
Guest keeps running. Uses the storage layer's own snapshot capability (or QEMU's) to get a consistent point-in-time copy. Minimal downtime — the default, most-used mode.
⏸️Suspend mode
Briefly pauses the guest to guarantee a fully consistent copy, then resumes it. A middle ground when snapshot mode isn't available for a given storage.
⏹️Stop mode
Fully shuts the guest down for the duration of the backup. Safest for absolute consistency (e.g. databases without app-level consistency guarantees), but causes real downtime.
Proxmox Backup Server (PBS) is a dedicated product your PVE nodes push backups to. It adds client-side deduplication (only changed chunks are transferred/stored after the first backup), compression, optional encryption before data ever leaves the source, and configurable retention (keep last N, N daily, N weekly...). Storing backups on PBS — physically separate from the cluster — is what actually protects you if a whole node or its local storage dies.
Restore a VM
qmrestore <archive> <new-vmid> --storage local-zfs
Restore a container
pct restore <new-ctid> <archive> --storage local-zfs
Users, permissions & the API
Three moving parts: where an identity comes from, what it's allowed to do, and where that permission applies.
🌐Realm
The authentication source: Linux PAM, Proxmox VE's own built-in auth server, or an external LDAP / Active Directory / OpenID Connect provider.
🎭Role
A named bundle of privileges — built-in ones like PVEAdmin, PVEVMAdmin, PVEAuditor, or a custom role you assemble from individual privilege bits.
📍Path (ACL)
Where in the resource tree a role applies — the whole Datacenter, one node, a resource pool, or a single VM. A user/group + role + path = one ACL entry.
You want a junior admin to manage only VMs in the "webteam" pool, without touching storage or other teams' VMs:
- Create the user in an appropriate realm (or add them via LDAP sync).
- Create — or use the built-in —
PVEVMAdminrole (start/stop/console/snapshot, no storage/network admin). - Add an ACL: User = that admin, Path =
/pool/webteam, Role = PVEVMAdmin. - They can now fully manage VMs in that pool and nothing else in the cluster.
🔑API Tokens
For scripts, Terraform, or CI: create a token under a user (User → API Tokens). It gets its own secret and, if you uncheck "Privilege Separation," inherits the user's ACLs — or you can scope it independently with its own ACL entries, and revoke it without touching the user's password.
GPU & PCI passthrough
Handing real hardware directly to a VM — near-native performance, but a few prerequisites have to line up.
1Enable IOMMU in firmware & kernel
Turn on Intel VT-d / AMD-Vi in BIOS/UEFI, then add intel_iommu=on (or amd_iommu=on) plus iommu=pt to the kernel command line and reboot.
2Check IOMMU groups
The target device needs to sit in its own (or a cleanly separable) IOMMU group — otherwise everything sharing that group must be passed through together.
3Bind the device to vfio-pci
Blacklist the host driver for that device (e.g. nvidia/nouveau/amdgpu) and load vfio-pci against its PCI ID so the host itself stops using it.
4Add it as a PCI device on the VM
In the VM's Hardware tab: Add → PCI Device → select the physical device → enable "All Functions" and, for GPUs, "PCI-Express" and ROM-BAR as needed.
Consumer GPUs sometimes throw "Code 43" in Windows guests unless you hide the hypervisor signature (args: -cpu host,hv_vendor_id=null,kvm=off style tweaks). Motherboard IOMMU grouping varies wildly — some boards need a kernel patch or ACS override to split groups cleanly. Always keep a way to reach the host's console/SSH before rebooting into a passthrough config, in case the GPU output disappears with it.
Terminal playground
A simulated Proxmox shell. Try the real command syntax — qm, pct, pvesm, pvecm — and get realistic canned output. Type help to start.
CLI cheat sheet
Every command from the playground above, organized and copyable.
Proxmox vs. the alternatives
Where it fits relative to the other names you'll hear.
| Platform | License | Base | Best fit |
|---|---|---|---|
| Proxmox VE | Free / open-source (AGPLv3) | Debian + KVM + LXC | Home labs to mid-size clusters, full control, no license fees |
| VMware ESXi / vSphere | Proprietary, licensed | Custom VMkernel | Large enterprises already invested in the VMware ecosystem |
| XCP-ng | Free / open-source | Xen | Xen fans wanting a free ESXi-like alternative with Citrix Hypervisor roots |
| Hyper-V | Bundled with Windows Server | Windows kernel hypervisor | Shops already standardized on Windows Server infrastructure |
| Plain libvirt/KVM | Free / open-source | Any Linux + KVM | Maximum flexibility for people who want to assemble the stack themselves |
🎯Why people pick Proxmox specifically
No per-core or per-socket licensing, a genuinely usable web UI without needing a separate management server (vCenter-equivalent is built in), first-class support for both VMs and containers in one tool, and — because it's just Debian — nothing is a black box when you need to debug it at 2am.
Glossary
Every term used across this course, in one searchable place.
Quiz: do you actually get it?
Ten scenario-based questions. No fluff — each one tests something that actually trips people up.