Virtualisierung verstehen und abgrenzen

Eine VM ist kein kleiner physischer Server

Eine virtuelle Maschine verhält sich für ihr Betriebssystem weitgehend wie ein eigener Rechner, ist operativ aber eine Kette aus Verträgen. Der Gast sieht virtuelle CPUs, Arbeitsspeicher, Blockgeräte, Netzwerkkarten, Firmware und Zeitquellen. Diese Geräte werden durch einen Hypervisor oder Virtual Machine Monitor bereitgestellt. Der Hypervisor wiederum hängt von Prozessorfunktionen, Host-Speicher, physischen Netzpfaden, Storage und einer Managementschnittstelle ab. Eine Störung kann deshalb auf einer Ebene sichtbar werden, obwohl ihre Ursache auf einer anderen liegt. Für die Diagnose hilft eine feste Schichtung: ``text Anwendung und Gastbetriebssystem ↓ virtuelle Geräte und Gastintegration ↓ VM-Prozess und Hypervisor ↓ Host-Kernel, CPU, RAM, Netzwerk, Storage ↓ Management-, Cluster- und Automatisierungsebene `` Der Pfeil bedeutet Abhängigkeit, nicht Beweis. Ein Paketverlust im Gast beweist keinen Gastfehler; ein voller Datenträger im Gast beweist nicht, dass der Storage-Pool voll ist. Umgekehrt kann ein Managementportal eine VM als „running“ führen, obwohl der Dienst im Gast längst hängt. Beginne daher mit dem beobachtbaren Dienstsymptom, bestimme dann die betroffene Ebene und sammle auf der nächsttieferen Ebene nur die Evidenz, die diese Hypothese bestätigt oder widerlegt. So vermeidest du Sprünge vom Anwendungssymptom direkt zum Host-Neustart.

Hypervisor-Typen ändern den Betriebsvertrag

NIST unterscheidet zwei Grundformen. Ein Bare-Metal- oder Typ-1-Hypervisor läuft direkt auf der Hardware beziehungsweise als dafür vorgesehene Hostschicht. Ein Hosted- oder Typ-2-Modell läuft auf einem allgemeinen Hostbetriebssystem. Produkte verwischen diese Grenze teilweise: KVM nutzt Linux-Kernelmechanismen, während QEMU den VM-Prozess und Geräte bereitstellt; Hyper-V wird als Rolle von Windows Server betrieben. Für die Störungsanalyse ist daher weniger das Etikett als die tatsächliche Abhängigkeit wichtig. Bei einem Hosted-Modell gehören Scheduler, Treiber, Dateisystem und Sicherheitsrichtlinien des Hostbetriebssystems sichtbar zum Pfad. Bei einem dedizierten Virtualisierungshost existieren dieselben Ressourcen, aber oft hinter einer spezialisierten Managementoberfläche. In beiden Fällen teilt sich eine VM reale Kapazität mit anderen Workloads. Virtuelle CPUs werden auf physische Ausführungseinheiten geplant, Gast-RAM wird durch Host-RAM gedeckt, virtuelle Disks enden in Dateien, Volumes oder entfernten LUNs und virtuelle NICs führen über Bridges, Switches oder Overlay-Netze. Formuliere deshalb vor einer Maßnahme den Betriebsvertrag: Wer startet den VM-Prozess? Welche Instanz besitzt die persistente Definition? Welcher Host liefert CPU und RAM? Wo endet das virtuelle Blockgerät? Welche Instanz verbindet den Port mit dem Netz? Wenn diese Fragen nicht beantwortet sind, ist die Fehlerdomäne noch nicht klein genug für einen sicheren Eingriff.

Virtuelle Hardware ist eine Schnittstelle, keine Garantie

Der Gast arbeitet gegen ein virtuelles Hardwaremodell. Eine emulierte Netzwerkkarte kann einen bekannten physischen Chip nachbilden; ein paravirtualisiertes Gerät wie virtio bietet dagegen eine für Virtualisierung entworfene Schnittstelle. Emulation verbessert häufig die Kompatibilität, während paravirtualisierte Geräte weniger Übersetzungsarbeit benötigen. Beides setzt einen passenden Gasttreiber voraus. Der Hypervisor kann ein Gerät korrekt anbieten, das Gastbetriebssystem es aber wegen fehlendem Treiber, geänderter Geräte-ID oder unvollständiger Initialisierung nicht nutzen. Diese Grenze erzeugt zwei unterschiedliche Nachweise. Auf Hypervisorseite prüfst du, welches Gerät tatsächlich an die VM gebunden ist. Im Gast prüfst du, ob das Betriebssystem genau dieses Gerät erkennt und einen Treiber geladen hat. Nur einer der Nachweise reicht nicht. Eine Managementansicht mit „NIC vorhanden“ beweist keine Adresse im Gast; ip link im Gast beweist nicht, dass der Backend-Port mit dem richtigen virtuellen Netz verbunden ist. Dasselbe gilt für CPU-Funktionen. Der Gast sieht ein vom Hypervisor präsentiertes CPU-Modell, nicht automatisch alle Merkmale des Hosts. Diese Abstraktion ermöglicht Portabilität, kann aber Anwendungen überraschen, die bestimmte Instruktionen erwarten. Ändere deshalb CPU-Modell, Firmwaretyp oder Gerätetyp nicht als ersten Diagnoseversuch. Solche Änderungen modifizieren den Vertrag zwischen Gast und Plattform und können einen Neustart, neue Treiber oder eine geänderte Migrationskompatibilität erfordern. Erst Inventar sichern, dann Abweichung benennen, dann geplant ändern.

