100 cards · 5 suits · free

    The Proxmox Tarot

    One hundred illustrated cards, each explaining a single Proxmox VE concept in plain English. The Major Arcana covers the fundamentals; four suits cover compute, storage, networking, and backup and cluster operations. Read it in order and it is a curriculum; draw at random and it is a flashcard deck.

    All Proxmox guides

    Showing 100 of 100 cards

    Every card, in order

    Major ArcanaCore concepts

    1. PROXMOX VE
    One free platform, a whole datacenter of tricks. Proxmox VE bundles KVM virtual machines, LXC containers, software-defined storage, networking, clustering, and backups under one web interface — open source, enterprise-grade in practice.
    2. THE NODE
    Before the cluster, there is the node. A node is one physical machine running Proxmox — the actual metal that carries every virtual world you create. Most homelabs start with exactly one.
    3. THE HYPERVISOR
    The most important software layer you never see. A hypervisor lets one machine run many isolated operating systems at once. Proxmox is a type-1: it runs on bare metal, not inside another OS.
    4. KVM
    Your hypervisor has been inside Linux all along. KVM turns the Linux kernel itself into a hypervisor — VMs run as regular processes with near-native performance, hardware-accelerated by your CPU.
    5. QEMU
    Every VM needs a body. QEMU builds it. QEMU conjures the virtual hardware — disks, network cards, displays, USB — while KVM supplies the raw speed. Together they are the engine room of every Proxmox VM.
    6. THE VIRTUAL MACHINE
    A complete computer, dreamed inside another. A VM has its own firmware, kernel, and OS — fully isolated, believing it owns real hardware. Break it, snapshot it, clone it: the host never notices.
    7. THE CONTAINER (LXC)
    Why boot a whole OS when you can borrow one? LXC containers share the host's kernel — near-zero overhead, seconds to start, a fraction of the RAM. Perfect for the twenty small services every homelab accumulates.
    8. THE KERNEL
    One root feeds the whole forest. The kernel is the core of the OS — and on Proxmox, one Linux kernel powers the host and every container on it. Only VMs bring their own.
    9. THE CLUSTER
    Many towers, one will. Join nodes into a cluster and they share configuration, migrate VMs between each other, and appear as a single system. Three nodes is the magic number — you'll learn why at the Quorum card.
    10. THE WEB GUI
    Your entire virtual kingdom, ruled from a browser tab. Port 8006: create VMs, watch graphs, move workloads, restore backups. Everything the CLI can do, most of it two clicks away.
    11. THE DATACENTER
    The view from the mountaintop. "Datacenter" is the top level of the Proxmox tree — settings that span every node: users, storage definitions, firewall rules, HA. Set once, applies everywhere.
    12. THE CLI
    The plain words of power. qm for VMs, pct for containers, pvesh for the whole API. Everything the GUI does has a command underneath — and scripts don't click buttons.
    13. THE TEMPLATE
    Build once. Stamp forever. Convert a configured VM into a template and every future clone starts pre-installed, pre-hardened, ready in seconds. The golden image is the oldest sysadmin magic there is.
    14. THE CLONE
    One made two, alike in every line. A full clone is independent; a linked clone shares the template's base disk and only stores its changes — near-instant and tiny. Know which one you're making.
    15. THE SNAPSHOT
    A moment, crystallized against regret. A snapshot freezes a VM's disk (and optionally RAM) in place — roll back a failed upgrade in seconds. But it lives with the VM. It is not a backup. Say it with me.
    16. THE BACKUP
    The realm, rewritten in patient ink. A backup is a complete copy stored somewhere else — surviving disk death, node death, and your own worst commands. Snapshots protect you from mistakes; backups protect you from everything.
    17. THE RESTORE
    A backup you've never restored is a rumor. Restoring rebuilds the full VM from its archive — and testing that restore is the only proof your backup strategy exists. Schedule the fire drill.
    18. HIGH AVAILABILITY
    When one falls, another already stands. Mark a VM as HA and the cluster restarts it on a surviving node when its host dies — automatically, in minutes, while you sleep. Requires a quorate cluster and shared or replicated storage.
    19. LIVE MIGRATION
    The world walks, and never wakes. Live migration moves a *running* VM between nodes — memory streamed across, a final pause of milliseconds, users none the wiser. Drain a node, patch it, refill it. Zero downtime.
    20. PROXMOX BACKUP SERVER
    The vault beyond the walls. PBS is Proxmox's dedicated backup appliance: incremental forever, deduplicated, encrypted, verified on schedule. Give it its own box — the vault should not share a roof with the treasure.
    21. THE FIREWALL
    The gate that questions all who pass. Proxmox ships a built-in firewall at three levels — datacenter, node, and per-VM. Default-deny at the edge, explicit allows per service, and your lab stops being an open house.
    22. THE HOMELAB
    The whole small kingdom, kept for joy. A homelab is permission to break things: your own datacenter in miniature, where every skill is learned twice — once from the docs, once from the outage.

    VesselsCompute & VMs

    23. vCPU
    Slices of one mind, dealt to many. vCPUs are shares of your real cores handed to VMs — and you can promise more than you have, because most VMs idle most of the time. Overcommit is a feature, not a sin. Watch the load average.
    24. CPU TYPE: HOST
    Wear the true face of the machine. CPU type "host" exposes your processor's real features to the VM — maximum performance, full instruction sets. The price: live migration only works between identical CPUs. Mixed cluster? Pick a common baseline like x86-64-v3.
    25. MEMORY BALLOONING
    Breath given, breath reclaimed. The balloon driver lets the host quietly reclaim idle RAM from guests and hand it to whoever needs it now. Set min/max memory and let the vessels breathe.
    26. VIRTIO
    The straight road, free of toll gates. VirtIO drivers let the guest *know* it's virtual and skip hardware emulation entirely — dramatically faster disk and network. Default for Linux; install the driver ISO for Windows.
    27. QEMU GUEST AGENT
    The envoy who speaks for the world within. The guest agent runs inside the VM and talks to the host: clean shutdowns, real IP addresses in the GUI, filesystem-freeze for consistent snapshots. Two minutes to install, permanently useful.
    28. CLOUD-INIT
    A name, a key, a purpose at first breath. Cloud-init injects hostname, SSH keys, network config, and users into a VM at first boot. Combined with a template, a ready-to-SSH server takes about forty seconds.
    29. PCI PASSTHROUGH
    The relic handed through the glass. Passthrough gives a VM direct control of a real PCIe device — GPU, HBA, NIC — with bare-metal performance. The host gives it up entirely; the guest owns it completely.
    30. IOMMU
    Walls that keep each spirit to its garden. The IOMMU (Intel VT-d / AMD-Vi) maps and isolates device memory access — it's what makes passthrough safe instead of reckless. Enable it in BIOS, verify your groups, then pass things through.
    31. GPU PASSTHROUGH
    The painter's engine, given whole. Pass a full GPU into one VM for local AI, transcoding, or a gaming guest. One device, one VM — the host waves goodbye at boot.
    32. vTPM
    A secret heart, sealed and sworn. A virtual TPM 2.0 gives a VM the secure chip modern OSes demand — Windows 11 won't install without it. Add it in options; it lives encrypted with the VM.
    33. UEFI (OVMF)
    The modern rite of waking. OVMF gives VMs UEFI firmware instead of legacy BIOS — required for Secure Boot, GPU passthrough setups, and modern guests. New VM? Default to it.
    34. MACHINE TYPE (q35)
    The newer chassis beneath the dream. q35 is the modern virtual chipset with native PCIe — the right frame for passthrough and current operating systems. i440fx is the old cart: it still rolls, but you know better.
    35. HOTPLUG
    Gifts accepted without sleep. Hotplug lets a running VM accept new disks, NICs, RAM — even vCPUs — without a reboot. The carriage keeps rolling while you hang new lanterns on it.
    36. NUMA
    Near memory is sweetest. On multi-socket systems, each CPU has *local* RAM — crossing to the other socket's memory costs latency. Enable NUMA awareness so big VMs keep their memory close to home.
    37. CPU AFFINITY
    Bound to chosen hearths. Affinity pins a VM's vCPUs to specific physical cores — steady latency for the workloads that hate surprises, clean separation for the noisy ones.
    38. UNPRIVILEGED CONTAINER
    A lantern with clipped keys. In an unprivileged container, root inside maps to a nobody-user outside — escape the container and you land powerless. It's the default for a reason. Stay unprivileged unless a mount forces your hand.
    39. CT TEMPLATE
    The folded seed of a lantern. Container templates are ready-made root filesystems — Debian, Ubuntu, Alpine — downloaded once, spawned endlessly. A new service in under a minute, a few hundred MB each.
    40. NESTED VIRTUALIZATION
    A dream within the dream. Nested virt lets a VM run its own hypervisor — a Proxmox cluster *inside* one Proxmox VM. The safest possible place to rehearse dangerous things.
    41. RESOURCE LIMITS
    Measured portions keep the peace. Cores, cpulimit, memory caps: limits stop one hungry guest from starving the table. Set them before the noisy neighbor incident, not after.

    WellsStorage

    42. ZFS
    The living well that remembers all. ZFS is filesystem and volume manager in one — it checksums every block, heals silent corruption from redundancy, and snapshots for free. The single best reason to give your storage plenty of RAM.
    43. COPY-ON-WRITE
    Never erase; write beside. ZFS never overwrites data in place — changes are written to new blocks and pointers flip atomically. That's why snapshots are instant and power loss doesn't shred your filesystem.
    44. STORAGE POOL
    Many springs, one water. A pool fuses your disks into one addressable space; datasets and VM volumes draw from it as needed. Design the pool right and everything above it is easy.
    45. MIRROR
    Twin wells share one truth. A mirror writes everything to two (or more) disks — lose one, keep running, resilver fast. For homelab VM storage, mirrors beat parity more often than people expect.
    46. RAID-Z
    The braided rope survives a cut strand. RAID-Z stripes data with parity — Z1 survives one dead disk, Z2 two. More usable space than mirrors, slower rebuilds. Capacity storage loves it; VM storage tolerates it.
    47. ARC
    The sweetest water kept at the lip. ARC is ZFS's RAM read-cache — your hottest data served from memory. This is the famous "ZFS eats RAM": it's not eating, it's *caching*, and it gives it back when asked.
    48. SLOG
    The oath written before the ink dries. A SLOG device absorbs synchronous write logging on fast storage so sync-heavy workloads (NFS, databases) stop waiting on your data disks. Useless for async writes — know your workload first.
    49. L2ARC
    A second shelf for warm memories. L2ARC extends the read cache onto SSD when RAM runs out of room. Rule of thumb: max out RAM first — the second shelf only matters when the first is full.
    50. SCRUB
    The patient lamp inspects every stone. A scrub reads every block in the pool, verifies checksums, and repairs damage from redundancy. Schedule it monthly — silent corruption only stays silent if nobody checks.
    51. RESILVER
    The broken mirror rewoven. When you replace a failed disk, resilvering rebuilds its data from the survivors. Modern ZFS only copies actual data, not empty space — but your pool is fragile until it finishes.
    52. DATASET
    A garden with its own gate and law. Datasets are filesystems within the pool, each with its own compression, quota, and snapshot policy. One per purpose — backups, media, VMs — and the rules never fight.
    53. zvol
    A channel carved in the shape of a disk. A zvol is a block device carved from the pool — this is how VM disks live on ZFS, snapshots and checksums included. A pond cut in stone, sized to order.
    54. LVM
    Land redrawn without moving the earth. LVM abstracts disks into volumes you can resize and rearrange without repartitioning. The default when Proxmox installs to a single disk without ZFS.
    55. LVM-THIN
    Fields promised before they are plowed. LVM-thin pools allocate space only when written — enabling snapshots and overprovisioning on plain LVM. The default VM storage on non-ZFS installs.
    56. THIN PROVISIONING
    Promise wide, fill as needed. Give ten VMs 100 GB each on a 500 GB store — space is consumed only as they actually write. Glorious efficiency, right up until everyone drinks at once. Monitor the real fill line.
    57. qcow2
    The folding flask that grows as poured. qcow2 is QEMU's copy-on-write disk format — grows with use, carries internal snapshots, moves anywhere as a single file. The flask expands as you pour.
    58. NFS
    The shared table across the river. NFS exports a directory over the network — the easiest shared storage a cluster can have, and every node sees the same files. ISOs, backups, even VM disks if the network is honest.
    59. iSCSI
    A distant cellar, felt as one's own. iSCSI serves raw block storage over the network — the remote LUN mounts like a local disk. Your SAN protocol on commodity everything.
    60. CEPH
    The sea that heals its own storms. Ceph spreads replicated storage across your cluster nodes — any node can die and data flows on, rebalancing itself. Hyperconverged: your compute *is* your SAN. Wants three nodes and honest networking.
    61. OSD
    Each keeper minds one cask. An OSD is the Ceph daemon owning one disk — storing, replicating, rebalancing its share. More casks, more keepers, more parallel hands.

    BridgesNetworking

    62. LINUX BRIDGE
    The crossroads where all lanterns meet. vmbr0 is a virtual switch inside your node: VMs plug into it, it plugs into your NIC, and everyone reaches the world. The first networking concept every Proxmox user meets.
    63. VLAN
    Ribbons keep the roads apart. VLANs slice one physical network into isolated virtual ones by tagging packets — lab, IoT, and trusted traffic on the same wire, never touching. Segmentation is the cheapest security you'll ever deploy.
    64. BOND (LACP)
    Two ropes, one pull. Bonding joins NICs into one logical link — survive a cable failure, aggregate throughput. LACP needs a switch that speaks it; active-backup works anywhere.
    65. VIRTIO NIC
    The gate that needs no translator. The VirtIO network adapter skips hardware emulation for multi-gigabit guest speeds. e1000 exists for compatibility; VirtIO exists for actually moving data.
    66. MTU
    The gate measures every cart. MTU is the largest packet a link accepts — mismatched MTUs cause the weirdest failures in networking: pings pass, transfers hang. When traffic acts haunted, check the gate first.
    67. JUMBO FRAMES
    Wider gates for greater loads. MTU 9000 moves storage traffic with fewer, larger packets — less CPU, more throughput. But *every* hop must agree: one narrow gate on the path and carts jam.
    68. SDN
    Roads redrawn by the mapmaker's hand. Proxmox SDN defines networks in software across the whole cluster from the GUI — zones, VNets, subnets — no per-node interface surgery.
    69. VNET
    One kingdom's roads above many lands. A VNet is a virtual network spanning your nodes — VMs join it anywhere in the cluster and share one seamless layer-2 world.
    70. NAT
    All letters leave under one seal. NAT lets many private addresses share one public one — every outgoing packet re-stamped with the house crest, replies routed back to the right room.
    71. DHCP
    Every traveler receives a number. DHCP hands out IPs automatically. In the lab, reserve fixed addresses for infrastructure — the servers should live at numbers you know by heart.
    72. DNS
    Names traded for places. DNS turns names into addresses. Run your own resolver and your lab gets memorable hostnames, ad-blocking, and one more thing to blame when anything breaks. (It's always DNS.)
    73. MAC ADDRESS
    The birthmark no paint conceals. Every interface carries a unique hardware address; your VMs get generated ones. Pin DHCP reservations and firewall rules to it — the sigil under the lantern never changes.
    74. TAGGED / UNTAGGED
    Some wear the ribbon; some go plain. Trunk ports carry tagged traffic for many VLANs; access ports strip the tag and serve exactly one. Half of all VLAN confusion is just these two words.
    75. OPEN vSWITCH
    A grander crossroads with many rules. OVS replaces the Linux bridge with a programmable switch — richer VLAN handling, tunneling, flow rules. Most labs never need it; the ones that do, really do.
    76. PORT FORWARDING
    A door in the wall to one room only. Forwarding maps an external port to one internal host and service. Every open door is a promise to defend — count yours occasionally.
    77. REVERSE PROXY
    One herald answers for many houses. A reverse proxy is the single entrance routing visitors to services by hostname — TLS certificates managed in one place, internal ports never exposed. The herald with the directory.
    78. WIREGUARD
    A private thread through the wild. WireGuard is a modern VPN in a few thousand lines — keys exchanged, tunnel up, your lab reachable from anywhere as if you never left the house.
    79. SECURITY GROUP
    One law, pinned to many gates. Security groups are reusable firewall rule-sets — write "web server rules" once, attach everywhere, update in one place. Stop copying rules by hand.
    80. SUBNET
    Neighborhoods drawn in the same ink. A subnet is an IP range forming one network segment — /24 is your familiar 254-house street. Plan your neighborhoods before the town sprawls.

    ScrollsBackup, DR & Cluster Ops

    81. VZDUMP
    The city, rolled into a scroll. vzdump is Proxmox's backup engine — snapshot mode archives a *running* VM with barely a pause. One command, one schedule, whole cities preserved nightly.
    82. CHUNK
    Great works travel in small stones. PBS splits every backup into content-addressed chunks — small, hashed, reusable pieces. Everything clever about PBS (dedup, incrementals, verify) starts here.
    83. DEDUPLICATION
    One stone serves every mosaic. Identical chunks are stored exactly once, no matter how many VMs or backup runs contain them. Fifty Debian VMs, one set of Debian chunks. Watch the dedup factor climb.
    84. INCREMENTAL
    Write only what the night changed. After the first backup, PBS transfers only changed data — nightly backups of large VMs finish in minutes, not hours. The ledger grows one line at a time.
    85. RETENTION
    Seven suns, four moons, six seasons. Retention policy decides what history you keep: keep-daily 7, keep-weekly 4, keep-monthly 6 covers most sins. Decide how far back "undo" must reach, then write it down.
    86. PRUNE
    The gardener trims what time has spent. Pruning applies your retention policy — old backups marked for removal, the shelf kept honest. Automate it; a garden untrimmed becomes a wall.
    87. VERIFY
    Every seal, tested by lamplight. Verification re-reads backups and re-checks every chunk's hash on a schedule — bit rot found *now*, not during the restore you desperately need.
    88. BACKUP ENCRYPTION
    Written in a tongue only you read. PBS encrypts client-side — the server stores ciphertext it can never read. Guard the key like the treasure it protects: lose it and the scrolls stay sealed forever.
    89. SYNC JOB
    The vault's twin beyond the mountains. Sync jobs replicate a PBS datastore to a remote one — the offsite leg of your strategy, automated. When the house burns, the mountain twin remembers everything.
    90. GARBAGE COLLECTION
    Unclaimed stones return to dust. After pruning, GC finds chunks no backup references anymore and reclaims the space. Prune marks; garbage collection sweeps. Schedule both.
    91. 3-2-1 RULE
    Three copies, two vessels, one afar. Three copies of the data, on two different media, one offsite. Old wisdom, still undefeated — everything fancier is decoration on this.
    92. COROSYNC
    The heartbeat drum all towers share. Corosync carries cluster membership and messaging — it decides who's alive. It craves low latency, not bandwidth; give it its own small network and it will never lie to you.
    93. QUORUM
    The council votes before the realm acts. A cluster only acts while a majority of votes are present — that's what stops two halves from ruling at once. It's also why two-node clusters need help (next card).
    94. QDEVICE
    The distant elder breaks the tie. A QDevice adds an external tiebreaker vote from any small machine — a Pi will do. Two-node cluster plus QDevice: lose either node, keep quorum, keep running.
    95. FENCING
    The fallen tower is bound before repair. Before HA restarts a dead node's VMs elsewhere, the node must be provably isolated — or the same VM could run twice and eat its own disk. Fencing is the binding that makes recovery safe.
    96. SPLIT-BRAIN
    Two kings, one crown — so none may rule. A split-brain is two cluster halves each believing they're in charge — writing to the same storage from both sides is how data dies. Quorum exists so the minority half kneels instead.
    97. MAINTENANCE MODE
    Rest, wrapped in grey ribbon. Maintenance mode drains a node gracefully — workloads migrate off, HA stands down, and you patch and reboot in peace. Update the towers one ribbon at a time.
    98. STORAGE REPLICATION
    The garden repainted nightly next door. pvesr ships ZFS snapshots between nodes on a schedule — every few minutes, the neighbor holds a near-current copy. No shared storage needed; failover loses only the last interval.
    99. WATCHDOG
    The hound that wakes the sleeping heart. The watchdog is a timer the node must keep resetting — hang, and it forces a reboot. It's the muscle behind HA's self-fencing: the hound pulls the bell when the hearth goes cold.
    100. TASK LOG
    Every deed, inked as it happens. Every action — every migration, backup, and 2 a.m. mistake — is recorded in the task log with full output. The last card's lesson is the first habit: when anything breaks, read the log before you guess.