Hoe de planner rekent

Voordat er één gast start gaat er 2 GB naar het besturingssysteem en de hypervisor-diensten. Dat is niet optioneel en niet iets waar je omheen kunt plannen.

Gebruik je ZFS, dan komt de ARC-cache daar bovenop. De aanbeveling is 2 GB basis plus 1 GB per TB opslag. Voor 8 TB is dat dus 10 GB — geheugen dat je niet aan VM's kunt geven. Sinds Proxmox VE 8.1 begrenst de installer ARC bij nieuwe ZFS-installaties automatisch op 10% van je RAM met een maximum van 16 GiB, maar pools die je zelf aanmaakt erven die limiet niet.

Een LXC-container deelt de kernel van de host. Een VM draait een eigen kernel en besturingssysteem, en dat kost 0,5 GB extra per exemplaar bovenop de werkende set van de dienst zelf. Dat is het getal dat de planner bij elke VM optelt.

Belangrijker dan die halve GB: een VM krijgt een vaste reservering, terwijl ongebruikt geheugen in een container beschikbaar blijft voor de rest van je server. Daarom staat bij vrijwel elke dienst LXC als voorkeur. De uitzonderingen zijn diensten die een eigen kernel nodig hebben — Home Assistant OS, TrueNAS, OPNsense en Windows — en die staan in de planner als niet-omzetbaar gemarkeerd.

KSM voegt identieke geheugenpagina's samen. Dat werkt alleen tussen VM's, en pas vanaf twee: met één VM valt er niets te dedupliceren. De planner rekent 12% besparing over het VM-geheugen zodra er twee of meer zijn.

Reken dat niet als harde capaciteit. Hoeveel KSM oplevert hangt af van hoe sterk je VM's op elkaar lijken, en het kan tegenvallen. Hetzelfde geldt voor ballooning: dat geeft ongebruikt geheugen terug aan de host, maar werkt niet in combinatie met PCIe-passthrough, en een te laag minimum betekent dat geheugen wordt weggenomen op het verkeerde moment.

De planner rekent 12% vrije marge als ondergrens en waarschuwt daaronder. Je hebt die ruimte nodig voor backups, een snapshot en het opstarten van een extra gast. Volledig volplannen betekent dat de host gaat swappen, en dat voelt als een defecte server.

Voor de CPU geldt iets anders: vCPU's mag je overboeken, geheugen niet. Tot ongeveer driemaal je aantal threads merk je er in een homelab weinig van; daarboven krijg je merkbare wachttijden. De planner waarschuwt vanaf 2,5× en meldt het als kritiek vanaf 4×. Meer vCPU's toewijzen dan een gast gebruikt maakt hem overigens langzamer, niet sneller.

De stroomkosten zijn recht toe recht aan: opgegeven wattage maal 24 uur maal 365 dagen, gedeeld door duizend, maal je kWh-prijs. Continu verbruik, dus geen rekening met idle-dips.

De VPS-vergelijking is een grove indicatie op basis van ongeveer € 1,6 per GB RAM per maand bij een Europese aanbieder. Controleer actuele tarieven zelf. Aanschaf van hardware, schijven en je eigen tijd zitten er niet in, dus gebruik het om een orde van grootte te vergelijken en niet als businesscase.

Dit is een planningshulpmiddel, geen meting van jouw server. De cijfers per dienst zijn richtwaarden: waar officiële documentatie een getal noemt is dat overgenomen en hierboven verantwoord, en waar die ontbreekt staat een richtwaarde uit typische homelab-configuraties.

Je werkelijke verbruik hangt af van je gebruik. Databases, mediaservers en ZFS zijn de drie plekken waar het in de praktijk het vaakst hoger uitvalt dan gepland. Reken daar marge, en meet na met arc_summary en pct-mem in plaats van op dit model te vertrouwen als eindstation.