Dieser Beitrag basiert auf einem realen Vorfall in einer produktiven Hyper-V-Failovercluster-Umgebung. Sämtliche Kunden-, Personen-, System-, Netzwerk- und Zeitangaben wurden entfernt, verändert oder durch fiktive Beispielwerte ersetzt.

Wenn eine hochverfügbare virtuelle Maschine plötzlich automatisch neu gestartet wird, fällt der erste Verdacht in einer Storage-Spaces-Direct-Umgebung häufig auf das Storage-Subsystem. Mögliche Ursachen scheinen schnell gefunden: Cluster Shared Volumes, RDMA, SMB Direct, Storage-Latenzen oder ein Fehler innerhalb des S2D-Pools.

Im hier beschriebenen Fall deuteten die ersten Symptome ebenfalls auf einen möglichen Storage-Ausfall hin. Die detaillierte Auswertung zeigte jedoch ein anderes Bild: Nicht der Speicher, sondern eine kurzfristig fehlgeschlagene Statusabfrage innerhalb des Hyper-V-Management-Stacks hatte den automatischen Recovery-Prozess ausgelöst.

Der Vorfall

In einem produktiven Hyper-V-Failovercluster registrierte der Clusterdienst einen Fehler bei der virtuellen Maschine VM-PROD-01. Die VM-Ressource wechselte aus dem Online-Zustand in einen Fehlerzustand und wurde anschließend automatisch neu gestartet.

Die Wiederherstellung war nach wenigen Sekunden abgeschlossen. Die betroffene VM wurde auf demselben Clusterknoten wieder bereitgestellt. Ein Failover auf einen anderen Knoten war nicht erforderlich.

Für die Darstellung des Vorfalls verwenden wir ausschließlich folgende fiktive Bezeichnungen:

  • CLUSTER-01 für den Failovercluster
  • HV-NODE-03 für den betroffenen Clusterknoten
  • VM-PROD-01 für die betroffene virtuelle Maschine
image-19 Ein vermeintlicher S2D-Ausfall: Wie das Clusterlog die vermeidliche Ursache widerlegt (Ursachenanalyse bisher nicht abgeschlossen)

Anonymisierte Incident-Timeline

Die erste Hypothese: ein Problem mit Storage Spaces Direct

In einem Hyper-V-Cluster mit Storage Spaces Direct gehören Probleme im Storage- und Netzwerkpfad zu den naheliegenden Verdächtigen. Deshalb konzentrierte sich die erste Prüfung auf folgende Bereiche:

  • Cluster Shared Volumes
  • Storage Spaces Direct
  • Storage-Pool und physische Datenträger
  • RDMA und SMB Direct
  • Storage- und I/O-Latenzen
  • Clusterknoten und deren Netzwerkverbindungen

Besonders relevant waren die typischen Failover-Clustering-Ereignisse:

5120
5142
5144
1135
1136
1205

Diese Ereignisse können beispielsweise auf nicht erreichbare Cluster Shared Volumes, umgeleiteten CSV-Zugriff, ausgefallene Clusterknoten oder fehlgeschlagene Clusterrollen hinweisen.

Für den untersuchten Vorfall wurden jedoch keine entsprechenden Begleitereignisse festgestellt. Auch für Storage Spaces, StorPort, SMB Direct und RDMA fanden sich im relevanten Analysezeitraum keine Hinweise auf einen Fehler.

Der Überwachungspfad einer hochverfügbaren VM

Ein Failovercluster bewertet den Zustand einer virtuellen Maschine nicht ausschließlich über den Heartbeat des Gastbetriebssystems. Zwischen dem Cluster Resource Manager und dem Gast befinden sich mehrere Komponenten, die an der Ermittlung des VM-Zustands beteiligt sind.

  • Failover Cluster Resource DLL
  • Cluster Resource Manager
  • Virtual Machine Management Service, kurz VMMS
  • WMI- beziehungsweise CIM-Schnittstellen
  • Hyper-V Worker Process, also vmwp.exe
  • Hyper-V-Integrationsdienste im Gastbetriebssystem

Eine Verzögerung innerhalb dieses Überwachungspfads kann dazu führen, dass der Cluster den Zustand einer VM nicht rechtzeitig bestimmen kann. Das bedeutet nicht automatisch, dass die VM abgestürzt ist oder den Zugriff auf ihre virtuellen Datenträger verloren hat.

image-20 Ein vermeintlicher S2D-Ausfall: Wie das Clusterlog die vermeidliche Ursache widerlegt (Ursachenanalyse bisher nicht abgeschlossen)

Hyper-V-Clusterarchitektur und Überwachungspfad

Der entscheidende Hinweis im Clusterlog

Die eigentliche Ursache wurde erst durch die detaillierte Auswertung des Clusterlogs sichtbar. Unmittelbar vor dem automatischen Restart enthielt das Protokoll sinngemäß folgende Statusinformationen:

Virtual Machine "VM-PROD-01":
Heartbeat state 'Present'
VM status 'LostTimeout'

IsAlive: false
heartbeat failure: false
network failure: false

