none
VM Crash trotz Storage Resiliency RRS feed

  • Frage

  • Hallo,

    wir betreiben einen HyperV Cluster bestehend aus drei Windows Server 2016 Hosts.

    Obwohl dieser über Storage Resiliency einzelne VMs davor bewahren sollte abzustürzen, crashen unsere Maschinen sobald das CSV weg ist.

    Die VM ist eigentlich korrekt konfiguriert:

    AutomaticCriticalErrorAction        : Pause
    AutomaticCriticalErrorActionTimeout : 30

    Das verhalten des HyperVs sieht mir auch erst mal korrekt aus:

    -----------------------------------------

    Protokollname: Microsoft-Windows-FailoverClustering/Operational
    Quelle:        Microsoft-Windows-FailoverClustering
    Datum:         16.02.2019 12:07:01
    Ereignis-ID:   5151
    Das freigegebene Clustervolume (Ressource 'T2-SAS') ist während der Verarbeitung von 'VolumeEventResourcePreOnline' (von Knoten 'HYPVNODE1' mit der Sequenznummer initiiert) in den Status 'CsvFsVolumeStatePaused' gewechselt.
    -----------------------------------------

    Protokollname: Microsoft-Windows-Hyper-V-Worker-Admin
    Quelle:        Microsoft-Windows-Hyper-V-SynthStor
    Datum:         16.02.2019 12:07:31
    Ereignis-ID:   12635
    VM1: Die virtuelle Festplatte 'C:\ClusterStorage\Volume2\T2HypVMachines\VM1\2016DataCenter_Master.vhdx' hat eine Statusbenachrichtigung zur Resilienz empfangen. Aktueller Status: E/A-Zeitüberschreitung. (ID des virtuellen Computers)
    -----------------------------------------

    Protokollname: Microsoft-Windows-Hyper-V-Worker-Admin
    Quelle:        Microsoft-Windows-Hyper-V-SynthStor
    Datum:         16.02.2019 12:07:31
    Ereignis-ID:   12636
    VM1: Die virtuelle Festplatte 'C:\ClusterStorage\Volume2\T2HypVMachines\VM1\2016DataCenter_Master.vhdx' hat einen behebbaren Fehler erkannt. Aktueller Status: E/A-Zeitüberschreitung. (ID des virtuellen Computers)
    -----------------------------------------

    Protokollname: Microsoft-Windows-Hyper-V-Worker-Admin
    Quelle:        Microsoft-Windows-Hyper-V-Worker
    Datum:         16.02.2019 12:07:31
    Ereignis-ID:   18524
    "VM1" wurde aufgrund eines kritischen Fehlers angehalten. (ID des virtuellen Computers)
    -----------------------------------------

    Protokollname: Microsoft-Windows-Hyper-V-Worker-Admin
    Quelle:        Microsoft-Windows-Hyper-V-SynthStor
    Datum:         16.02.2019 12:08:47
    Ereignis-ID:   12635
    VM1: Die virtuelle Festplatte 'C:\ClusterStorage\Volume2\T2HypVMachines\VM1\2016DataCenter_Master.vhdx' hat eine Statusbenachrichtigung zur Resilienz empfangen. Aktueller Status: Keine Fehler. (ID des virtuellen Computers)

    -----------------------------------------

    Protokollname: Microsoft-Windows-Hyper-V-Worker-Admin
    Quelle:        Microsoft-Windows-Hyper-V-SynthStor
    Datum:         16.02.2019 12:08:47
    Ereignis-ID:   12634
    VM1: Die Resilienz virtueller Festplatten wurde für Laufwerk 'C:\ClusterStorage\Volume2\T2HypVMachines\VM1\2016DataCenter_Master.vhdx' erfolgreich wiederhergestellt. Aktueller Status: Keine Fehler. (ID des virtuellen Computers)

    -----------------------------------------


    Bis dann die Meldung kommt:

    -----------------------------------------

    Protokollname: Microsoft-Windows-Hyper-V-Worker-Admin
    Quelle:        Microsoft-Windows-Hyper-V-Worker
    Datum:         16.02.2019 12:08:48
    Ereignis-ID:   18502
    "VM1" wurde ausgeschaltet. (ID des virtuellen Computers)

    -----------------------------------------

    Unsere TestVM quitiert das mit einem:

    -----------------------------------------

    Protokollname: System
    Quelle:        Microsoft-Windows-Kernel-Power
    Datum:         16.02.2019 12:09:18
    Ereignis-ID:   41
    Das System wurde neu gestartet, ohne dass es zuvor ordnungsgemäß heruntergefahren wurde. Dieser Fehler kann auftreten, wenn das System nicht mehr reagiert hat oder abgestürzt ist oder die Stromzufuhr unerwartet unterbrochen wurde.

    -----------------------------------------

    Ich kann nicht nachvollziehen, warum unsere VM das tut.

    Wir sind bei den Tests im Bereich weniger Minuten, also bei weitem nicht über den Zeitraum von 30 Minuten, an dem die Resiliency den Server abschalten würde.

    Hat jemand eine Idee, woran das noch liegen könnte?

    Beste Grüße

    Dennis

    Montag, 18. Februar 2019 11:48