Was ist eine virtuelle Maschine? VM, Hypervisor, Gastbetriebssystem und Snapshots verständlich erklärt

Host, Gast und Hypervisor übernehmen unterschiedliche Aufgaben

Als Host gilt der physische Rechner beziehungsweise die Virtualisierungsplattform, deren Prozessor, RAM, Massenspeicher und Netzwerkanschlüsse genutzt werden. Bei Desktoplösungen wie VirtualBox oder Parallels Desktop läuft zusätzlich ein sichtbares Hostbetriebssystem, etwa Windows, Linux oder macOS. Serverplattformen können anders aufgebaut sein und den Hypervisor enger mit einer spezialisierten Verwaltungsumgebung verbinden. Host und Hostbetriebssystem sind deshalb nicht in jeder Architektur dasselbe.

Der Gast ist die virtuelle Maschine. Das darin installierte Windows, Linux oder andere System heißt Gastbetriebssystem. Es verhält sich weitgehend so, als liefe es auf einem eigenen Computer, obwohl es nur die vom Hypervisor präsentierte Hardware sieht. Ein Fehler im Gast muss den Host nicht unmittelbar betreffen; eine absolute Sicherheitsgrenze entsteht daraus jedoch nicht.

Der Hypervisor bildet die entscheidende Virtualisierungsschicht. Er erstellt und startet VMs, weist ihnen Ressourcen zu, vermittelt Gerätezugriffe und trennt ihre Laufzeitumgebungen voneinander. VirtualBox, VMware-Produkte, Hyper-V, Proxmox VE, Parallels Desktop und KVM sind bekannte Beispiele aus unterschiedlichen Einsatzfeldern. Die Namen bezeichnen keine identische Architektur und auch keine Rangfolge; gemeinsam ist ihnen die Aufgabe, virtuelle Computer auf realer Hardware zu betreiben.

Der Hypervisor erzeugt dabei keine neuen physischen Ressourcen. Konfigurieren Sie vier virtuelle CPUs und acht Gigabyte RAM, bedeutet das nicht zwangsläufig, dass vier Prozessorkerne und acht Gigabyte dauerhaft exklusiv für die VM blockiert sind. Je nach Plattform handelt es sich um eine Obergrenze, eine aktuelle Zuteilung, eine Mindestgarantie, eine Priorisierung oder eine Kombination daraus. Mehrere laufende VMs können sich dieselben Hostressourcen teilen und um CPU-Zeit, Speicherbandbreite und Datenträgerzugriffe konkurrieren.

Virtuelle Hardware übersetzt reale Ressourcen für das Gastbetriebssystem

Die virtuelle CPU, kurz vCPU, ist die Prozessoransicht des Gasts. Der Hypervisor lässt deren Rechenarbeit auf den realen Prozessorkernen ausführen und nutzt dafür in der Regel Hardwarefunktionen moderner CPUs. Eine vCPU ist somit kein vollständig nachgebildeter Prozessor und kein fest zugeordneter physischer Kern. Viele vCPUs beschleunigen eine VM nur, wenn die Anwendung parallel arbeiten kann und der Host genügend Rechenzeit bereitstellt.

Der virtuelle Arbeitsspeicher erscheint dem Gast als gewöhnlicher RAM. Tatsächlich stammt er aus dem Speicher des Hosts oder wird von der Plattform dynamisch bereitgestellt. Ist die Zuteilung zu knapp, lagert das Gastbetriebssystem Daten auf seinen virtuellen Datenträger aus. Ist sie zu großzügig, fehlt dem Host oder anderen VMs Speicher. Beide Fälle können das Gesamtsystem erheblich verlangsamen.

Eine virtuelle Festplatte sieht für das Gastbetriebssystem wie eine SSD oder Festplatte mit Partitionen und Dateisystem aus. Auf dem Host liegt sie häufig als Image-Datei oder als vergleichbares Speicherobjekt vor. Dynamisch wachsende Images belegen anfangs weniger realen Platz und werden größer, wenn der Gast Daten schreibt. Ihre konfigurierte Maximalgröße garantiert jedoch nicht, dass auf dem Host ausreichend Speicher vorhanden ist.

Die virtuelle Netzwerkkarte verbindet den Gast mit einem virtuellen Switch oder einem Netzwerk-Backend des Hypervisors. Erst dessen Betriebsart entscheidet, ob die VM lediglich über den Host ins Internet gelangt, im lokalen Netz als eigener Teilnehmer erscheint oder vollständig isoliert bleibt. Das Gastbetriebssystem benötigt dafür einen passenden Treiber, genau wie bei einer physischen Netzwerkkarte.

