Proxmox Builders Course

This is a build course, not an operations course. Our Proxmox Level 1 to 3 courses teach engineers to run a cluster that already exists. The Builders course teaches them to decide what to build, justify that decision, and construct it correctly the first time.

Course purpose

Equip engineers who are handed a requirement to return a working Proxmox VE platform: one chosen on evidence, sized with the arithmetic shown, built to a plan with objective acceptance criteria, and designed around the failures that actually happen.

Duration

1 day, delivered as 2 half days
a standalone track that does not depend on Proxmox Levels 1 to 3

Target audience

Solution architects
Infrastructure engineers
Pre-sales technical consultants
Senior operations staff who are handed a requirement and expected to return a working platform

Prerequisites

Learners should already be comfortable with:

Linux administration: shell, systemd, networking and storage
general virtualisation concepts
prior Proxmox operational experience is helpful but not assumed

Learning outcomes

decide, on evidence, whether Proxmox VE is the right platform for a requirement
design node count, quorum, failure domains and the storage architecture
size CPU, memory, storage and network with the arithmetic shown, including N+1 and Windows Server licensing
scope a project and produce a bill of materials, a sequenced build plan and objective acceptance criteria
build and harden hosts, and design and apply the network safely
choose between LVM, ZFS, NFS, iSCSI and Ceph, and justify the choice
specify encryption against named threats, with a complete key register
build a least-privilege access model with realms, roles, ACLs and scoped API tokens
automate provisioning with the API, Terraform or OpenTofu, and Ansible
build and test high availability, and design around the platform's real failure modes

Detailed module structure

Unit 1: Design considerations and solution architecture

Topics:

what Proxmox VE is, and whether it is the right choice
Proxmox VE compared with VMware, Hyper-V, Nutanix, HPE VM Essentials and XCP-ng
what a Proxmox design actually decides
the N+1 principle
node count and quorum
cluster size and when to split
stretched clusters and latency
failure domains
converged or disaggregated storage architecture
documenting the design

Important framing: GEN is not aligned with Proxmox or any other vendor. The first duty of a builder is to check that the platform decision was made on evidence.

Lab:

design interrogation, with deliverables per client

Unit 2: Sizing and capacity planning

Topics:

the sizing method
CPU sizing and overcommit
how Windows Server licensing changes the arithmetic
memory sizing, the real constraint
ZFS ARC sizing
Ceph memory sizing
storage sizing for capacity and IOPS
network sizing
a complete worked sizing

Lab:

size a real cluster for a national veterinary group of 34 practices

Unit 3: Scoping, discovery and the build plan

Topics:

why scoping fails
the discovery checklist
turning discovery into a bill of materials
the build plan
acceptance criteria
handover

Lab:

interrogate a scoping brief: what is missing and what is assumed
build the risk register
state what you will not do

Unit 4: Host build and bootstrap

Topics:

firmware, out-of-band management and the BIOS/UEFI baseline
installation choices and automating the install
the post-install script
boot device selection
post-install baseline
certificates
host hardening baseline

Lab:

node bootstrap verification

Unit 5: Networking design and build

Topics:

designing the network first, and where filtering belongs
why a software firewall is not a firewall boundary
reference topologies
the full vocabulary of /etc/network/interfaces
choosing bond modes, and splitting bond members across physical cards
peer-to-peer mesh networking when there is no switch
VLANs, and letting the switch do the tagging
MTU and jumbo frames
applying and validating changes, with pre-staged fallback configurations
SDN and when to use it

Lab:

3-node hyper-converged cluster on a tight budget
6-node cluster with disaggregated NFS storage
4-node cluster at a manufacturing site in a hostile environment

Unit 6: Storage foundations, LVM and ZFS

Topics:

the Proxmox storage model
storage type comparison
LVM and LVM-thin, and the repair asymmetry between them
ZFS fundamentals for Proxmox
SLOG and L2ARC, and why they are usually not the answer
ZFS replication: HA without shared storage
scrubs, trim and monitoring
filesystem choice and recoverability, including BTRFS

Lab:

3-node cluster with no shared storage and HA wanted
single node at a branch office
an inherited, undocumented estate

Unit 7: Shared storage, NFS, iSCSI and Ceph

Topics:

why shared storage changes the design
NFS, and getting performance out of it
iSCSI and shared block storage, and why it disappoints on Proxmox
the one-LUN-per-node trap
snapshots as volume chains in PVE 9
GFS2, OCFS2 and ZFS over iSCSI
Ceph architecture and design decisions for builders
building Ceph on Proxmox
Ceph health and what the warnings mean
choosing between them

Lab:

choose the shared storage for a set of situations, and justify each choice

Unit 8: Encryption

Topics:

deciding what needs encrypting
encryption at rest with LUKS
ZFS native encryption
Ceph encryption
TLS for the web UI and API
backup encryption
key management in the design

Lab:

encryption decisions and the key register for a legal firm, an NHS trust department and a software company

Unit 9: Authentication, authorisation and access control

Topics:

the access model
realms, and why the hypervisor should not hang off Active Directory
built-in roles
building the access model
two-factor authentication, and why not on root@pam
API tokens
auditing

Lab:

choose the authentication model for a manufacturer, a regulated fintech, an MSP managing 40 client clusters, and a small cluster with no directory

Unit 10: The Proxmox API

Topics:

why the API matters to a builder
API structure and authentication
working with the API
asynchronous tasks
a practical API client
replacing the GUI with custom control surfaces, including console redirection
API design practices

Lab:

API exploration and a provisioning script
design question, no commands

Unit 11: Automation and infrastructure as code

Topics:

what to automate, and in what order
templates and cloud-init
Terraform and OpenTofu
Ansible
hook scripts
backup automation
automation practices

Lab:

build a template and provision from it

Unit 12: High availability

Topics:

what Proxmox HA actually provides
prerequisites
Corosync, quorum and QDevice
fencing and the watchdog
the HA stack, HA groups and resources
failure scenarios, and how the two planes fail independently
configuration mistakes that defeat quorum
HA with local storage using replication
testing HA as the acceptance gate
HA design checklist

Lab:

HA build and failover test

Unit 13: Proxmox fragility

Topics:

what actually breaks
pmxcfs and /etc/pve, the most sensitive component
the management plane is not the data plane
backing up the cluster database
why package upgrades are not a routine operation
it is still Linux
hardware, and the homogeneity trap
stage, test, then deploy
support: who fixes it at three in the morning
designing for the failures that actually happen

Lab:

fragility review: find and rank the failures waiting to happen
produce the remediation plan and the support model

Assessment

Design and justify a build

A regional logistics company is replacing an ageing three-host VMware cluster and an end-of-life SAN. Learners produce:

the design, with the sizing arithmetic shown
a sequenced build plan with test gates
ten pass/fail acceptance criteria
the automation, API token and backup job definition

Defend the design

“Why this node count rather than one fewer, and what happens at 14:00 on a Tuesday when room A loses power?”

Design on evidence, size with arithmetic, build it right first time

Ideal for engineers who turn a requirement into a working Proxmox platform

Training scope and tailoring

The training plan shown above is provided as a structured guide to the typical scope and direction of the course. Our training content is reviewed and refined over time, so the precise balance of modules, examples and exercises may vary when the course is delivered.

Where there are specific topics, technologies or operational outcomes that are particularly important to your team, these can normally be incorporated into the delivery plan by prior agreement. Training is not treated as a rigid, fixed package; it is adapted where appropriate to reflect the client environment, delegate experience level, group size and the objectives agreed in advance.