Zuerst den richtigen Managementkontext beweisen

Viele scheinbar verschwundene VMs sind im falschen Verwaltungsbereich gesucht worden. Libvirt adressiert Treiber und Instanz über eine Verbindungs-URI. qemu:///system bezeichnet typischerweise den systemweiten QEMU/KVM-Dienst; qemu:///session eine benutzerbezogene Sitzung. Unterschiedliche URIs können getrennte Inventare, Berechtigungen, Netzwerke und Storage-Pools besitzen. Auch Cluster-UIs, Cloudprojekte und Mandanten erzeugen solche Sichtgrenzen. Verlasse dich nicht auf den impliziten Standard deines Clients. Mache Ziel und Inventarumfang sichtbar: ``bash uri='qemu:///system' virsh -c "$uri" uri virsh -c "$uri" list --all virsh -c "$uri" dominfo app-01 ` virsh list ohne --all` zeigt standardmäßig nur aktive Domains. Eine gestoppte, aber persistent definierte VM fehlt deshalb in der Ausgabe. Ein leeres Ergebnis bedeutet zunächst nur: In dieser Verbindung wurde keine passende aktive Domain aufgelistet. Es beweist weder Löschung noch den Ausfall des Hosts. Dokumentiere Host oder Endpoint, URI beziehungsweise Projekt, Identität und Filter. Prüfe anschließend das vollständige Inventar. Das ist auch eine Sicherheitsgrenze. Eine systemweite Verbindung kann andere Rechte und Ressourcen erreichen als eine Sitzung. Wechsle nicht blind zu einem privilegierten Kontext, nur damit ein Name erscheint. Stelle erst fest, welches Managementsystem die VM besitzen soll, und verwende dann den dafür vorgesehenen Zugriff. Eine Diagnose ist reproduzierbar, wenn ein zweiter Operator mit demselben Ziel und derselben Identität dasselbe Inventar sieht.

Laufender Zustand und persistente Definition sind zwei Wahrheiten

Eine VM besitzt mindestens einen Laufzeitzustand und häufig eine persistente Definition für den nächsten Start. Beide können auseinanderlaufen. Hotplug kann einem laufenden Gast ein Gerät geben, ohne die Startdefinition dauerhaft zu ändern. Eine Bearbeitung der inaktiven Definition kann umgekehrt erst nach dem nächsten Start wirken. Libvirt-Kommandos kennzeichnen diese Sicht teilweise mit Optionen wie --inactive, --live, --config oder --current. Welche Variante ein einzelner Befehl unterstützt, muss in dessen Dokumentation geprüft werden. Sichere bei Abweichungen beide Ansichten, statt eine durch Neustart zu vernichten: ``bash virsh -c qemu:///system dominfo app-01 virsh -c qemu:///system dumpxml app-01 > /tmp/app-01.live.xml virsh -c qemu:///system dumpxml --inactive app-01 > /tmp/app-01.config.xml diff -u /tmp/app-01.config.xml /tmp/app-01.live.xml ` Nicht jede Domain besitzt beide Ansichten, und sensible XML-Daten gehören nicht ungeprüft in Tickets. Der Ablauf zeigt dennoch das Prinzip: Zustand erfassen, Gültigkeitsbereich notieren, dann vergleichen. Eine Änderung mit virsh edit betrifft die persistente Konfiguration; sie ist kein Beweis, dass die laufende VM sofort angepasst wurde. Diese Trennung verhindert gefährliche Fehlschlüsse. Wenn eine VM nach einem Neustart ein Interface verliert, kann die Live-Konfiguration zuvor korrekt und die persistente Definition unvollständig gewesen sein. Wenn ein Hotplug scheinbar „nicht funktioniert“, wurde vielleicht nur --config` geändert. Benenne bei jedem Befund, ob er für jetzt, für den nächsten Start oder für beide gilt.