Zur VM gehört außerdem eine virtuelle Firmware. Sie übernimmt Aufgaben, die auf einem physischen PC BIOS oder UEFI erledigen: Sie initialisiert virtuelle Geräte, wählt das Startmedium und lädt das Betriebssystem. Von der gewählten VM-Generation und Plattform hängen Funktionen wie UEFI-Start, Secure Boot oder ein virtuelles TPM ab. Diese Merkmale sind insbesondere für neuere Windows-Versionen relevant.

ISO-Datei, Gasttreiber und Passthrough erfüllen verschiedene Funktionen

Eine ISO-Datei ist meist das virtuelle Gegenstück zu einer Installations-DVD. Sie wird in ein virtuelles optisches Laufwerk eingelegt, damit die VM davon starten und das Betriebssystem installieren kann. Die ISO-Datei ist nicht die fertige VM: Nach der Installation liegen Betriebssystem, Programme und Nutzerdaten auf der virtuellen Festplatte.

Virtuelle Hardware wird nicht durchgehend auf dieselbe Weise bereitgestellt. Manche Geräte werden emuliert, damit verbreitete Standardtreiber funktionieren. Synthetische oder paravirtualisierte Geräte nutzen dagegen speziell auf den Hypervisor abgestimmte Treiber und vermeiden einen Teil des Emulationsaufwands. Das kann Netzwerk- und Speicherzugriffe deutlich effizienter machen. Beim Passthrough erhält der Gast einen direkteren Zugriff auf ein reales Gerät, beispielsweise einen USB-Adapter oder unter geeigneten Voraussetzungen eine Grafikkarte.

Guest Tools, Guest Additions oder Integration Services bündeln solche Treiber und zusätzliche Dienste. Sie ermöglichen je nach Plattform eine dynamische Bildschirmauflösung, bessere Maus- und Grafiksteuerung, Zeitabgleich, geordnetes Herunterfahren, gemeinsame Zwischenablagen oder Shared Folders. Gemeinsame Ordner stellen Dateien des Hosts im Gast bereit, schaffen aber zugleich einen bewussten Verbindungspfad zwischen beiden Systemen.

Diese Integrationsfunktionen sind komfortabel, reduzieren jedoch die Trennung. Dasselbe gilt für gemeinsam genutzte Zwischenablagen, Drag-and-drop und USB-Passthrough. Bei gewöhnlichen Arbeits-VMs kann der Nutzen überwiegen. In einer Umgebung für nicht vertrauenswürdige Software sollten Sie nur die unbedingt benötigten Verbindungen aktivieren.

Eine VM teilt sich endliche Ressourcen mit dem Host

RAM, CPU-Zeit und Speicherplatz bleiben begrenzt, auch wenn eine Oberfläche scheinbar beliebig viele virtuelle Geräte hinzufügen lässt. Eine sinnvolle Ausstattung richtet sich deshalb nach Gastbetriebssystem, Anwendungen, parallelen VMs und Hostreserve. Pauschale Idealwerte sind ohne dieses Lastprofil nicht belastbar.

Zu wenig Gast-RAM führt häufig dazu, dass das Betriebssystem in der VM auslagert. Dabei entstehen zusätzliche Zugriffe auf die virtuelle Festplatte, die ihrerseits auf dem Hostspeicher liegt. Weist der Hypervisor einer VM dagegen unverhältnismäßig viel RAM zu, kann das Hostbetriebssystem auslagern oder anderen VMs Speicher entziehen. Prüfen Sie daher sowohl die Speicherauslastung im Gast als auch den Speicherdruck des Hosts.

Auch bei vCPUs gilt nicht „mehr ist automatisch schneller“. Der Hypervisor muss die virtuelle Rechenarbeit auf der physischen CPU einplanen. Viele vCPUs können Wartezeiten erhöhen, wenn mehrere VMs gleichzeitig rechnen oder der Host nur wenige reale Kerne bereitstellt. Entscheidend sind die tatsächliche Anwendungslast, CPU-Wartezeiten und die verbleibende Reaktionsfähigkeit des Hosts.

Beim Speicher müssen Sie zwei Füllstände unterscheiden. Im Gast kann eine virtuelle Festplatte noch 100 Gigabyte freien Platz melden, während ihr dynamisch wachsendes Image das Hostvolume nahezu füllt. Umgekehrt schafft eine große konfigurierte virtuelle Kapazität keinen realen Speicher. Snapshot-Dateien, Protokolle und weitere VMs benötigen ebenfalls Platz außerhalb der Sicht des Gastbetriebssystems.

NAT und Bridged Network bestimmen die Erreichbarkeit der VM

