Hoe Proxmox werkt: ASNetworking legt VM's, containers, KVM en QEMU uit

Dank aan ASNetworking voor de duidelijke visuele uitleg in deze Spaanstalige Proxmox-cursus. Hoofdstuk twee bouwt het mentale model achter een gevirtualiseerde host op: wat een VM van een fysieke machine leent, hoe toewijzing van resources werkt, wanneer containers verschillen en waarom QEMU en KVM samen verschijnen. Bekijk de originele video voor de volledige uitleg van de maker.

Bekijk dit vóór het lezen: Deze conceptuele les van 20 minuten is nuttig als je Proxmox VE overweegt voor een homelab, maar eerst de verschillende lagen wilt begrijpen voordat je iets installeert. De diagrammen gaan van een fysieke server en meerdere gasten naar thin-provisioned schijven, containers, de Linux-kernel, QEMU en KVM. Sommige afbeeldingen tonen grote machines uit het bedrijfsleven of illustratieve capaciteiten; het zijn leervoorbeelden en geen hardwarespecificaties voor een compacte server.

Het belangrijkste onderscheid is tussen wat een gast te zien krijgt en wat de host daadwerkelijk beschikbaar heeft. Een VM kan zijn eigen CPU-kernen, RAM, schijf en besturingssysteem zien, terwijl die resources uiteindelijk van dezelfde fysieke host afkomstig zijn. Proxmox VE brengt VM- en Linux-containerbeheer samen in één interface; dit hoofdstuk legt de architectuur uit, in plaats van prestaties te meten of een voltooide installatie te demonstreren.

Eén fysieke host, meerdere afzonderlijke machines

Virtualisatie maakt het mogelijk om op één server meerdere gastbesturingssystemen als afzonderlijke VM's te draaien. Elke gast ziet virtuele hardware en kan zijn eigen applicaties uitvoeren, terwijl de host de onderliggende CPU plant en het fysieke geheugen, de opslag en het netwerk beheert. Daarom kunnen een test-VM met Linux en een afzonderlijke service-VM naast elkaar bestaan zonder dat voor elke taak een fysieke computer nodig is.

Overcommitten vereist een realistisch resourcebudget

ASNetworking introduceert overcommitten: meer virtuele resources aan gasten toewijzen dan de host zou kunnen leveren als elke gast ze tegelijk volledig opeist. Dat kan verstandig zijn wanneer workloads op verschillende momenten pieken. Het levert geen extra hardware op. Zware gelijktijdige belasting kan leiden tot CPU-concurrentie, geheugendruk of tragere opslag. Begin in een klein homelab met het fysieke RAM en de opslag die je daadwerkelijk hebt, reserveer ruimte voor de host en controleer het gebruik voordat je een nieuwe gast toevoegt.

Thin provisioning verandert wanneer schijfruimte wordt verbruikt

Een virtuele schijf kan een grotere logische capaciteit presenteren dan de fysieke ruimte die tot nu toe daadwerkelijk is verbruikt. De afbeelding in de video toont vijf virtuele schijven van 1 TB op een fysieke schijf van 1 TB, waarbij elke schijf momenteel 100 GB gebruikt. Dat werkt alleen zolang de daadwerkelijke schrijfbewerkingen op de fysieke schijf passen. Als de gasten hun virtuele schijven gezamenlijk vullen, kan de host al lang vóór de weergegeven capaciteiten een probleem lijken te vormen zonder vrije ruimte komen te zitten. Controleer de vrije fysieke ruimte, de opslagindeling, snapshots en back-ups in plaats van alleen op de opgegeven virtuele capaciteit te plannen.

De aflevering behandelt ook geheugentiering. RAM en tragere opslag hebben verschillende functies: koude gegevens naar een tragere laag verplaatsen kan helpen om druk te beheersen, maar opslag wordt daardoor niet zo snel als RAM. Beschouw elke functie die resources bespaart als een afweging die je aan de hand van de workload moet controleren, vooral op een host met beperkt geheugen.

