Xen Summit 2026: VM vs Docker vs bare metal voor selfhosting

Xen Summit 2026 opent op 15 september in München, op een interessant moment voor virtualisatie. Docker kan vrijwel elke zelfgehoste applicatie verpakken die mensen belangrijk vinden, maar hypervisors blijven zich ontwikkelen voor cloud, beveiliging, embedded systemen en hardware-intensieve workloads.

De nuttige vraag voor de eigenaar van een homeserver is niet ‘Xen of Docker?’ Ze werken op verschillende lagen. De echte beslissing is: waar heeft elke workload zijn grens nodig?

Xen Summit 2026: waarom zijn hypervisors nog steeds belangrijk?

Xen Summit 2026 vindt plaats van 15 tot en met 17 september in München, met twee dagen technische lezingen, gevolgd door een dag met architectuur- en ontwerpsessies. Het programma omvat cloudinfrastructuur, beveiliging, Arm, embedded systemen, automotive, tooling en implementaties uit de praktijk.

Xen 4.22 verscheen ook kort voor de Summit. De huidige release wordt ondersteund tot en met juli 2029, waarbij de beveiligingsondersteuning doorloopt tot juli 2031. Die levenscyclus zegt iets over moderne virtualisatie: de waarde draait steeds minder om ‘hoeveel VM's kan deze machine uitvoeren?’ en steeds meer om hoe betrouwbaar kan infrastructuur workloads in de loop der tijd isoleren, beheren en onderhouden?

Daarom hebben containers hypervisors nooit overbodig gemaakt.

Docker heeft de virtuele machine niet overbodig gemaakt

Containers lossen een uiterst nuttig probleem op: applicaties en afhankelijkheden verpakken zonder voor elke service een volledig gastbesturingssysteem te verpakken.

De containerdocumentatie van Docker benadrukt het architecturale verschil: containers kunnen de kernel van de host delen, terwijl een virtuele machine een gastbesturingssysteem met een eigen kernel uitvoert.

Container
────────────
Afhankelijkheden en implementatie
Afhankelijkheden
────────────
Gedeelde kernel van de host


Virtuele machine
────────────
Afhankelijkheden en implementatie
Userspace van de gast
Kernel van de gast
────────────
Gevirtualiseerde hardware

Containers optimaliseren de implementatie van applicaties.

VM's creëren een extra grens rond het besturingssysteem.

En in echte infrastructuur worden ze vaak gestapeld:

Hardware
   ↓
Hypervisor
   ↓
Virtuele machine
   ↓
Container runtime
   ↓
Containers

Daarom is ‘VM versus Docker’ vaak de verkeerde discussie.

De echte vraag is welke grens de workload daadwerkelijk nodig heeft.

De vier grenzen van een zelfgehoste server

Accounts, rechten en gegevenstoegang

De fout is te verwachten dat één laag het probleem van een andere laag oplost.

Een container beschermt je niet tegen het uitvallen van de fysieke host. Zes VM’s op dezelfde SSD vormen geen zes onafhankelijke opslagsystemen. Een tweede server verhelpt zwakke authenticatie van applicaties niet.

En elke gewone webapp zijn eigen VM geven kan de implementatieoverhead opnieuw introduceren die containers juist moesten wegnemen.

Gebruik de goedkoopste isolatiegrens die daadwerkelijk aan de vereiste voldoet.

Heb je echt een VM nodig? Gebruik de test met vijf vragen

1. Heeft het een ander besturingssysteem of een andere kernel nodig?

Windows, een complete tweede Linux-distributie, een firewall-appliance of testen op besturingssysteemniveau zijn voor de hand liggende VM-kandidaten.
            ↓
           VM

Ander besturingssysteem / andere kernel vereist?

2. Heeft het een afzonderlijke vertrouwensgrens nodig?

Beveiligingsexperimenten, minder vertrouwde software, buildworkers en wegwerpbare testomgevingen kunnen rechtvaardigen dat het gastbesturingssysteem van de primaire host wordt gescheiden.

Een VM is niet automatisch ‘veilig’, maar biedt een andere isolatiegrens dan een ander proces dat dezelfde hostkernel deelt.

3. Heeft het controle op laag niveau over het besturingssysteem of netwerk nodig?

