Proxmox VE · Self-assessment
Knowledge checks
Every knowledge check in this course, in curriculum order. Each link opens the page at its quiz. The questions are auto-graded in the browser and nothing is recorded — a wrong answer costs you only the explanation, which is the part worth reading.
- Knowledge checks
- 253
- Parts covered
- 27
- Of all lessons
- 100%
Part I
Foundations
7 checks
- Welcome to RunBook AcademyA hands-on production Proxmox VE administration course.→
- What virtualisation actually does→
- KVM and QEMU: the hypervisor pair→
- Hardware virtualisation, IOMMU, and CPU features→
- LXC containers vs virtual machines→
- Proxmox VE architecture and daemons→
- Where configuration actually lives→
Part II
Production Planning
8 checks
- Requirements capture: RPO, RTO, workloads→
- Hardware selection for production Proxmox→
- Firmware, BIOS and controller configuration before installThe settings you make once, before Proxmox is installed, that cannot be undone without rebuilding the node — HBA versus RAID mode, IOMMU and SR-IOV, power profiles, boot mode and the BMC baseline.→
- Reference architectures: small, medium, hyperconverged, SAN-backed, DR→
- Failure-domain modelling→
- Capacity planning and N+1 design→
- Sizing a cluster: a worked example with real numbersOne workload inventory carried end to end — through growth, overcommit, the N+1 survivable ceiling, RAM, IOPS, network bandwidth and Ceph raw-to-usable — to a node count, a bill of materials and an expiry date.→
- Cost vs availability vs complexity→
Part III
Installation & Baseline
10 checks
- Pre-install checklist→
- Installer walkthrough→
- Repositories and subscriptions→
- Post-install hardening baseline→
- Certificates and TLS→
- Certificate rotation, ACME renewal, and TLS hardening→
- Automated installation with answer filesBuilding a Proxmox node from an answer file rather than a keyboard — the answer.toml schema, the three fetch modes, device filters that survive a hardware swap, and first-boot hooks.→
- Boot and root layout: ZFS root, systemd-boot and GRUBThe partition layout the installer creates, why the bootloader is derived rather than chosen, and which parts of the install-time decision cannot be changed afterwards.→
- proxmox-boot-tool: ESP synchronisation and kernel pinningKeeping every EFI System Partition in sync so a node still boots after losing a disk, pinning a known-good kernel after a regression, and repairing a node that will not start.→
- Installing PVE on top of an existing Debian systemThe supported path for rented dedicated servers and machines you cannot boot from an ISO — the exact procedure on Debian 13 Trixie, and an honest account of what the ISO installer does that this does not.→
Part IV
Networking
10 checks
- Linux networking primer: interfaces, bridges, taps→
- Bonds, LACP, VLANs, MTU→
- Applying network changes without losing the nodeProxmox stages network changes in a file before applying them. Knowing that file exists is the difference between a reversible change and a drive to the datacentre.→
- Traffic-class separation→
- SDN: zones, VNets, subnets→
- SDN IPAM and DNS: NetBox, phpIPAM and PowerDNSSDN can allocate a guest an address and register it in DNS without anyone touching a wiki page. It can also make VM provisioning depend on a service the virtualisation team does not run.→
- SDN fabrics: OpenFabric, OSPF, WireGuard→
- EVPN and BGP routing across Proxmox clusters→
- BGP policy: route maps, prefix lists and filteringA Proxmox fabric speaking BGP to the wider network will advertise whatever it knows unless you tell it otherwise. Route maps are how you tell it otherwise.→
- Network failure scenarios and debugging→
Part V
Storage Fundamentals
8 checks
- Storage fundamentals: block, file, object→
- IOPS, latency, queue depth, sync vs async→
- RAID, snapshots, thin provisioning, TRIM→
- Filesystems for VM disks: ext4, xfs, and ZFS on top→
- Disk benchmarking with fio: how to verify your storage is fast enough→
- Storage monitoring: S.M.A.R.T., ZFS scrub health, and early warning signs→
- The PVE storage model: storage.cfg, types and contentEvery other storage lesson in this course assumes this abstraction and none of them define it. A storage entry, its type, its content types, its node restriction, the shared flag that is an assertion rather than an implementation, and the volume identifier that ties a guest disk to all of it.→
- Choosing a storage backend: the capability matrixSnapshots, thin provisioning, shared access and clones are not independent choices — each backend gives you a fixed bundle of them, and the bundle decides what your operations look like for years. The documented matrix, what each capability actually buys, and the four questions that pick a backend.→
Part VI
ZFS
8 checks
- ZFS pools, vdevs, and RAIDZ→
- ZFS ARC, ZIL/SLOG, L2ARC→
- Special vdevs, metadata devices and native encryptionA special vdev makes a spinning-disk pool behave like flash for metadata. It also makes losing one NVMe drive lose everything, which is not how SLOG or L2ARC behave.→
- ZFS scrub, resilver, and disk replacement→
- ZFS as Proxmox storage (local-zfs, replication)→
- volblocksize, recordsize and guest alignmentvolblocksize is fixed at zvol creation. Getting it wrong costs IOPS, capacity or both, and the only repair is to rewrite every block.→
- ZFS snapshots, clones, and the snapshot lifecycle→
- ZFS send/receive: replication, off-site backups, and migration→
Part VIII
Ceph
11 checks
- Ceph architecture: RADOS, MON, MGR, OSD, MDS→
- Proxmox-integrated Ceph: install and configure→
- Ceph hardware and network sizing→
- Ceph pools: replicated, EC, FastEC, device classes→
- Ceph day-2: OSD replacement, scrubbing, recovery→
- Ceph performance and health investigation→
- Ceph troubleshooting scenarios→
- Ceph authentication: cephx, keyrings and capabilitiesEvery Proxmox Ceph cluster runs cephx by default and almost every one of them runs everything as client.admin. This lesson explains what that means and how to fix it without breaking storage.→
- Connecting Proxmox to an external Ceph clusterHyper-converged Ceph is one pattern. The other is a storage team that already runs Ceph and hands you a keyring. This lesson covers the second one, including what Proxmox can no longer tell you.→
- RBD mirroring for cross-site replicationCeph replicates inside a cluster and stops at its boundary. RBD mirroring is how a second site gets a copy - and how a bad failover destroys one.→
- Upgrading Ceph: Squid to TentacleA Ceph major-version upgrade is the one maintenance action that can take an entire Proxmox estate down at once. This is how it is done, and where the point of no return is.→
Part IX
Virtual Machines
14 checks
- VM creation and machine types→
- VM CPU: types, NUMA, pinning, limits→
- VM memory: ballooning, hugepages, NUMA→
- VM disks: VirtIO SCSI, cache, discard, IO threads→
- VM network devices and configuration→
- Cloud-Init, templates, and clones→
- PCI/GPU passthrough, TPM, UEFI→
- Machine types, QEMU versions and migration compatibilityThe machine type pins a VM virtual hardware to a QEMU version. What "latest" resolves to and when, why a rolling cluster upgrade only migrates in one direction, and why Windows is pinned at creation while Linux is not.→
- VM snapshots: mechanics, cost and limitsWhere a snapshot physically lives on each storage backend, what vmstate adds, why a long-lived snapshot chain gets more expensive over time on some backends and not others, and the precise sense in which a snapshot is not a backup.→
- The QEMU guest agent in depthThe channel between the hypervisor and the guest: what it enables, the four sub-options nobody reads, running commands inside a guest from the host, and how to diagnose an agent that is configured and not answering.→
- Consoles and recovery: noVNC, SPICE, serial and qm terminalFour ways into a guest and what each one can still reach when the guest is broken. Configuring a serial console properly on both sides, and the recovery path for a VM whose graphics, network or root filesystem have stopped cooperating.→
- Hookscripts, startup order and resource poolsThe supported extension point for guest lifecycle automation, the boot ordering that decides whether a cluster comes back correctly after a power event, and pools as an authorisation and accounting boundary rather than a folder.→
- Disk I/O paths: aio, cache, iothread and how they interactFour disk parameters that are usually set independently and are not independent. What each of the three aio backends does, which cache modes each can be combined with, what an iothread actually buys, and how to measure the difference rather than guess.→
- virtio-fs, virtio-rng, vmgenid and the rest of the device modelThe devices a VM has beyond a disk and a NIC: sharing a host directory into a guest without a network filesystem, feeding entropy to guests that need it, and the generation ID that lets a guest know it has been rolled back.→
Part X
LXC Containers
11 checks
- LXC architecture: namespaces and cgroupsThe two kernel mechanisms behind every container, how to see them on a running system, why PVE 9 uses only cgroup v2, and the precise sense in which a namespace is not a security boundary.→
- Privileged vs unprivileged containersA security boundary, not a preference: what the UID mapping actually does, why the setting cannot be changed after creation, how to audit an estate for privileged containers, and the migration path off one.→
- Container networking and storageHow a container attaches to a bridge and what veth pair sits underneath, the net[n] options that matter, why the container firewall is a different object from the host firewall, and the three storage shapes with three different backup outcomes.→
- Container migration, backups, and security boundaryWhat container migration really does compared with a VM’s, the three vzdump modes and the downtime each one actually costs, restore behaviour that surprises people, and the security boundary stated without hedging.→
- LXC templates, custom images, and the template workflow→
- LXC updates, migration, and low-downtime maintenance→
- Bind mounts and mount points: sharing host storage with a containerThe three kinds of mount point, why a bind-mounted directory shows up as nobody:nogroup inside an unprivileged container, the idmap arithmetic that fixes it, and the reason a container restore can come back without its data.→
- Passing devices into containers: GPUs, dongles and the boundary you give upThe dev[n] option, what it does that a raw cgroup rule does not, why /dev/dri for transcoding is a real security decision, and the two failures - a device that renumbers after a reboot and a dongle that never comes back after a replug.→
- Nesting and Docker inside LXC: what the flag enables and what it costsWhat features=nesting actually turns on, why Docker-in-LXC works but stores its layers badly, the security argument for and against, and the honest answer to when a VM is the correct choice instead.→
- Container resource limits under cgroup v2cores versus cpulimit versus cpuunits, what memory and swap limits do when they are hit, why a container OOM looks nothing like a VM OOM, and the lxcfs layer that decides what the container believes about its own resources.→
- Recovering a container that will not startReading a pct start failure properly, mounting a container rootfs from the host to fix it from outside, resizing a full rootfs, when pct fsck applies and when it cannot, and repairing a config that no longer parses.→
Part XI
Clustering
8 checks
- What a Proxmox cluster is (and is not)→
- Corosync and pmxcfsThe two subsystems that make a set of servers into a cluster, what each is actually responsible for, and how to tell which one is at fault when the cluster misbehaves.→
- Quorum, votes, and QDeviceThe majority arithmetic that keeps a cluster safe, and the external vote that makes a two-node cluster viable - including why the same QDevice on a three-node cluster makes it less resilient, not more.→
- Joining, removing, and replacing nodesWhich command runs on which node, why a removed node must never be powered back on with its old configuration, and the ordering that decides whether a dead node takes its guest configurations with it.→
- Quorum loss recoveryDiagnosis before intervention: what the votes are telling you, the four causes and how to distinguish them, and why the command everybody reaches for is the one that turns a frozen cluster into a corrupted one.→
- Cluster networking deep dive: Corosync links, totem, and tuningEditing corosync.conf without losing the cluster, what a real knet configuration looks like on PVE 9, the totem parameters that exist and their actual defaults, and how to prove a redundant link works before you need it.→
- What /etc/pve does when quorum is lostpmxcfs keeps serving reads without quorum and rejects every write. That single asymmetry produces a cluster that looks healthy in the GUI and refuses every change, and it is the symptom operators misdiagnose most often.→
- Cold-starting a cluster from a full shutdownA cluster with every node off is inquorate by definition, and nothing recovers until a majority is back. The ordering that gets you from dark racks to running workloads - and the partial power restore that traps operators halfway.→
Part XII
High Availability
9 checks
- Cluster vs HA vs DR: the terminologyFour words that stakeholders use interchangeably and that address four different failures, the questions to ask when someone requests "HA", and why answering the wrong one is how estates end up with an expensive cluster and no recovery plan.→
- HA architecture: CRM, LRM, watchdog, fencingThe two daemons, the agent lock that carries the safety guarantee, why the recovery delay is roughly a minute and must not be shortened, and how to configure and verify a watchdog that will actually fire.→
- HA rules: node-affinity (PVE 9)How node-affinity and resource-affinity constrain placement, why strict and non-strict are opposite failure choices, the rules that cannot be satisfied and what happens then, and the migration from deprecated HA Groups.→
- When HA cannot save youSeven failure modes HA cannot recover from, the arithmetic behind the capacity one, why a storage outage defeats every compute node at once, and what to write in a runbook for each.→
- HA operational procedures: enable, monitor, disarmThe commands that exist and the ones people think exist, what each resource state actually means, maintenance mode versus disarming the whole stack, and recovering a service from error state without repeating the fault.→
- HA in depth: groups, constraints, affinity, and the failure matrix→
- CRS and dynamic load balancing (PVE 9.2)The three CRS scheduler modes, what changed when ha=dynamic and automatic rebalancing arrived, the five datacenter.cfg keys that govern when a guest gets moved, and how to constrain a scheduler that has started migrating production at 03:00.→
- What HA requires: the storage, network and fencing matrixWhich storage backends permit HA and which quietly do not, what actually happens to a guest on local storage when its node dies, why fencing is a prerequisite rather than a refinement, and a readiness check you can run before enabling anything.→
- Anatomy of a bad fence: two post-mortemsA false-positive fence that took down a healthy node and a near-split-brain that nearly took the storage with it - reconstructed from CRM and LRM logs, with the design changes that prevent each and the reasoning behind them.→
Part XIII
Proxmox Backup Server
13 checks
- PBS architecture: chunk store, dedup, encryption→
- PBS datastores, namespaces, prune, GC, verify→
- Backup jobs and Proxmox VE integration→
- PBS remotes, sync, off-site, S3, tape→
- Restore practice: file-level, VM-level, restore certification→
- Ransomware posture and the 3-2-1 rule→
- Building the PBS host: install, storage layout, sizingProxmox Backup Server as its own machine - why it must not live on a hypervisor, how to lay out the OS and datastore disks, the RAM and IOPS arithmetic that follows from 4 MiB chunking, and the datastore tuning knobs that exist.→
- Backup modes: snapshot, suspend and stopThe per-job setting that decides whether the guest keeps running and what the backup is consistent with - crash consistency versus filesystem consistency versus application consistency, and why the guest agent is the whole difference.→
- Fleecing, bandwidth limits and backup impactWhy a slow backup target makes a running guest slow, how backup fleecing breaks that coupling, which storage a fleecing image needs, and the bwlimit / ionice / max-workers levers that shape the rest of the backup window.→
- Dirty bitmaps and why incremental backups are fastTwo separate optimisations get confused for one: the QEMU dirty bitmap that avoids reading the disk, and chunk deduplication that avoids uploading it. Knowing which is which explains why the backup after a reboot is slow and why nothing is wrong.→
- Live restore, single-file restore and the RTO arithmeticThree restore shapes with very different recovery times - full restore, live restore, and pulling one file out of a snapshot. When each is the right answer, what live restore costs while it runs, and the failure mode that makes it a decision rather than a default.→
- PBS users, ACLs, tokens and datastore permissionsThe PBS permission model as a design tool: the object-path tree, propagation, the built-in roles and the one privilege boundary that separates a backup a compromised hypervisor can write from one it can delete.→
- Backing up non-PVE hosts with proxmox-backup-clientPBS is not only a Proxmox VE accessory. A physical database server, a cloud VM or a NAS can back up into the same deduplicated datastore - with its own credential, its own encryption key, and a systemd timer instead of a backup job.→
Part XIV
Disaster Recovery
9 checks
- RPO, RTO, and dependency modellingTurning a business sentence into two numbers with arithmetic behind them, why an RPO is bounded by the backup schedule rather than the sync schedule, dependency mapping that survives contact with an incident, and the recovery order nobody writes down.→
- Site failure design and DR site architectureFour DR architectures priced against RTO, what a DR site actually needs beyond compute and storage, the DNS and network cutover, and the pre-positioned credentials without which the whole design is theory.→
- DR runbook exercise: restoring a fictional businessBuilding a runbook someone can execute at 03:00, the decision authority that has to exist before the technical steps matter, and the gaps a tabletop reliably finds in a plan that looked complete.→
- DR test, exercise, and continuous improvementExercise types priced by cost and risk, what each one can and cannot find, the metrics that make DR readiness visible to people who fund it, and the improvement loop that stops a plan going stale.→
- Designing a multi-site DR strategy with PBS and ZFS replication→
- DR testing: fire drills, partial failures, and chaos engineering→
- Rebuilding a destroyed cluster: /etc/pve, node identity and the platform itselfWhat in /etc/pve is the cluster’s identity rather than its configuration, how to back it up so a rebuild is possible, restoring config.db onto new hardware, and rebuilding around a single surviving node without producing a cluster that half-remembers the dead one.→
- Disaster recovery for the backup server itselfWhat "the backup server is gone" actually costs, PBS-to-PBS sync in pull and push direction as a DR mechanism, rebuilding a PBS host around a surviving datastore, and key escrow - because an encrypted chunk store without its key is not a backup.→
- Choosing a replication strategy: ZFS send, Ceph RBD mirror, PBS syncThree mechanisms that all get called replication, their real RPO and RTO, what each costs in bandwidth and operational surface, why RBD mirroring is not a Proxmox feature, and how to combine them so each failure has an owner.→
Part XV
Security & Hardening
12 checks
- Threat model and management isolation→
- Auth realms, RBAC, TFA, and API tokens→
- Proxmox firewall: host, VM, security groups→
- Production hardening checklist→
- Network security: VLANs, firewall, IDS, and intrusion detection→
- Audit logging, integrity monitoring, and compliance evidence→
- The ACL model: paths, propagation and custom rolesThe permission tree Proxmox actually evaluates — path, principal, role, propagate — and how to build a role that grants exactly the privileges a job needs and audit that it did.→
- Authentication realms: LDAP, AD and sync jobsConfiguring an LDAP or Active Directory realm end to end, mapping directory groups onto Proxmox groups, running the sync safely with --dry-run, and deciding what happens to a PVE user when the directory entry disappears.→
- OpenID Connect and single sign-onConfiguring an OIDC realm against a real identity provider, mapping claims onto Proxmox users and groups, and designing the path back in for the day the IdP is unavailable.→
- API tokens, privilege separation and secret rotationThe full token lifecycle — creation, privilege separation, expiry, where the secret ends up in automation, and a rotation procedure that does not take production down.→
- The firewall in depth: three levels, and the nftables backendHow datacenter, node, VNet and guest rules combine, what the management IP set actually protects, and what changes when you move from the iptables backend to proxmox-firewall on nftables.→
- Responding to a Proxmox security advisoryTracking PVE and Debian advisories, assessing whether your estate is actually exposed, patching under HA without an outage, and keeping the evidence an auditor will ask for.→
Part XVI
Monitoring
10 checks
- What to monitor across the Proxmox stackThe signals worth watching at each layer, ordered by how much warning they give - and the five levels between a node being up and a service actually working, four of which can be true while the user sees nothing.→
- Metrics and notifications: two subsystems, one confusionGetting numbers out of a Proxmox cluster and getting alerts out of it are separate mechanisms with separate configuration files, and conflating them is why so many clusters have dashboards and no alerting.→
- Alert design: SLOs, symptoms, and dashboardsWhat a complete alert rule contains beyond its threshold, the burn-rate arithmetic worked with real numbers, and why a dashboard that helps its author is usually useless to the person woken at 03:00.→
- Prometheus node_exporter: collecting host and VM metrics→
- Logging: syslog, journald, and centralised log aggregation→
- Alerting and SLOs: building meaningful on-call signals→
- The PVE notification system: targets and matchersTargets are where a notification can go; matchers decide which ones go there. This is the only mechanism by which a Proxmox cluster reaches a human, and the default configuration sends everything to a mailbox nobody reads.→
- Reading the built-in graphs: RRD, retention and limitsThe graphs in the Proxmox GUI are the first thing every operator looks at and the least understood. What they measure, how far back they really go, what PVE 9 changed about them, and the four questions they structurally cannot answer.→
- External metric servers: InfluxDB, Graphite and OpenTelemetryThe native push export in /etc/pve/status.cfg - three backends, their real option sets, the cardinality the export generates, and the reason a UDP metric server can be silently broken for months.→
- Monitoring Ceph and PBSThe two subsystems whose failures are quiet and expensive. Which Ceph numbers predict an outage rather than describe one, why the fullest OSD is the only capacity figure that matters, and why a PBS metrics dashboard tells you nothing about whether your backups worked.→
Part XVII
Performance Engineering
10 checks
- CPU and memory performance engineering→
- Storage I/O performance→
- Diagnosing "the VM is slow"→
- VM right-sizing: matching resources to workloads→
- Network performance: MTU, offload, and tuning for VM workloads→
- Performance testing and benchmarking: validating your cluster is fast enough→
- Host tuning: governors, C-states, THP and NUMA balancingThe host settings that cap guest performance no matter how the VM is configured — CPU frequency and idle policy, transparent hugepages, automatic NUMA balancing and swappiness — how to measure each one, and which are worth changing in production.→
- KSM, memory overcommit and the ballooning interactionWhat Kernel Samepage Merging actually costs in CPU and saves in RAM, how ksmtuned decides when to run, how KSM composes with ballooning and fights hugepages, and why counting KSM savings as capacity is how a cluster OOMs during a failover.→
- Containing a noisy neighbourIdentifying the guest that is ruining a host, and applying CPU weight, CPU limits and I/O throttles to contain it — without an outage, and without hiding the fact that the node is over capacity.→
- Tuning per backend: ZFS ARC, Ceph OSD, LVM-ThinThe levers that only exist on one storage backend — ARC sizing against host memory pressure, mClock profiles for recovery versus client I/O, thin-pool autoextend — and the measurement that proves each one did something.→
Part XVIII
Maintenance & Lifecycle
10 checks
- Patching, repository management, and reboot planning→
- Rolling maintenance: node evacuation and HA workflows→
- Major upgrades: PVE version upgrades and Ceph upgrades→
- Capacity planning: forecasting growth and avoiding surprises→
- Backup verification and integrity testing→
- Compliance maintenance: PCI-DSS, SOC 2, ISO 27001 evidence collection→
- The pveXtoY upgrade checker and the pre-upgrade gatepve8to9 is the first command in Proxmox own major-upgrade procedure. Reading and clearing every class of its output, what it does not check, and the go/no-go decision it should drive.→
- Repositories, apt pinning and kernel pinningChoosing between the enterprise, no-subscription and test repositories, holding a package that must not move, pinning a known-good kernel after a regression, and why unattended upgrades on a hypervisor need a policy.→
- Firmware, BIOS and microcode in a maintenance windowThe layer below the operating system — CPU microcode, device firmware, BIOS and BMC — how each reaches a Proxmox node, and how to roll it across a cluster without losing one.→
- Decommissioning and refreshing a nodeRemoving a node from a cluster so it stays removed, the corosync and Ceph consequences of doing it in the wrong order, sanitising the disks, and living with a mixed-generation cluster during a refresh.→
Part XIX
Troubleshooting
10 checks
- Proxmox troubleshooting methodology→
- Common Proxmox incident scenarios→
- Ceph troubleshooting: OSDs, MONs, PGs, and recovery operations→
- Network troubleshooting: bridging, VLANs, MTU, and routing issues→
- VM startup failures: debugging the most common boot problems→
- PBS troubleshooting: datastore issues, chunk corruption, and restore failures→
- Collecting evidence: pvereport, logs and the task modelThe evidence you can gather while a fault is present is worth ten times the evidence you can gather after a reboot. pvereport, the daemon-to-question map, where task logs actually live, and how to assemble a support package that does not need a second round of questions.→
- HA and fencing incidentsA guest moved and nobody moved it. A node rebooted with nothing in its logs. A service sits in error and will not start. Reading CRM and LRM state after the fact, recognising a watchdog reset by its absence of evidence, and the recovery sequence that does not make it worse.→
- Storage and ZFS troubleshootingA pool that will not import, a resilver that has stopped moving, a pool at 100% with no obvious consumer, and guests that have gone read-only under a storage that looks fine. Four faults with four different first commands, and none of them is a reboot.→
- When the GUI or the API is the problempveproxy runs as www-data on port 8006 and reads certificates from a two-step fallback path. pvedaemon listens only on localhost. Knowing which of them is broken turns "the cluster is down" into a two-minute fix — and none of the fixes touch a running guest.→
Part XX
CLI & Automation
13 checks
- The PVE command surface, tool by toolEvery pve* tool on a Proxmox node, what each one owns, real invocations with the output they produce, and a map from the question you are trying to answer to the tool that answers it.→
- PVE REST API: tokens, authentication, and the API viewer→
- pvesh: scripting the PVE API like a pro→
- Terraform provider for Proxmox: infrastructure as code for VMs and containers→
- REST API automation patterns→
- Ansible for Proxmox: from ad-hoc commands to full fleet management→
- Python client for Proxmox: building robust automation→
- Cloud-init, ansible-pull, and other VM bootstrap patterns→
- Webhooks and event-driven automation: react to cluster state changes→
- PBS REST API: backup automation and integration→
- API security, hardening, and credential management→
- Tasks, UPIDs and asynchronous operationsEvery state-changing action in Proxmox creates a task and returns a UPID before the work is done. What a UPID encodes, how to poll one correctly, how to read a task log, and why a script that ignores this races itself.→
- Idempotency and drift in Proxmox automationThe PVE API is imperative, not declarative. What that means for scripts that must be safe to re-run, how the config digest gives you optimistic concurrency for free, and how to detect drift between what you intended and what the cluster actually has.→
Part XXI
Migration to Proxmox
9 checks
- Migration from VMware, Hyper-V, and physical systems→
- Migrating from VMware vSphere: full conversion playbook→
- Migration from VMware vSphere: the complete playbook→
- Migrating from Xen / XenServer: conversion paths→
- Migrating from Hyper-V: VHDX conversion and Generation 1/2 handling→
- Cloud-to-Proxmox: importing AWS, Azure, and GCP images→
- The native ESXi import wizardProxmox VE ships an esxi storage plugin that connects to an ESXi host, lists its virtual machines, and imports them without an intermediate export. What it handles, the four documented limitations that will stop you, and when to fall back to virt-v2v.→
- Rehearsing a migration and keeping a way backA rehearsal that is not isolated is an outage. A rollback that nobody has dated is a hope. This lesson builds the isolated test network, writes cutover success criteria that can fail, and identifies the point of no return — the moment rollback stops being free and starts costing data.→
- Exporting out of ProxmoxProxmox VE imports OVF and has no matching export command, so leaving is a disk conversion plus a rebuilt guest definition. The paths that actually work, what does not travel, and why a tested exit is a procurement requirement rather than a sign of disloyalty.→
Part XXII
Operating as a Business Service
10 checks
- Operational discipline: inventory, tagging, change managementAn inventory that is reconciled against the cluster rather than maintained by hope, a tag taxonomy the cluster itself can enforce, and the governance settings in datacenter.cfg that stop tags becoming noise.→
- Operational checklists: daily, weekly, monthly, quarterly, annualA cadence of checks with real commands behind them, written so that each one can fail - and the distinction between a check that produces evidence and one that produces a tick.→
- Operational runbooks and incident managementRunbooks that survive the incident they are for, the roles that stop one person doing four jobs badly, and why mitigation comes before diagnosis on every Proxmox failure worth having a procedure for.→
- Capstone project: design a Proxmox infrastructure→
- Runbook maintenance: keep procedures accurate and used→
- Capacity reporting and stakeholder communication→
- Cost modelling and chargebackWhat a capacity-driven cost model actually contains, worked end to end with real arithmetic - and how to survive the comparison with a cloud bill that somebody will eventually put in front of you.→
- Defining and measuring an SLAWhat an availability number actually commits you to: the downtime arithmetic, what it implies for maintenance windows, why measuring from the hypervisor is measuring the wrong thing, and the ceiling Proxmox HA physically imposes on any target you offer.→
- Change classification and approvalHow a Proxmox change gets risk-classified before it is scheduled: blast radius, reversibility and detectability, the changes that cannot be undone at all, and the evidence an approver actually needs rather than the evidence they usually get.→
- On-call, escalation and handoverRota arithmetic for a team that is too small for one, what actually earns a page on a Proxmox cluster, and the temporary-state register - the handover section that stops a suppressed alert from becoming next month outage.→
Part XXIII
Home Lab
8 checks
- Home lab introduction: what to run on a single NUC or mini-PC→
- community-scripts.org: the helper-scripts catalog for Proxmox→
- Setting up a single-node Proxmox home lab from scratch→
- Building a 2-node cluster + qdevice for the home lab→
- Self-hosting popular apps: Nextcloud, Jellyfin, Pi-hole, Vaultwarden→
- GPU passthrough for Jellyfin transcoding and AI workloads→
- Home-lab networking: VLANs, firewall, and isolation→
- Backing up a home lab with PBS and offsite sync→
Part XXIV
Professional Development
8 checks
- PDM introduction: from operator to engineer→
- Writing runbooks that actually get used→
- Leading incident response: when you are the on-call→
- Mentoring 1:1s: how to grow engineers effectively→
- Design reviews: writing and evaluating architecture documents→
- Career planning: where you are, where you want to be, how to get there→
- Communicating with non-technical stakeholders→
- Building an artefact portfolio: blogs, talks, and OSS contributions→
Part XXV
Proxmox Datacenter Manager
6 checks
- What Proxmox Datacenter Manager is, and is notPDM against PVE and PBS, the multi-cluster problem that produces it, the capabilities that shipped in 1.1 versus the ones still on the roadmap, and an honest reading of a product whose supported-until date is still published as TBA.→
- Installing PDM and connecting clustersSizing and installing the PDM host, choosing between the ISO and a Debian Trixie base, the three repositories, and then the part that actually matters: the remote model, the API token that carries every action, and the pinned certificate that will break on a renewal you forgot about.→
- The cross-cluster view: inventory, health, and what is actually liveThe dashboard, the cross-remote guest list, custom Views and their widgets — and the question nobody asks until an incident: which numbers on this page were fetched just now, which were collected minutes ago, and which are the last-seen state of a remote that is currently down.→
- Cross-cluster guest migration through PDMPDM makes moving a guest between two independent clusters a dialog box. Underneath it is qm remote-migrate, which Proxmox VE labels EXPERIMENTAL, which leaves the source guest behind in a stopped state by default, and which demands that you map every bridge and every storage by hand.→
- Access control and the trust boundaryPDM has three roles, no custom roles, and one API token per cluster stored in a config file on a single host. That host is now the most valuable machine in your estate — the same concentration the Ansible controller and the central identity store create, arriving by a different door.→
- When PDM is the wrong answerOne cluster, a scripted automation pipeline, or an orchestration layer you already trust — three situations where adding PDM costs more than it returns. Plus the honest positive case, the real price of adoption, and how to un-adopt without leaving credentials behind.→
Part XXVI
Windows Guests
6 checks
- Installing Windows on Proxmox correctlyThe Windows installer cannot see a VirtIO disk, the SCSI controller default is wrong for Windows, and the ostype list has no entry named after the Windows Server release you are installing. Getting all three right at creation time is cheaper than every one of the recoveries.→
- VirtIO drivers, the guest agent and the balloon serviceThe VirtIO ISO carries drivers, an agent and a memory-reporting service, and they install by three different mechanisms. A Windows guest with some of them is a specific and diagnosable state, not a partly working one.→
- Windows templates and sysprepCloning a Windows guest without generalising it is unsupported by Microsoft and produces an estate of machines that share an identity. What sysprep actually removes, how to build a Proxmox template around it, and why cloudbase-init needs the ostype you set in Lesson 1.→
- Windows guest performanceCPU model, vCPU count, controller and cache mode decide most of a Windows guest performance, and the balloon driver is a documented tradeoff rather than a free win. How to measure it from inside the guest and from the host, and why the two disagree.→
- Domain controllers as virtual machinesvmgenid makes a snapshot rollback of a domain controller survivable rather than safe, and Microsoft explicitly excludes full-disk backup restores from that protection. What USN rollback costs, why the first instinct in an AD incident is the wrong one, and what a DC backup strategy has to look like on Proxmox.→
- Windows guest troubleshootingINACCESSIBLE_BOOT_DEVICE after a controller change, a guest that boots to the UEFI shell, reactivation after a hardware change and clock drift that stops Kerberos. The recovery for each, in the order that does the least damage.→
Part XXVII
Multi-Cluster and Multi-Tenancy
6 checks
- When one cluster becomes twoProxmox VE sets no explicit node limit, which is not the same as saying a cluster can grow forever. The real ceilings are corosync latency, the size of the blast radius you are willing to accept, and the fact that an upgrade is a cluster-wide event. This lesson is the decision, not the tooling.→
- Cross-cluster migration from the command lineqm remote-migrate and pct remote-migrate, without a Datacenter Manager in front of them: how the target endpoint string is built, which privileges the receiving token needs, why Sys.Incoming exists, what does not travel with the guest, and how to clean up a migration that stopped halfway.→
- Keeping clusters identical: baselines, drift and version skewThe second cluster does not cost you hardware, it costs you agreement. This lesson names every cluster-scoped configuration surface in /etc/pve, defines the naming contract that makes migration between clusters possible at all, and builds a drift report you can run on a schedule.→
- Operating a fleet of clustersInventory that spans clusters, a change that lands on four of them in a defined order, and an on-call model where the first question is no longer "what is wrong" but "which cluster". The operational patterns that only start to matter at cluster number two.→
- Pools, delegation and the limits of tenant boundariesResource pools are an authorisation and grouping boundary, and Proxmox VE does not support per-pool quotas — a fact worth knowing before you promise one to a tenant. This lesson builds a delegated tenant that works, then enumerates precisely what PVE does not isolate.→
- Network isolation between tenantsA pool does not stop one tenant reaching another; the bridge does, or does not. SDN zones per tenant, SDN.Use as the permission that decides which networks a tenant may attach to, the three switches that must all be on before a firewall rule is enforced, and why isolate-ports is not a cluster-wide control.→