Diese Kombination ist für die Bewertung entscheidend.

Der Hyper-V-Heartbeat des Gastbetriebssystems war weiterhin vorhanden. Gleichzeitig meldete die Clusterressource den VM-Status LostTimeout. Der Cluster konnte den Betriebszustand der VM somit nicht mehr innerhalb des erwarteten Zeitfensters zuverlässig ermitteln.

Der anschließende IsAlive-Test lieferte deshalb den Wert false. Die Clusterressource wurde als fehlerhaft bewertet und der konfigurierte Recovery-Prozess gestartet.

Warum „Heartbeat Present“ und „IsAlive false“ kein Widerspruch sind

Der Heartbeat zeigt, ob das Gastbetriebssystem über die Hyper-V-Integrationsdienste grundsätzlich noch Lebenszeichen sendet. Der IsAlive-Test berücksichtigt dagegen den übergeordneten Zustand der Clusterressource.

Dadurch kann folgende Situation entstehen:

  1. Das Gastbetriebssystem sendet weiterhin einen Heartbeat.
  2. Die Hyper-V-Verwaltung kann den vollständigen VM-Status nicht rechtzeitig ermitteln.
  3. Die Clusterressource bewertet den Gesamtzustand als nicht zuverlässig.
  4. Der IsAlive-Test schlägt fehl.
  5. Der Cluster startet die konfigurierte Wiederherstellung.

LostTimeout oder echter Storage-Ausfall?

Ein Hyper-V-Status-Timeout und ein echter Storage-Ausfall können aus Anwendersicht ähnlich erscheinen, weil die betroffene VM in beiden Fällen kurzfristig nicht verfügbar sein kann. In den Protokollen zeigen sich jedoch deutliche Unterschiede.

Typische Indikatoren eines LostTimeout

  • Der Gast-Heartbeat ist weiterhin vorhanden.
  • Der VM-Status lautet LostTimeout.
  • Der IsAlive-Test schlägt fehl.
  • Es liegt kein gemeldeter Heartbeat-Fehler vor.
  • Es liegt kein gemeldeter Netzwerkfehler vor.
  • Es fehlen typische CSV-, Storage- oder S2D-Fehler.

Typische Indikatoren eines Storage-Ausfalls

  • CSV-Ereignisse wie 5120, 5142 oder 5144
  • Datenträger oder Volumes wechseln in einen Offline- oder Fehlerzustand.
  • I/O-Anforderungen laufen in Timeouts.
  • Storage-Treiber melden Fehler oder auffällige Latenzen.
  • RDMA- oder SMB-Direct-Verbindungen werden unterbrochen.
  • Mehrere VMs oder ein gesamtes CSV können betroffen sein.
image-21 Ein vermeintlicher S2D-Ausfall: Wie das Clusterlog die vermeidliche Ursache widerlegt (Ursachenanalyse bisher nicht abgeschlossen)

LostTimeout im Vergleich mit einem echten S2D-/CSV-Ausfall

Der automatische Recovery-Ablauf

Nachdem der Cluster den IsAlive-Fehler erkannt hatte, wechselte die VM-Ressource durch mehrere interne Zustände. Der anonymisierte Ablauf lässt sich vereinfacht wie folgt darstellen:

Online
→ ProcessingFailure
→ WaitingToTerminate
→ Terminating
→ automatischer Ressourcen-Restart
→ OnlinePending
→ Online

Parallel dokumentierten die Hyper-V-Ereignisse das Trennen und anschließende Neuerstellen der virtuellen Netzwerkkarte. Danach wurde die VM erfolgreich gestartet und wieder mit dem virtuellen Switch verbunden.

Diese Netzwerkswitch-Ereignisse waren keine Ursache des Incidents. Sie waren eine Folge des vom Cluster ausgelösten Neustarts der VM-Ressource.

image-22 Ein vermeintlicher S2D-Ausfall: Wie das Clusterlog die vermeidliche Ursache widerlegt (Ursachenanalyse bisher nicht abgeschlossen)

Automatischer Recovery-Workflow des Failoverclusters

Welche Ursachen konnten ausgeschlossen werden?

Durch die Korrelation der Failover-Clustering-, Hyper-V-, System- und Clusterprotokolle ergaben sich für den untersuchten Vorfall keine Hinweise auf folgende Fehlerklassen:

  • Ausfall eines Cluster Shared Volume
  • Wechsel eines CSV in Redirected I/O
  • Fehler im Storage-Spaces-Direct-Pool
  • Ausfall eines physischen Datenträgers
  • StorPort- oder VHD-bezogene I/O-Fehler
  • Unterbrechung von RDMA oder SMB Direct
  • Ausfall eines Clusterknotens
  • Netzwerkfehler der virtuellen Maschine
  • Verlust des Gast-Heartbeats

Die Ergebnisse sprechen deshalb gegen einen ursächlichen Fehler im S2D-, CSV-, Netzwerk- oder Storage-Subsystem.

Welche Ursache ist am wahrscheinlichsten?

Der nachgewiesene Auslöser des automatischen Recovery-Prozesses war der Status LostTimeout in Verbindung mit einem fehlgeschlagenen IsAlive-Test.