Firewalls, routeringslabs en appliancebesturingssystemen hebben er vaak baat bij een eigen besturingsomgeving te hebben, in plaats van de containerhost telkens opnieuw aan te passen.

4. Heeft het directe eigendom over hardware nodig?

Hier wordt virtualisatie bijzonder interessant.

• Een workload heeft mogelijk een:
• GPU,
• netwerkadapter,
• USB-controller,
• ander PCIe-apparaat.

De huidige infrastructuurdocumentatie van Xen bevat juist PCI-passthrough en SR-IOV, omdat de architectuurvraag soms wordt:

welke gast deze fysieke apparatuur beheert?

5. Is het gewoon een andere applicatie?

Als de workload een conventioneel dashboard, mediaservice, databasegestuurde webapp, downloadtool of automatiseringsservice is en geen andere kernel of speciale vertrouwensgrens vereist, is een container meestal het eenvoudigste startpunt.

VM versus container versus bare metal voor homeservers

Het belangrijke onderscheid is dat resourcegebruik en isolatie afzonderlijke vragen zijn.

Een kleine Linux-VM gebruikt mogelijk heel weinig. Een AI-container kan een volledige GPU en tientallen gigabytes geheugen gebruiken.

Het één-boxprobleem: consolidatie heeft drie grenzen

De meeste dimensionering van homeservers begint bij CPU en RAM. In de praktijk kan een geconsolideerde server om drie verschillende redenen “vol” raken.

Rekencapaciteitsgrens

De bekende: er is niet genoeg CPU, RAM, opslagprestaties, GPU-capaciteit of VRAM voor nog een workload.

Isolatiegrens

De host heeft nog steeds beschikbare resources, maar je wilt niet langer dat een andere workload dezelfde kernel, rechten, hardware- of beheergrens deelt.

Uitvalgrens

De workloads passen technisch gezien, maar te veel belangrijke services vallen nu tegelijk uit.

Eén fysieke host
├── DNS
├── opslag
├── Home Assistant
├── media
├── Windows-VM
└── experimenten

Eén herstart heeft nu gevolgen voor het hele huis.

Dit geeft serverconsolidatie voor thuis een beter model:

Servercapaciteit
wordt niet alleen beperkt door:

CPU + RAM

Het kan ook worden beperkt door:

Isolatietolerantie

of

Uitvaltolerantie

Een server kan zijn isolatie- of uitvalgrens bereiken lang voordat de CPU 100% wordt belast.

Virtuele isolatie is geen fysieke redundantie

Zes VM's maken geeft je zes nuttige softwaregrenzen. Het geeft je geen zes onafhankelijke fysieke machines.

De host valt uit
   ↓
De hypervisor stopt
   ↓
Elke VM op die host stopt

Hetzelfde geldt voor opslag. Vijf VM-schijven op één defecte SSD zijn nog steeds vijf onbeschikbare VM-schijven.

Dit wordt vooral belangrijk wanneer een homelab ongemerkt uitgroeit tot een productieomgeving thuis.

Drie echte virtualisatielessen uit Zima-thuislabs

Het grensmodel wordt gemakkelijker te begrijpen wanneer het op echte hardware wordt toegepast in plaats van op diagrammen.

1. Een lichtgewicht VM-host heeft nog steeds een geheugenplafond

ZimaOS biedt sinds versie 1.3 native ZVM-ondersteuning, inclusief installatie van Windows- en Linux-VM's met één klik. De huidige hardwarevereisten voor virtuele machines maken ook een belangrijk punt duidelijk dat generieke calculators voor “hoeveel VM's?” vaak verbergen: het gasttype, de actieve workload, snapshots en geheugentoewijzing zijn belangrijker dan een vast aantal VM's.

Een recente test uit de praktijk kwam tot dezelfde conclusie. Mart draaide een Windows 7-VM onder Proxmox op een compacte server met 8 GB en liet zien dat één bescheiden gast realistisch was, maar dat het gastgeheugen al snel de beschikbare middelen voor de host en andere services vermindert. De Proxmox- en Windows-VM-test herinnert er nuttig aan dat virtualisatie geen RAM creëert.

De eerste virtualisatiegrens op een kleine server is vaak het geheugen, niet de CPU.

2. Passthrough draait eigenlijk om eigenaarschap