Wat de hypervisor beheert

De hypervisor bevindt zich tussen de fysieke resources en de VM's. Het diagram op dit punt in de video benadrukt dat elke VM zijn eigen workload heeft, maar nog steeds afhankelijk is van de CPU, het RAM, de schijf en het netwerk van één host. Proxmox VE voegt de beheertools rond deze gasten toe, waaronder een webinterface en services voor configuratie en beheer. De architectuur omvat KVM-virtuele machines en LXC-containers.

VM's en containers bieden verschillende grenzen

Een VM bevat een gastbesturingssysteem en virtuele hardware. Een Linux-container isoleert applicaties en hun gebruikersruimte, terwijl deze de Linux-kernel van de host deelt. Daardoor is een container over het algemeen lichter dan een volledige VM, maar het is een ander isolatie- en besturingssysteemmodel. Een Windows-gast, of een workload die baat heeft bij een afzonderlijke kernel, hoort in een VM. Een geschikte Linux-service kan in een LXC-container passen. De Proxmox-documentatie voor LXC legt het containermodel uitgebreider uit.

Containers en VM's kunnen ook worden gecombineerd: een container-runtime kan binnen een VM draaien wanneer die grens geschikt is voor de implementatie. Het vergelijkingsschema in de video bevat bare metal, gevirtualiseerde, gecontaineriseerde en gecombineerde opstellingen. Kies de grens op basis van de service en de vereisten voor beveiliging, compatibiliteit en onderhoud; een container is niet simpelweg een kleinere VM.

Waar Linux, QEMU en KVM passen

Proxmox VE is een op Linux gebaseerd platform met een beheerinterface; je hoeft niet elk commando uit je hoofd te kennen om de rol van de onderdelen te begrijpen. De maker verwijst kort naar de downloadpagina van Proxmox en legt vervolgens de technische lagen onder een VM uit. Op het webscherm met downloads staat de productfamilie, terwijl het virtualisatiemodel directer wordt uitgelegd in het volgende QEMU/KVM-diagram.

KVM is de virtualisatiemogelijkheid in de Linux-kernel en gebruikt ondersteunde CPU-virtualisatie-extensies. QEMU levert het proces voor de virtuele machine en geëmuleerde of paravirtuele apparaten; samen voeren QEMU en KVM hardwareversnelde VM's uit. Dit is een nuttige manier om de labels in Proxmox te lezen, in plaats van QEMU en KVM als twee concurrerende hypervisors te zien. De Proxmox-handleiding voor QEMU/KVM behandelt VM-configuratie en mogelijkheden.

Pas het model toe op een klein homelab

De video toont kort een afbeelding met het marktaandeel van hypervisors. De percentages zijn niet nodig om een platform voor een homelab te kiezen en mogen niet worden beschouwd als onafhankelijk geverifieerde marktgegevens. De nuttigere vraag is concreet: welke workloads hebben een volledig gastbesturingssysteem nodig, welke kunnen een Linux-kernel delen en hoeveel passen binnen je werkelijke RAM- en opslagbudget?

Voor een compacte host zoals de ZimaBoard 2 mini-thuisserver kun je het beste eerst één of twee bescheiden services plannen, de CPU, het geheugen, het opstartmedium en de aangesloten opslag van het exacte model controleren en pas uitbreiden nadat je het werkelijke gebruik hebt gemeten. Dit is een toepassing van het resourcemodel uit de les, geen bewering dat de video benchmarks van de ZimaBoard 2 uitvoert of een specifiek aantal VM's valideert. Bewaar back-ups gescheiden van thin-provisioned virtuele schijven.

Nu deze lagen duidelijk zijn, kan het volgende hoofdstuk zich richten op praktische installatiekeuzes. Bekijk het installatiehoofdstuk van ASNetworking voor de bespreking van RAM, opslagindelingen en het vastzetten van netwerkinterfaces voordat je je eerste host bouwt.