Von der VM zum realen Ressourcenpfad

Ein VM-Name ist kein Ressourcenpfad. Für Storage musst du vom Gastgerät über das virtuelle Blockgerät bis zur Quelle und deren Backend verfolgen. Für Netzwerk führt der Weg von der Gast-NIC über MAC-Adresse und virtuelles Interface zu Bridge, virtuellem Switch oder Software Defined Network und weiter zum physischen Uplink. Die erste belastbare Frage lautet nicht „Ist Storage kaputt?“, sondern „Welche konkrete Quelle und welcher konkrete Pfad versorgen diese VM?“. Libvirt liefert dafür einen Ausgangspunkt: ``bash virsh -c qemu:///system domblklist app-01 --details virsh -c qemu:///system domiflist app-01 virsh -c qemu:///system dumpxml app-01 ` domblklist ordnet virtuelle Targets ihren Quellen zu; domiflist` zeigt konfigurierte Netzschnittstellen und ihre Zuordnung. Die XML-Definition enthält zusätzliche Details. Diese Ausgaben beweisen noch nicht, dass das Backend gesund ist. Sie geben dir aber die Identität für den nächsten Test: genau dieser Pool, dieses Volume, diese Bridge, dieses Netz oder dieser Port. Prüfe anschließend den kleinsten gemeinsamen Bereich. Betrifft ein I/O-Fehler nur eine virtuelle Disk, alle Disks derselben VM, alle VMs auf einem Datastore oder alle VMs eines Hosts? Betrifft Paketverlust eine Gast-NIC, ein virtuelles Netz, einen Uplink oder mehrere Hosts? Ein Vergleich mit einem möglichst ähnlichen, aber gesunden Nachbarn ist wertvoll, wenn du die gemeinsame Abhängigkeit explizit benennst. „Andere VMs gehen“ ist ohne Host-, Netz- und Storagebezug keine ausreichende Kontrolle.

Gaststeuerung und Hypervisorsteuerung nicht verwechseln

Ein sauberer Shutdown ist eine Kooperation. Der Hypervisor fordert das Gastbetriebssystem zum Herunterfahren auf; der Gast muss das Signal empfangen und seinen Zustand geordnet schließen. Ein solcher Befehl kann asynchron sein und erfolgreich angenommen werden, obwohl die VM noch läuft. Prüfe deshalb nach dem Request erneut den Zustand und beobachte den vorgesehenen Timeout. Ein erzwungenes Stoppen beendet dagegen den VM-Prozess aus Sicht des Hypervisors. Bei Libvirt ist virsh destroy sinngemäß mit dem Ziehen der Stromversorgung vergleichbar; die persistente Definition wird dadurch nicht automatisch gelöscht. Das ist nützlich, wenn ein Gast nicht mehr kooperiert, trägt aber dieselben Risiken wie ein harter Stromverlust: unvollständige Schreibvorgänge, Dateisystem- oder Anwendungswiederherstellung und verlorene flüchtige Daten. Der Name „destroy“ darf weder als Löschen der VM-Definition noch als harmloser Neustart missverstanden werden. Nutze eine Eskalationsleiter: Dienst im Gast prüfen, Gast-Shutdown mit bestätigtem Zeitfenster anfordern, Zustand beobachten, Anwendungseigentümer einbeziehen und erst dann einen erzwungenen Stopp freigeben. Halte fest, wer den Datenverlust akzeptiert und welche Wiederanlaufprüfung folgt. Wenn der VM-Prozess selbst hängt, können Hostsignale nötig sein; wenn nur die Anwendung hängt, ist ein Hypervisor-Eingriff meist eine unnötig große Fehlerdomäne. Der Ort des wirksamen Befehls muss zur belegten Fehlergrenze passen.

Gemeinsame Fehlerdomänen vor der Maßnahme kartieren

Isolation ist ein Ziel der Virtualisierung, aber keine vollständige Trennung. Mehrere VMs teilen einen Host-Scheduler, Speicherkanäle, physische Uplinks, Storage-Pools, Managementdienste und häufig eine Strom- oder Kühlungsdomäne. Ein Hostausfall betrifft deshalb alle dort laufenden Workloads. Ein gestörter Storage-Pool kann VMs auf mehreren Hosts treffen. Ein defekter Managementdienst kann Änderungen verhindern, während die Datenebene und laufende VMs weiter funktionieren. Erstelle bei einem breiten Symptom eine kleine Abhängigkeitsmatrix: ``text Workload Host Storage-Pool virtuelles Netz Managementziel app-01 hv-a pool-prod net-app cluster-east app-02 hv-a pool-test net-app cluster-east db-01 hv-b pool-prod net-db cluster-east ` Wenn app-01 und app-02 betroffen sind, ist der Host eine stärkere gemeinsame Spur als der Storage-Pool. Wenn app-01 und db-01 I/O-Fehler zeigen, rückt pool-prod nach vorn. Das ist keine Kausalitätsgarantie, aber eine kontrollierte Priorisierung. Bewerte vor jeder Maßnahme den Blast Radius. Ein Neustart von app-01 betrifft einen Gast. Ein Neustart von hv-a` betrifft mindestens zwei Workloads und eventuell Clusterkapazität, Storage-Locks oder Wiederanlaufreihenfolgen. Eine Änderung am Managementziel kann alle administrativen Operationen treffen. Beginne mit einer lesenden Prüfung auf der kleinsten plausiblen Ebene. Je größer die Maßnahme, desto stärker müssen Evidenz, Freigabe, Kapazitätsreserve und Rückweg sein.