De Proxmox-build van Jonatan Castro uit 2026 maakt de vraag rond de hardwaregrens duidelijker.

In zijn opstelling draait ZimaOS als VM, terwijl vanuit Proxmox een fysieke SATA AHCI-controller wordt doorgegeven. ZimaOS ziet vervolgens de aangesloten schijven en maakt RAID op gastniveau aan.

Fysieke SATA-schijven
       ↓
SATA-controller
       ↓
PCI-passthrough
       ↓
ZimaOS-VM
       ↓
Opslagbeheer

De waarde zit niet alleen in het feit dat “een NAS in een VM kan draaien”.

Het nuttige architectuurdetail is dat het eigenaarschap van de opslag expliciet is: in plaats van de gast alleen abstracte virtuele schijven te geven, ontvangt de gast de relevante fysieke controller.

De volledige Proxmox-virtualisatie- en SATA-passthrough-build laat ook zien waarom PCIe-topologie en IOMMU-ondersteuning belangrijk zijn zodra virtualisatie echte apparaten gebruikt.

3. Eén box kan veel dingen draaien — maar HA vereist een extra box

Deze build biedt ook een nog betere les over de storingsgrens.

Eén compacte node verwerkt een groot deel van de serviceworkload, terwijl een afzonderlijke NAS-node en quorumapparaat deelnemen aan het bredere Proxmox-ontwerp. Services die voor HA zijn gemarkeerd, kunnen worden verplaatst wanneer één node opnieuw wordt opgestart.

Die architectuur maakt een onderscheid zichtbaar dat benchmarks van één server niet kunnen aantonen:

Veel VM's op één host
≠
Hoge beschikbaarheid

Meerdere storingsbestendige nodes
+
gedeeld/verplaatsbaar workloadontwerp
=
een pad naar HA

Voor een gewone homeserver heb je geen hoge beschikbaarheid nodig. Maar als de vereiste is dat “deze workload blijft werken wanneer één fysieke node uitvalt”, voldoet het aanmaken van een andere VM op dezelfde node daar niet aan.

Welke hardwarefuncties zijn werkelijk belangrijk voor virtualisatie?

‘Ondersteunt virtualisatie’ is te vaag zodra het lab verder gaat dan eenvoudige VM's.

Voor gewone gasten zijn CPU-virtualisatieondersteuning, voldoende RAM en snelle VM-opslag de basis.

Kijk voor passthrough- en netwerkexperimenten ook naar:

• IOMMU-ondersteuning zoals Intel VT-d of AMD-Vi,
• beschikbare PCIe-uitbreiding,
• meerdere fysieke netwerkinterfaces,
• firmwareondersteuning,
• apparaat-/IOMMU-groepering,
• voldoende geheugen voor zowel de host als de gasten.

De huidige documentatie over PCI-passthrough van XCP-ng maakt expliciet onderscheid tussen normale CPU-virtualisatie en de IOMMU-functionaliteit die nodig is voor het toewijzen van fysieke apparaten.

Voor een compact homelab kan een compacte x86-thuisserver met VT-x, VT-d, PCIe-uitbreiding en meerdere Ethernetinterfaces daarom interessanter zijn dan simpelweg de CPU met het grootste aantal cores kopen.

De hardware moet aansluiten bij de grens die je probeert te creëren.

Xen is een hypervisor; XCP-ng is een platform

De Xen Summit legt ook een andere veelvoorkomende verwarring rond virtualisatie bloot: projecten op verschillende lagen worden vaak vergeleken alsof het gelijkwaardige producten zijn.

Xen vormt de basis van de hypervisor.

XAPI biedt beheertools rond Xen.

XCP-ng verpakt die componenten in een compleet virtualisatieplatform.

Virtualisatieplatform
───────────────────────
XCP-ng + beheer

Beheer/toolstack
───────────────────────
XAPI

Hypervisor
───────────────────────
Xen

Hardware
───────────────────────
CPU / RAM / NIC / GPU / Opslag

Hetzelfde principe geldt elders: een virtualisatieplatform is meer dan alleen de onderliggende hypervisor.

Voor een self-hoster gaat de praktische keuze daarom niet alleen over hypervisortechnologie. Het gaat ook om de levenscyclus van VM's, netwerken, opslag, back-ups en hoeveel van dat platform je daadwerkelijk wilt beheren.