Im NAT-Modus vermittelt eine virtuelle Netzwerkkomponente die Verbindung nach außen. Die VM kann gewöhnlich auf Internet und Netzwerkdienste zugreifen, ist aus dem lokalen Netz aber nicht ohne Weiteres direkt erreichbar. Für eingehende Verbindungen kann eine Portweiterleitung erforderlich sein. NAT vereinfacht viele Testumgebungen, ersetzt jedoch weder eine Firewall noch die Absicherung des Gastbetriebssystems.

Beim Bridged Network wird die virtuelle Netzwerkkarte über einen physischen Hostadapter mit dem externen Netz verbunden. Die VM tritt dort typischerweise mit einer eigenen IP-Adresse als separater Teilnehmer auf. Das ist hilfreich, wenn andere Geräte einen Serverdienst in der VM erreichen sollen oder realistische Netzwerktests erforderlich sind. Gleichzeitig wird der Gast im lokalen Netz sichtbarer und muss wie ein eigener Rechner abgesichert werden.

Die konkreten Bezeichnungen und Details unterscheiden sich zwischen Hypervisoren. Ein falsch gewählter Modus erklärt häufig, warum eine VM zwar ins Internet gelangt, aber von einem anderen Rechner nicht erreichbar ist. Prüfen Sie deshalb zuerst den gewünschten Kommunikationsweg: nur ausgehend, direkt im LAN, ausschließlich zwischen VMs oder vollständig isoliert.

Ein Snapshot ist ein abhängiger Rückkehrpunkt

Ein Snapshot speichert beziehungsweise referenziert den Zustand einer VM zu einem bestimmten Zeitpunkt. Je nach Produkt kann er den Zustand der virtuellen Datenträger, die VM-Konfiguration und gegebenenfalls den Inhalt des Arbeitsspeichers erfassen. Nach seiner Erstellung landen neue Schreibvorgänge häufig in einer Differenz- oder Delta-Datei, während die bisherige Basis unverändert bleibt.

Der Snapshot ist damit kein frei stehendes Vollabbild. Für eine funktionsfähige Wiederherstellung werden die Basisplatte, alle benötigten Differenzdateien, die VM-Konfiguration und der Hostspeicher gebraucht. Weitere Snapshots können eine Kette bilden. Mit jedem Schreibvorgang wachsen deren Dateien; abhängig von Plattform, Kettentiefe, Änderungsrate und Speichersystem kann zusätzlicher I/O-Aufwand entstehen.

Auch die Konsistenz ist nicht immer gleich. Ein Snapshot einer ausgeschalteten VM bildet einen anderen Zustand ab als eine Aufnahme während des laufenden Betriebs. Gespeicherter RAM macht einen Zustand nicht automatisch anwendungs- oder transaktionskonsistent. Datenbanken und produktive Dienste benötigen Sicherungsverfahren, die ihre Anwendungen gezielt einbeziehen.

Praxisfall: Das Update gelingt nicht und die Snapshot-Kette wächst

Vor einem riskanten Update einer Server-VM erstellt der Administrator einen Snapshot. Die VM läuft anschließend weiter, das Update ersetzt zahlreiche Systemdateien und erzeugt neue Daten. Diese Änderungen landen in einer Delta-Datei. Weil ein erster Reparaturversuch unsicher erscheint, wird ein zweiter Snapshot angelegt. Nun hängen der aktuelle Zustand und die Rückkehrpunkte von einer längeren Kette ab.

Während der Tests sinkt der freie Hostspeicher, obwohl die Speicheranzeige im Gast unauffällig bleibt. Die VM reagiert langsamer, weil zusätzlich konkurrierende I/O-Zugriffe stattfinden. Ein Zurückrollen kann die Updateänderungen verwerfen, schützt aber nicht gegen den Defekt des Hostlaufwerks oder den Verlust des gesamten VM-Verzeichnisses. Dafür ist weiterhin ein getrenntes und überprüftes Backup erforderlich.

Sind passende Gasttools und paravirtualisierte Treiber installiert, kann der Hypervisor bestimmte Vorgänge koordinierter ausführen: etwa das Gastbetriebssystem geordnet herunterfahren, Dateisystemaktivitäten abstimmen oder effiziente virtuelle Speicher- und Netzwerkgeräte verwenden. Das verbessert die Voraussetzungen, garantiert aber keine konsistente Sicherung jeder Anwendung. Insbesondere Datenbanken benötigen anwendungsspezifische Verfahren.

Nach einem erfolgreichen Test sollten nicht mehr benötigte Snapshots über die Verwaltungsoberfläche des Hypervisors gelöscht oder konsolidiert werden. Dafür gibt es keine universelle Frist oder produktübergreifend sichere Höchstzahl. Maßgeblich sind Änderungsrate, freier Speicher, Kettentiefe und die Vorgaben der eingesetzten Plattform. Löschen Sie Delta-Dateien niemals manuell im Dateisystem.

