Xen Summit 2026: VM vs. Docker vs. Bare Metal für Self-Hosting

Der Xen Summit 2026 beginnt am 15. September in München – zu einem interessanten Zeitpunkt für die Virtualisierung. Docker kann nahezu jede selbst gehostete Anwendung paketieren, die für Nutzer relevant ist, und dennoch entwickeln sich Hypervisoren in den Bereichen Cloud, Sicherheit, eingebettete Systeme und hardwareintensive Arbeitslasten weiter.

Die nützliche Frage für Besitzer eines Heimservers lautet nicht „Xen oder Docker?“. Sie arbeiten auf unterschiedlichen Ebenen. Die eigentliche Entscheidung lautet: Wo benötigt jede Arbeitslast ihre Grenze?

Xen Summit 2026: Warum sind Hypervisoren weiterhin wichtig?

Der Xen Summit 2026 findet vom 15.–17. September in München statt, mit zwei Tagen technischer Vorträge, gefolgt von einem Tag mit Architektur- und Design-Sitzungen. Das Programm umfasst Cloud-Infrastruktur, Sicherheit, Arm, eingebettete Systeme, Automobiltechnik, Werkzeuge und reale Bereitstellungen.

Xen 4.22 erschien ebenfalls kurz vor dem Summit. Die aktuelle Version wird bis Juli 2029 unterstützt, wobei sich der Sicherheitssupport bis Juli 2031 erstreckt. Dieser Lebenszyklus sagt etwas über moderne Virtualisierung aus: Der Wert liegt zunehmend nicht darin, „wie viele VMs kann dieses Gerät ausführen?“, sondern darin: Wie zuverlässig kann die Infrastruktur Arbeitslasten im Laufe der Zeit isolieren, steuern und warten?

Genau deshalb haben Container Hypervisoren nie überflüssig gemacht.

Docker hat die virtuelle Maschine nicht überflüssig gemacht

Container lösen ein äußerst nützliches Problem: Anwendungen und Abhängigkeiten zu bündeln, ohne für jeden Dienst ein komplettes Gastbetriebssystem zu verpacken.

Die Container-Dokumentation von Docker hebt den architektonischen Unterschied hervor: Container können sich den Hostkernel teilen, während eine virtuelle Maschine ein Gastbetriebssystem mit eigenem Kernel ausführt.

Container
────────────
Anwendung
Abhängigkeiten
────────────
Gemeinsam genutzter Hostkernel


Virtuelle Maschine
────────────
Anwendung
Gast-Userspace
Gastkernel
────────────
Virtualisierte Hardware

Container optimieren die Bereitstellung von Anwendungen.

VMs schaffen eine weitere Betriebssystemgrenze.

Und in echter Infrastruktur werden sie häufig kombiniert:

Hardware
   ↓
Hypervisor
   ↓
Virtuelle Maschine
   ↓
Container-Laufzeit
   ↓
Container

Daher ist „VM oder Docker“ oft die falsche Debatte.

Die eigentliche Frage ist, welche Grenze die Arbeitslast tatsächlich benötigt.

Die vier Grenzen eines selbst gehosteten Servers

Der Fehler besteht darin, zu erwarten, dass eine Schicht das Problem einer anderen Schicht löst.

Ein Container schützt dich nicht vor dem Ausfall des physischen Hosts. Sechs VMs auf derselben SSD erzeugen nicht sechs unabhängige Speichersysteme. Ein zweiter Server behebt keine schwache Anwendungsauthentifizierung.

Und wenn jede gewöhnliche Web-App ihre eigene VM erhält, kann das wieder den Bereitstellungsaufwand erzeugen, den Container eigentlich beseitigen sollten.

Verwende die einfachste Abgrenzung, die die Anforderung tatsächlich erfüllt.

Benötigst du wirklich eine VM? Der Test mit fünf Fragen

1. Benötigt sie ein anderes Betriebssystem oder einen anderen Kernel?