Als technische Auslöser eines solchen Status kommen unter anderem infrage:

  • eine kurzzeitige Verzögerung zwischen Failovercluster und VMMS
  • ein verzögert antwortender Hyper-V Worker Process
  • eine nicht rechtzeitig abgeschlossene WMI- oder CIM-Abfrage
  • eine temporäre Belastung innerhalb des Hyper-V-Management-Stacks
  • zeitgleiche Snapshot-, Backup- oder VSS-Aktivitäten

Für keine dieser möglichen Unterursachen lag im betrachteten Analysezeitraum ein zusätzlicher, eindeutiger Fehlernachweis vor. Belastbar nachgewiesen ist deshalb der LostTimeout, nicht jedoch die genaue Komponente, welche die Verzögerung innerhalb des Hyper-V-Management-Pfads verursacht hat.

Lessons Learned

Event ID 1069 ist zunächst nur ein Symptom

Ein Clusterereignis, das eine fehlgeschlagene Ressource meldet, beschreibt zunächst nur das Ergebnis. Für die Ursachenanalyse muss die vorausgehende Zustandsänderung im Clusterlog untersucht werden.

Ein VM-Neustart ist nicht automatisch ein Storage-Problem

Auch in einer S2D-Umgebung können Fehler innerhalb des Hyper-V-Management-Stacks eine automatische Wiederherstellung auslösen. Die Existenz eines S2D-Clusters ist noch kein Beleg dafür, dass der Fehler im Storage-Layer liegt.

Heartbeat und IsAlive müssen getrennt bewertet werden

Ein vorhandener Heartbeat belegt, dass der Gast weiterhin Lebenszeichen sendet. Der übergeordnete Ressourcenstatus kann dennoch fehlschlagen, wenn der Hyper-V-Stack keine vollständige oder rechtzeitige Statusantwort liefert.

Die korrekte zeitliche Korrelation ist entscheidend

Clusterlog, Failover-Clustering-Ereignisse und Hyper-V-Systemereignisse müssen auf denselben Ereigniszeitraum eingegrenzt werden. Bereits eine Abweichung bei der Zeitzone oder beim ausgewählten Zeitfenster kann die Analyse in eine falsche Richtung führen.

Empfehlungen für ähnliche Vorfälle

  1. Den exakten Fehlerzeitraum aus den Failover-Clustering-Ereignissen bestimmen.
  2. Das Clusterlog mit lokaler Zeitdarstellung und einem ausreichend großen Zeitraum erzeugen.
  3. Im Clusterlog nach dem VM-Namen, der Ressourcen-ID und ProcessingFailure suchen.
  4. Die Protokollzeilen unmittelbar vor dem Zustandswechsel auswerten.
  5. Auf Heartbeat state, VM status, IsAlive, heartbeat failure und network failure achten.
  6. Parallel nach CSV-, S2D-, StorPort-, SMB-Direct- und RDMA-Ereignissen suchen.
  7. Hyper-V-Ereignisse darauf prüfen, ob sie Ursache oder lediglich Folge des Cluster-Recovery-Prozesses sind.
  8. Bei wiederholtem Auftreten zeitgleiche Backup-, Snapshot-, VSS- und Security-Aktivitäten korrelieren.

Fazit

Die Symptome ließen zunächst einen Fehler im Storage-Spaces-Direct- oder CSV-Subsystem vermuten. Die detaillierte Protokollanalyse bestätigte diese Hypothese jedoch nicht.

Der auslösende Zustand war ein kurzfristiger Hyper-V-Status-Timeout mit der Bezeichnung LostTimeout. Obwohl der Gast weiterhin einen Heartbeat lieferte und kein Netzwerkfehler gemeldet wurde, konnte der Cluster den vollständigen VM-Status nicht rechtzeitig ermitteln. Der daraufhin fehlgeschlagene IsAlive-Test startete den vorgesehenen automatischen Recovery-Prozess.

Die VM wurde innerhalb weniger Sekunden wieder bereitgestellt. Für einen Fehler im S2D-, CSV-, Netzwerk- oder Storage-Subsystem wurden keine belastbaren Hinweise gefunden.

Kernaussage: Ein LostTimeout ist nicht automatisch ein Storage-Problem. Erst die gemeinsame Auswertung von Clusterlog, Hyper-V-Ereignissen, Heartbeat-Status und IsAlive-Prüfung ermöglicht eine belastbare Abgrenzung.

Über den Autor

Oliver Sommer

Senior System Consultant mit Schwerpunkt auf Microsoft-Infrastrukturen, Windows Server, Hyper-V, Failover Clustering, Storage Spaces Direct, Microsoft Intune, Azure und PowerShell-Automatisierung.

Alle technischen Bezeichnungen der ursprünglichen Kundenumgebung wurden anonymisiert. Die gezeigten Befehle sind Beispiele und müssen vor dem Einsatz in einer produktiven Umgebung geprüft werden.
Dieser Beitrag wurde unter Verwendung von KI-Tools erstellt und redaktionell geprüft.