Die Managementebene ist ein eigenes Schutzgut

Managementoberflächen, APIs und Automatisierung dürfen nicht mit dem Datenpfad einer VM gleichgesetzt werden. Eine VM kann weiterlaufen, obwohl die Verwaltung nicht erreichbar ist. Umgekehrt kann das Portal „grün“ zeigen, während Anwendung, Gast oder Backend gestört sind. Prüfe deshalb Managementplane und Workloadplane getrennt: Ist nur der API-Endpunkt betroffen? Kann der Host lokal noch Inventar liefern? Ist die Anwendung aus ihrem vorgesehenen Netz erreichbar? NIST empfiehlt für Hypervisor und Virtualisierungsmanagement eine restriktive Zugriffskontrolle, sichere Konfiguration und Trennung der administrativen Schnittstellen. Praktisch bedeutet das: Managementzugriff nur aus vorgesehenen Netzen, individuelle Identitäten, minimale Rechte, nachvollziehbare Änderungen und keine Geheimnisse in Diagnoseartefakten. Ein vollständiger XML-Dump kann beispielsweise Gerätepfade oder andere schützenswerte Metadaten enthalten. Teile nur die für den Befund nötigen Ausschnitte über den vorgesehenen Kanal. Bei Automatisierung gilt dieselbe Scope-Regel wie bei der CLI. Ein Token kann auf ein Projekt, einen Cluster oder alle Hosts wirken. Bevor du einen vermeintlich idempotenten Reparaturlauf startest, prüfe Zielauswahl, Dry-Run-Möglichkeit, Parallelität und Abbruchgrenze. Ein einzelner falscher Filter verwandelt einen lokalen Fehler in eine Plattformstörung. Die Managementebene erleichtert große Änderungen; gerade deshalb ist sie nicht der Ort für unbestätigte Experimente.

Gastintegration und Zeit haben jeweils zwei Seiten

Integrationsdienste oder Guest Agents ergänzen die virtuelle Hardware um einen Kommunikationskanal zwischen Plattform und Gast. Darüber können Managementsysteme beispielsweise Informationen aus dem Gast abfragen oder koordinierte Aktionen anstoßen. Ein installierter Agent beweist aber weder, dass sein Dienst läuft, noch dass der Hypervisorkanal verbunden ist. Prüfe Status im Gast und Sicht auf Plattformseite getrennt. Ein Agent-Upgrade ist eine Änderung im Gast und kann Abhängigkeiten von Treiberpaketen, Dienststart und Plattformversion besitzen; es ist kein neutraler Diagnoseknopf. Zeit illustriert dieselbe Doppelgrenze. Der Gast besitzt eine virtuelle Uhr und kann zusätzlich über NTP oder einen anderen Zeitdienst synchronisieren. Hypervisorintegration und Netzwerkzeitsynchronisation dürfen nicht unkoordiniert gegeneinander regeln. Bei Zeitsprüngen sicherst du zuerst Offset, Quelle, Zeitzone und Ereigniszeit auf Gast und Host. Dann bestimmst du die beabsichtigte Autorität. Erst danach änderst du einen Dienst. Zeit ist außerdem Observability-Infrastruktur. Wenn Host, Gast und Managementsystem unterschiedliche Uhren verwenden, erscheinen Ereignisse in falscher Reihenfolge. Das erschwert die Zuordnung von VM-Neustart, Storagefehler und Anwendungsalarm. Bevor du Logs vergleichst, notiere Quelle und Offset der beteiligten Systeme. Korrigiere nicht sofort mit einem manuellen Sprung: Anwendungen, Datenbanken und verteilte Protokolle können auf rückwärts oder stark vorwärts springende Zeit empfindlich reagieren. Plane die Korrektur entsprechend der zulässigen Drift und der autoritativen Quelle.

Arbeitsbeispiel: „VM weg“ ohne voreiligen Hostneustart