Technische Machbarkeit ersetzt keine Betriebsplanung

Viele VM-Probleme beginnen außerhalb des Gastbetriebssystems: Der Host besitzt kein eigenes Backup, sein Datenträger ist fast voll oder mehrere VMs wurden ohne Leistungsreserve gestartet. Hinzu kommen ungeprüfte USB-Geräte, falsche Netzwerkmodi und fehlende Gasttreiber. Beziehen Sie deshalb immer Host, Hypervisor, VM-Konfiguration und Gast in die Diagnose ein.

Auch Lizenzfragen bleiben bestehen. Eine technisch mögliche Installation begründet nicht automatisch ein Nutzungsrecht. Betriebssysteme, Anwendungen, Fernzugriffe und Serverdienste können je nach Edition, Nutzung und Anbieter unterschiedliche Bedingungen haben. Prüfen Sie die aktuellen Lizenzregeln für das konkrete Szenario, bevor Sie ein physisches System vervielfältigen oder in eine VM migrieren.

Eine VM besitzt einen eigenen Kernel, ein Container normalerweise nicht

Eine VM enthält ein vollständiges Gastbetriebssystem mit eigenem Kernel. Sie startet eine komplette Systemumgebung und kann deshalb ein anderes unterstütztes Betriebssystem als der Host ausführen. Das benötigt mehr Arbeitsspeicher, Datenträgerplatz und Startzeit, bietet aber eine weitreichende Trennung der Betriebssystemumgebungen.

Ein Container kapselt im üblichen Modell Anwendungen und ihre Abhängigkeiten als isolierte Prozesse, teilt sich jedoch den Kernel der zugrunde liegenden Plattform. Container sind dadurch meist kleiner und schneller startbereit. Sie sind dennoch keine kleinen VMs und nicht pauschal die bessere oder sicherere Lösung. Benötigen Sie einen eigenen Kernel, ein vollständiges fremdes Betriebssystem oder dessen spezifische Systemdienste, spricht das für eine VM.

Beide Techniken können kombiniert werden. Docker Desktop verwendet auf manchen Hostsystemen intern eine VM, um die benötigte Linux-Umgebung bereitzustellen. Die darin gestarteten Container bleiben trotzdem Container: Sie teilen sich den Kernel dieser Plattform-VM und werden nicht zu eigenständigen virtuellen Computern.

Für diese Aufgaben ist ein vollständiges Gastbetriebssystem hilfreich

• Testsysteme: Prüfen Sie Updates, Konfigurationen oder Software getrennt vom produktiven Rechner. Ein Snapshot erleichtert das kurzfristige Zurückrollen, ersetzt aber kein Backup wichtiger Testdaten.
• Alte Software und Altsysteme: Eine VM kann eine ältere Betriebssystemumgebung erhalten. Klären Sie vorher Prozessorarchitektur, Bootmodus, Treiber, Aktivierung, Hardwaredongles und Lizenzbedingungen.
• Getrennte Arbeitsumgebungen: Kundenprojekte, Verwaltungssoftware oder spezielle Entwicklungswerkzeuge lassen sich voneinander abgrenzen. Gemeinsame Ordner und Zwischenablagen sollten Sie nur bewusst freigeben.
• Serverkonsolidierung: Mehrere Serverrollen können auf leistungsfähiger Hosthardware laufen. Planen Sie Ausfallvorsorge, Ressourcenreserven, Überwachung und unabhängige Sicherungen für die gesamte Plattform ein.
• Schulung und Betriebssystemvergleich: Lernende können Installationen und Verwaltungsaufgaben wiederholen, ohne jedes Mal einen physischen PC neu einzurichten.
• Entwicklungsumgebungen: Reproduzierbare Betriebssystem- und Werkzeugstände erleichtern Tests, wenn ein Container wegen Kernel-, Treiber- oder Systemanforderungen nicht ausreicht.
• Malware-Analyse: Nutzen Sie VMs dafür ausschließlich in kontrollierten Laboren mit qualifizierten Abläufen. Netzwerk, Shared Folders, Zwischenablage, USB und Zugriffe auf produktive Daten sind mögliche Risikopfade; Virtualisierung garantiert keine vollständige Eindämmung.

Bei der Migration eines physischen Altservers in eine VM, häufig als P2V-Migration bezeichnet, genügt das Kopieren der Festplatte nicht immer. Das System muss mit der virtuellen Firmware, den präsentierten Controllern und den Gasttreibern starten können. Anwendungen können außerdem an Netzwerkkarten, feste Adressen, Lizenzserver oder physische Spezialhardware gebunden sein.

Häufige Fragen zu virtuellen Maschinen