AI maakt hardware-eigenaarschap weer relevant

Containers maakten het verpakken van applicaties draagbaarder. Lokale AI herinnert infrastructuurbouwers eraan dat hardware minder draagbaar is.

Een GPU roept vragen op die een normale webcontainer mogelijk nooit nodig heeft:

Wie beheert de GPU?

Heeft één VM het volledige apparaat nodig?

Waar bevinden de drivers zich?

Kan het apparaat netjes worden gereset?

Kunnen meerdere workloads deze delen?

Stelt de host bruikbare IOMMU-groepen beschikbaar?

Dit is een van de redenen waarom passthrough relevant blijft in een Docker-first wereld.

Containers vereenvoudigden software-eigenaarschap. Accelerators brachten hardware-eigenaarschap terug in de architectuurdiscussie.

De juiste grens is belangrijker dan het aantal VM's

Xen Summit 2026 is nuttig voor self-hosters, zelfs als ze Xen nooit installeren.

De bredere les is dat bare metal, VM's en containers geen volwassenheidsniveaus zijn waarbij het ene uiteindelijk het andere vervangt.

Bare metal
→ direct eigenaarschap van hardware

Virtuele machine
→ grens voor besturingssysteem / kernel

Container
→ applicatiegrens

Applicatierechten
→ grens voor gebruiker / gegevens

Gebruik containers wanneer een applicatiegrens volstaat.

Gebruik een VM wanneer het besturingssysteem, het vertrouwensmodel of het eigenaarschap van fysieke apparaten een eigen grens verdient.

Gebruik bare metal wanneer een extra abstractielaag meer complexiteit bij herstel toevoegt dan nuttige flexibiliteit oplevert.

En wanneer één machine alles begint te dragen, vraag dan niet alleen of er nog CPU-capaciteit over is.

Vraag welke limiet je hebt bereikt:

Computeplafond?

Isolatieplafond?

Plafond voor storingen?

Het doel van virtualisatie is niet om het aantal VM's te maximaliseren. Het gaat erom de juiste grens rond de juiste workload te plaatsen.

Veelgestelde vragen

Wanneer vindt Xen Summit 2026 plaats?

Xen Summit 2026 vindt plaats van 15 tot en met 17 september in München, Duitsland. Op 15 en 16 september staan technische lezingen centraal; 17 september is gewijd aan ontwerpsessies en projectplanning.

Is Xen hetzelfde als XCP-ng?

Nee. Xen is de onderliggende hypervisor. XCP-ng is een compleet virtualisatieplatform dat is gebouwd rond Xen en de XAPI-toolstack, met mogelijkheden voor beheer, opslag, netwerken en de levenscyclus van VM's.

Moet ik voor self-hosting een VM of Docker gebruiken?

Gebruik een container wanneer een applicatie veilig de kernel van de host kan delen en vooral reproduceerbare packaging nodig heeft. Overweeg een VM wanneer de workload een ander besturingssysteem, een andere kernel, een vertrouwensgrens of een eigen hardwaretoewijzing nodig heeft.

Wanneer moet ik bare metal gebruiken in plaats van een VM?

Bare metal kan eenvoudiger zijn wanneer één workload de machine domineert, directe controle over hardware belangrijk is of passthrough de herstelcomplexiteit zou vergroten zonder nuttige isolatie te bieden.

Kan ik een NAS in een VM draaien?

Ja, maar leg duidelijk vast wie eigenaar is van de opslag. Door een opslagcontroller door te geven kan de NAS-guest directere controle krijgen over fysieke schijven, terwijl bare metal eenvoudiger kan blijven wanneer opslag de primaire rol van de machine is.

Beschermt virtualisatie tegen het uitvallen van een fysieke server?

Nee. VM's isoleren softwareomgevingen, maar kunnen nog steeds één moederbord, voeding en opslagsysteem delen. Meerdere VM's op één host zorgen niet voor fysieke redundantie.

Wat is er nodig voor GPU-passthrough?

GPU- en andere PCI-passthrough vereisen doorgaans IOMMU-ondersteuning, zoals Intel VT-d of AMD-Vi, naast gewone CPU-virtualisatie, plus compatibele firmware, apparaat-topologie en hypervisorconfiguratie.