Virtualisierung und Hypervisor

Ein physischer Server, mehrere Rechner, und jeder glaubt, die ganze Maschine gehöre ihm allein. Virtualisierung ist die höfliche Art, Betriebssysteme im Unklaren zu lassen.

Kurz gesagt

Virtualisierung lässt einen physischen Rechner mehrere virtuelle Maschinen (VMs) mit jeweils eigenem Betriebssystem betreiben. Ein Programm namens Hypervisor teilt Prozessor, Arbeitsspeicher, Datenträger und Netzwerk zu und hält die VMs auseinander. Ein Snapshot einer VM ist eine praktische Rückgängig-Taste für ein paar Tage, aber kein Backup.

So funktioniert’s

1. VMs und Hypervisor: Bei der Vollvirtualisierung laufen ein Betriebssystem und seine Anwendungen auf virtueller Hardware in einer virtuellen Maschine, die NIST Gast nennt. Der Hypervisor, auch Virtual Machine Monitor genannt, steuert den Fluss der Befehle zwischen den Gästen und der echten Hardware (Prozessor, Datenträger, Speicher, Netzwerkkarten). Er kann Ressourcen aufteilen und die Gäste voneinander abschotten, und ein Gast lässt sich vollständig kapseln, wodurch er sich verschieben lässt.
2. Zwei Bauarten: Bei der Bare-Metal-Virtualisierung läuft der Hypervisor direkt auf der Hardware, bei der gehosteten Virtualisierung läuft er auf einem gewöhnlichen Wirtsbetriebssystem.
3. Der Prozessor hilft mit: Bei den Virtualisierungserweiterungen von Intel (VMX) arbeitet der Hypervisor in einem Betriebsmodus (Root) und die Gäste in einem anderen (Non-Root), in dem ihr Verhalten eingeschränkt ist. Bestimmte Befehle und Ereignisse lösen einen VM-Exit aus, der die Kontrolle an den Hypervisor zurückgibt. Diese Beschränkung hält ihn Herr über die Hardware.
4. Geräte und IOMMU: Eine VM kann ein physisches Gerät direkt zugewiesen bekommen (Device Assignment, auch Passthrough genannt), für höchste E/A-Leistung. Eine IOMMU (Input–Output Memory Management Unit, bei Intel VT-d) hält so ein Gerät in dem Speicherbereich, der ihm zusteht, damit es nicht an beliebigen Speicher kommt.
5. Snapshots: Ein Snapshot hält Zustand und Daten einer VM zu einem Zeitpunkt fest. Broadcom nennt Snapshots nützliche kurzfristige Lösungen, nicht geeignet für langfristige Backups: Gehen die Dateien der VM verloren, gehen auch ihre Snapshot-Dateien verloren. Die Leistung kann leiden, und zwar stärker, je länger die Snapshot-Kette ist. Eigene Messungen von VMware empfehlen, Snapshots nur vorübergehend zu verwenden.
6. Ressourcen werden geteilt, also plane sie: Jede VM bekommt einen Anteil an denselben Prozessoren, demselben Speicher, denselben Datenträgern und Netzwerkkarten. Was du einer VM gibst, fehlt einer anderen.

In der Praxis

Zum Zeitpunkt unserer letzten Bestandsaufnahme (14. Okt. 2026) lief auf unserem Host, einem HPE ProLiant DL360 Gen9, VMware ESXi 7.0 Update 3 (Profil ESXi-7.0U3n-21930508-standard) mit sieben VMs, einer Mischung aus Windows-Server-2022- und Ubuntu-Linux-Gästen. Ihre Datenträger lagen auf einem VMFS6-Datastore mit 1,24 TB. Version und Build schreiben wir auf, weil jede spätere Frage nach Updates damit beginnt. Zwei Befehle zum Selbstausprobieren:

esxcli system version get          # auf einem ESXi-Host: Produkt, Version und Build
grep -m1 -o -w vmx /proc/cpuinfo   # unter Intel-Linux: gibt „vmx“ aus, wenn die CPU VMX bietet