Windows, eine vollständige zweite Linux-Distribution, eine Firewall-Appliance oder Betriebssystemtests sind naheliegende VM-Kandidaten.

Anderes Betriebssystem / anderer Kernel erforderlich?
            ↓
           VM

2. Benötigt sie eine separate Vertrauensgrenze?

Sicherheitsexperimente, weniger vertrauenswürdige Software, Build-Worker und kurzlebige Testumgebungen können es rechtfertigen, das Gastbetriebssystem vom primären Host zu trennen.

Eine VM ist nicht automatisch „sicher“, bietet dir aber eine andere Isolationsgrenze als ein weiterer Prozess, der denselben Host-Kernel nutzt.

3. Benötigt sie Kontrolle auf Betriebssystem- oder Netzwerkebene?

Firewalls, Routing-Labore und Appliance-Betriebssysteme profitieren oft davon, eine eigene Betriebsumgebung zu haben, anstatt den Container-Host wiederholt an sie anzupassen.

4. Benötigt sie direkten Hardwarebesitz?

Hier wird Virtualisierung besonders interessant.

Eine Workload benötigt möglicherweise ein:

• GPU,
• Netzwerkadapter,
• HBA,
• USB-Controller,
• ein weiteres PCIe-Gerät.

Die aktuelle Infrastrukturdokumentation von Xen umfasst PCI-Passthrough und SR-IOV genau deshalb, weil sich die Architekturfrage manchmal zu Folgendem wandelt:

Welcher Gast besitzt dieses physische Gerät?

5. Ist es einfach eine weitere Anwendung?

Wenn es sich bei der Workload um ein herkömmliches Dashboard, einen Mediendienst, eine datenbankgestützte Web-App, ein Download-Tool oder einen Automatisierungsdienst handelt – und sie keinen anderen Kernel oder eine besondere Vertrauensgrenze erfordert –, ist ein Container normalerweise der einfachere Ausgangspunkt.

VM vs. Container vs. Bare Metal für Heimserver

Der wichtige Unterschied besteht darin, dass Ressourcennutzung und Isolation getrennte Fragen sind.

Eine winzige Linux-VM benötigt möglicherweise sehr wenig. Ein KI-Container kann eine ganze GPU und mehrere Dutzend Gigabyte Speicher belegen.

Das Ein-Server-Problem: Konsolidierung hat drei Grenzen

Bei der Dimensionierung von Heimservern werden meist CPU und RAM betrachtet. In der Praxis kann ein konsolidierter Server aus drei verschiedenen Gründen „voll“ sein.

Rechenleistungsgrenze

Die bekannte Grenze: Es gibt nicht genügend CPU, RAM, Speicherleistung, GPU-Kapazität oder VRAM für einen weiteren Workload.

Isolationsgrenze

Der Host verfügt weiterhin über verfügbare Ressourcen, aber du möchtest keinen weiteren Workload mehr mit demselben Kernel, denselben Berechtigungen, derselben Hardware oder derselben administrativen Grenze teilen.

Ausfallgrenze

Die Workloads passen technisch darauf, aber jetzt fallen zu viele wichtige Dienste gemeinsam aus.

Ein physischer Host
├── DNS
├── Speicher
├── Home Assistant
├── Medien
├── Windows-VM
└── Experimente

Ein Neustart wirkt sich jetzt auf das gesamte Haus aus.

Damit erhält die Konsolidierung von Heimservern ein besseres Modell:

Serverkapazität
ist nicht nur begrenzt durch:

CPU + RAM

Sie kann außerdem begrenzt sein durch:

Isolationstoleranz

oder

Ausfalltoleranz

Ein Server kann seine Isolations- oder Ausfallgrenze erreichen, lange bevor seine CPU zu 100 % ausgelastet ist.

Virtuelle Isolation ist keine physische Redundanz

Wenn du sechs VMs erstellst, erhältst du sechs nützliche softwareseitige Grenzen. Du erhältst dadurch nicht sechs unabhängige physische Maschinen.