Der zweite Befehl zeigt nur, dass der Prozessor die Funktion bietet. Ob sie in der Firmware eingeschaltet ist, ist eine eigene Prüfung. Bei AMD-Prozessoren heißt das Flag anders.

VMs oder Container?

Ein Container teilt sich den Kernel des Hosts und isoliert nur Prozesse, Dateisystem und Netzwerk; eine VM bringt ihren eigenen Kernel mit und sieht virtuelle Hardware. Container starten in Sekunden und kosten fast keinen Speicher-Overhead, deshalb passen sie besser zu einzelnen Diensten (Webserver, Datenbank, Bot). VMs passen besser, wenn du ein anderes Betriebssystem, Kernel-Module, ein durchgereichtes Gerät oder eine harte Grenze zwischen Mandanten brauchst. Die meisten Homelabs landen bei beidem: eine Handvoll VMs, und in einer davon ein Container-Host. Der Container-Artikel erklärt diese Seite im Detail.

Mehr verschenken, als du hast

Hypervisoren lassen dich VMs in Summe mehr virtuelle CPUs und mehr Arbeitsspeicher zuweisen, als der Host physisch hat, das heißt Überbuchung. Bei CPUs geht das meist gut, weil selten alle VMs gleichzeitig rechnen; ein Host mit 16 Threads und 30 vCPUs ist normal. Beim Arbeitsspeicher ist es eine Falle: Nutzen die Gäste tatsächlich, was ihnen versprochen wurde, fängt der Hypervisor an zurückzuholen (Ballooning, Komprimieren, Auslagern auf Platte), und alles wird gleichzeitig langsam. Faustregel für zu Hause: Summe des zugewiesenen Speichers ≤ physischer Speicher minus das, was der Hypervisor selbst braucht, und die Rückholmechanismen bleiben das Sicherheitsnetz, als das sie gedacht sind.

Hypervisor zu Hause wählen: die Lizenzfrage

Unser Host läuft mit ESXi 7.0 Update 3. Broadcom hat den kostenlosen vSphere Hypervisor Anfang 2024 eingestellt und mit ESXi 8.0 Update 3e (April 2025) wieder einen kostenlosen VMware vSphere Hypervisor Version 8 bereitgestellt, ausdrücklich für nicht-produktive Nutzung, ohne Support, ohne vCenter und mit höchstens 8 virtuellen CPUs je VM. Für ein Lern-Homelab ist das brauchbar; für alles, worauf du angewiesen bist, lies die Bedingungen, bevor du aktualisierst. Die üblichen Alternativen, Proxmox VE (KVM) und reines KVM/libvirt auf einer Linux-Distribution, sind quelloffen, haben keine vCPU-Grenze und bekommen ihre Updates über die Distribution. Egal was du wählst: Die Prüflistenpunkte zu CPU-Flags, IOMMU, Ressourcensummen und Backups sind dieselben, denn der Hardware ist egal, welcher Hypervisor fragt.

Prüfliste

• Prüfe in der Firmware, dass die CPU-Virtualisierung eingeschaltet ist, und die IOMMU ebenfalls, wenn du Geräte durchreichen willst.
• Addiere Arbeitsspeicher und virtuelle CPUs aller VMs und vergleiche die Summe mit dem Host, mit Platz für den Hypervisor selbst.
• Plane Speicher- und Netzwerkpfade mit: wo die VM-Datenträger liegen und welche physischen Netzwerkkarten sich die VMs teilen.
• Lege Snapshots nur kurz an und lösche sie, sobald du die Änderung geprüft hast.
• Sichere VMs mit einem echten Backupwerkzeug auf getrennten Speicher und stelle zum Test eine VM wieder her, statt nur einen Backupjob laufen zu lassen.
• Schreib Hypervisor-Version und Build auf und aktualisiere die Notiz nach jedem Upgrade.
• Prüfe vor einem Upgrade die Lizenzbedingungen deiner Hypervisor-Version, vor allem vCPU-Grenzen und Support.