Der Host fällt aus
   ↓
Der Hypervisor wird beendet
   ↓
Jede VM auf diesem Host wird beendet

Dasselbe gilt für Speicher. Fünf VM-Festplatten auf einer ausgefallenen SSD sind weiterhin fünf nicht verfügbare VM-Festplatten.

Dieser Aspekt wird besonders wichtig, wenn sich ein Homelab unbemerkt in eine Produktionsumgebung zu Hause verwandelt.

Drei echte Erkenntnisse zur Virtualisierung aus Zima-Heimlaboren

Das Grenzmodell wird leichter verständlich, wenn es auf echte Hardware statt auf Diagramme angewendet wird.

1. Ein schlanker VM-Host hat weiterhin eine Speicherobergrenze

ZimaOS bietet seit Version 1.3 native ZVM-Unterstützung einschließlich der Installation von Windows- und Linux-VMs mit einem Klick. Die aktuellen Hardwareanforderungen für virtuelle Maschinen verdeutlichen außerdem einen wichtigen Punkt, den allgemeine Rechner zur Frage „Wie viele VMs?“ oft verbergen: Gasttyp, aktive Arbeitslast, Snapshots und Speicherzuweisung sind wichtiger als eine feste Anzahl von VMs.

Ein aktueller Praxistest kam zum selben Ergebnis. Mart führte eine Windows-7-VM unter Proxmox auf einem kompakten Server mit 8 GB aus und zeigte, dass ein einzelner moderater Gast realistisch ist, der Gastarbeitsspeicher jedoch schnell die für den Host und andere Dienste verfügbare Kapazität verringert. Der Proxmox- und Windows-VM-Test erinnert daran, dass Virtualisierung keinen zusätzlichen Arbeitsspeicher schafft.

Die erste Virtualisierungsgrenze bei einem kleinen Server ist häufig der Arbeitsspeicher, nicht die CPU.

2. Bei Passthrough geht es tatsächlich um Besitz

Jonatan Castros Proxmox-Aufbau von 2026 verdeutlicht die Frage nach der Hardware-Grenze.

In seinem Setup läuft ZimaOS als VM, während ein physischer SATA-AHCI-Controller von Proxmox durchgereicht wird. ZimaOS erkennt anschließend die angeschlossenen Laufwerke und erstellt RAID auf Gastebene.

Physische SATA-Laufwerke
       ↓
SATA-Controller
       ↓
PCI-Passthrough
       ↓
ZimaOS-VM
       ↓
Speicherverwaltung

Der Wert besteht nicht einfach darin, dass „ein NAS in einer VM ausgeführt werden kann“.

Das wichtige Architekturdetail ist, dass der Speicherbesitz eindeutig festgelegt ist: Statt dem Gast nur abstrakte virtuelle Datenträger bereitzustellen, erhält der Gast den relevanten physischen Controller.

Der vollständige Aufbau mit Proxmox-Virtualisierung und SATA-Passthrough zeigt außerdem, warum PCIe-Topologie und IOMMU-Unterstützung wichtig sind, sobald die Virtualisierung reale Geräte einbindet.

3. Ein Gerät kann vieles ausführen – für HA benötigen Sie jedoch ein weiteres Gerät

Derselbe Aufbau vermittelt außerdem eine noch bessere Lektion über die Ausfallgrenze.

Ein kompakter Knoten übernimmt einen großen Teil der Service-Arbeitslast, während ein separater NAS-Knoten und ein Quorum-Gerät am übergeordneten Proxmox-Design beteiligt sind. Für HA markierte Dienste können verschoben werden, wenn ein Knoten neu gestartet wird.

Diese Architektur macht einen Unterschied sichtbar, den Benchmarks für Einzelserver nicht zeigen können:

Viele VMs auf einem Host
≠
Hochverfügbarkeit

Mehrere ausfalltolerante Knoten
+
Konzept für gemeinsam genutzte und verschiebbare Arbeitslasten
=
ein Weg zur Hochverfügbarkeit

Für einen gewöhnlichen Heimserver benötigen Sie keine Hochverfügbarkeit. Wenn die Anforderung jedoch lautet: „Diese Arbeitslast muss den Ausfall eines physischen Knotens überstehen“, reicht es nicht aus, eine weitere VM auf demselben Knoten zu erstellen.

Welche Hardwarefunktionen sind für die Virtualisierung tatsächlich wichtig?

„Unterstützt Virtualisierung“ ist zu vage, sobald das Lab über einfache VMs hinausgeht.

Für gewöhnliche Gastsysteme sind CPU-Virtualisierungsunterstützung, ausreichend RAM und schneller VM-Speicher die Grundlagen.

Für Passthrough- und Netzwerkexperimente solltest du außerdem auf Folgendes achten:

• IOMMU-Unterstützung wie Intel VT-d oder AMD-Vi,
• verfügbare PCIe-Erweiterungen,
• mehrere physische Netzwerkschnittstellen,
• Firmware-Unterstützung,
• Geräte-/IOMMU-Gruppierung,
• ausreichend Speicher für Host und Gastsysteme.

Die aktuelle PCI-Passthrough-Dokumentation von XCP-ng unterscheidet ausdrücklich zwischen der normalen CPU-Virtualisierung und der IOMMU-Funktion, die für die Zuweisung physischer Geräte erforderlich ist.

Für ein kompaktes Homelab kann ein kompakter x86-Heimserver mit VT-x, VT-d, PCIe-Erweiterung und mehreren Ethernet-Schnittstellen daher interessanter sein, als einfach die CPU mit der höchsten Kernanzahl zu kaufen.

Die Hardware sollte der Grenze folgen, die du festlegen möchtest.

Xen ist ein Hypervisor; XCP-ng ist eine Plattform

Der Xen Summit macht außerdem eine weitere häufige Verwechslung bei der Virtualisierung sichtbar: Projekte auf unterschiedlichen Ebenen werden oft verglichen, als wären sie gleichwertige Produkte.

Xen bildet die Grundlage des Hypervisors.

XAPI stellt Management-Tools für Xen bereit.

XCP-ng bündelt diese Komponenten zu einer vollständigen Virtualisierungsplattform.

Virtualisierungsplattform
───────────────────────
XCP-ng + Management

Management-/Toolstack
───────────────────────
XAPI

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

Hardware
───────────────────────
CPU / RAM / NIC / GPU / Speicher

Dasselbe Prinzip gilt auch an anderer Stelle: Eine Virtualisierungsplattform ist mehr als der darunterliegende Hypervisor.

Für einen Self-Hoster geht es bei der praktischen Entscheidung daher nicht nur um die Hypervisor-Technologie. Es geht auch um den VM-Lebenszyklus, Netzwerke, Speicher, Backups und darum, wie viel dieser Plattform man tatsächlich selbst betreiben möchte.

Warum der Besitz von Hardware für KI wieder relevant wird

Container machten die Paketierung von Anwendungen portabler. Lokale KI erinnert Infrastrukturentwickler daran, dass Hardware weniger portabel ist.

Eine GPU wirft Fragen auf, die ein gewöhnlicher Webcontainer möglicherweise nie berücksichtigen muss:

Wem gehört die GPU?

Benötigt eine einzelne VM das gesamte Gerät?

Wo befinden sich die Treiber?

Kann das Gerät sauber zurückgesetzt werden?

Können mehrere Workloads sie gemeinsam nutzen?

Stellt der Host nutzbare IOMMU-Gruppen bereit?

Das ist ein Grund, warum Passthrough in einer Docker-zentrierten Welt weiterhin relevant ist.

Container vereinfachten den Besitz von Software. Beschleuniger rückten den Besitz von Hardware wieder in den Mittelpunkt der Architekturfrage.

Die richtige Grenze ist wichtiger als die Anzahl der VMs

Der Xen Summit 2026 ist für Self-Hoster nützlich, selbst wenn sie Xen nie installieren.

Die übergeordnete Erkenntnis ist, dass Bare Metal, VMs und Container keine Reifestufen sind, bei denen eines letztendlich die anderen ersetzt.

Bare Metal
→ direkter Hardwarebesitz

Virtuelle Maschine
→ Betriebssystem-/Kernel-Grenze

Container
→ Anwendungsgrenze

Anwendungsberechtigungen
→ Benutzer-/Datengrenze

Verwenden Sie Container, wenn eine Anwendungsgrenze ausreicht.

Verwenden Sie eine VM, wenn das Betriebssystem, das Vertrauensmodell oder der Besitz physischer Geräte eine eigene Grenze verdient.

Verwenden Sie Bare Metal, wenn eine weitere Abstraktionsebene mehr Komplexität bei der Wiederherstellung als nützliche Flexibilität mit sich bringt.

Und wenn eine Maschine beginnt, alles zu tragen, fragen Sie nicht nur, ob noch CPU-Reserven vorhanden sind.

Fragen Sie, welche Grenze Sie erreicht haben:

Rechenleistungsgrenze?

Isolationsgrenze?

Ausfallgrenze?

Das Ziel der Virtualisierung ist nicht, die Anzahl der VMs zu maximieren. Es geht darum, die richtige Grenze um die richtige Arbeitslast zu ziehen.

FAQ

Wann findet der Xen Summit 2026 statt?

Der Xen Summit 2026 findet vom 15. bis 17. September in München, Deutschland, statt. Der 15. und 16. September konzentrieren sich auf technische Vorträge, während der 17. September Design-Sitzungen und Projektplanung gewidmet ist.

Ist Xen dasselbe wie XCP-ng?

Nein. Xen ist der zugrunde liegende Hypervisor. XCP-ng ist eine vollständige Virtualisierungsplattform auf Basis von Xen und dem XAPI-Toolstack mit Funktionen für Verwaltung, Speicher, Netzwerk und den Lebenszyklus von VMs.

Sollte ich für Self-Hosting eine VM oder Docker verwenden?

Verwenden Sie einen Container, wenn eine Anwendung den Kernel des Hosts sicher gemeinsam nutzen kann und hauptsächlich eine reproduzierbare Paketierung benötigt. Ziehen Sie eine VM in Betracht, wenn die Arbeitslast ein anderes Betriebssystem, einen anderen Kernel, eine Vertrauensgrenze oder die Zuweisung dedizierter Hardware benötigt.

Wann sollte ich statt einer VM Bare Metal verwenden?

Bare Metal kann einfacher sein, wenn eine Arbeitslast die Maschine dominiert, der direkte Hardwarebesitz wichtig ist oder Passthrough die Wiederherstellung komplizierter machen würde, ohne einen nützlichen Isolationsvorteil zu bieten.

Kann ich ein NAS in einer VM betreiben?

Ja, aber legen Sie den Besitz des Speichers eindeutig fest. Das Durchreichen eines Speichercontrollers kann dem NAS-Gast einen direkteren Besitz der physischen Laufwerke geben, während Bare Metal einfacher bleiben kann, wenn Speicher die Hauptaufgabe der Maschine ist.

Schützt Virtualisierung vor dem Ausfall eines physischen Servers?

Nein. VMs isolieren Softwareumgebungen, können sich aber weiterhin ein Motherboard, ein Netzteil und ein Speichersystem teilen. Mehrere VMs auf einem Host schaffen keine physische Redundanz.

Was erfordert GPU-Passthrough?

GPU- und anderes PCI-Passthrough erfordern in der Regel zusätzlich zur gewöhnlichen CPU-Virtualisierung IOMMU-Unterstützung wie Intel VT-d oder AMD-Vi sowie kompatible Firmware, Gerätetopologie und Hypervisor-Konfiguration.