Zufälliges Einfrieren der ESXi-Umgebung auf mehreren Servern

1766
JM3

In den letzten Wochen gab es einige Probleme mit unserer ESXi-basierten VDI-Umgebung, bei der Bilder von Windows 7 Desktop während des Tages zufällig eingefroren wurden.

Dies kann bei jedem VDI Win7-Image auf einem unserer ESXi-Hosts der Fall sein. Soweit uns bekannt ist, wurden in letzter Zeit keine Änderungen am System oder an der Software vorgenommen (hmmm ...).

Wenn ich mir die Konsole eines eingefrorenen Systems anschaue, ist es nicht immer vollständig eingefroren. Manchmal kann ich ein Strg + Alt + Del Signal senden und es wird etwas tun, aber nicht immer. Darüber hinaus ist die CPU-Auslastung für die VM in ESXi tatsächlich ziemlich niedrig (<5% Auslastung). Es scheint also kein Prozess zu sein, der den Prozess mitreißt.

Bei dem Versuch, das Problem zu diagnostizieren, habe ich eine Momentaufnahme von ein paar VMs gemacht, während sie eingefroren waren, und konvertierte ihre vmss-Dateien in dmp-Dateien. Ich habe sie dann in windbg geladen und erhielt folgende Informationen:

0: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * *******************************************************************************  NMI_HARDWARE_FAILURE (80) This is typically due to a hardware malfunction. The hardware supplier should be called. Arguments: Arg1: 00000000004f4454 Arg2: 0000000000000000 Arg3: 0000000000000000 Arg4: 0000000000000000  Debugging Details: ------------------   DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT  BUGCHECK_STR: 0x80  PROCESS_NAME: System  CURRENT_IRQL: 0  LAST_CONTROL_TRANSFER: from fffff80001886113 to fffff80001e0d0ba  STACK_TEXT:  fffff800`0169aad0 fffff800`01886113 : 00000000`00000000 fffff800`01e293c0 00000000`00000000 00000000`00000000 : hal!HalpRtcClockInterrupt+0x2a fffff800`0169ab00 fffff880`033cd9c2 : fffff800`01892709 00000000`00369e99 fffffa80`0249d638 00000000`00000000 : nt!KiInterruptDispatchNoLock+0x163 fffff800`0169ac98 fffff800`01892709 : 00000000`00369e99 fffffa80`0249d638 00000000`00000000 00000000`00000000 : intelppm!C1Halt+0x2 fffff800`0169aca0 fffff800`0188189c : fffff800`01a04e80 fffff800`00000000 00000000`00000000 fffff880`0105e800 : nt!PoIdle+0x52a fffff800`0169ad80 00000000`00000000 : fffff800`0169b000 fffff800`01695000 fffff800`0169ad40 00000000`00000000 : nt!KiIdleLoop+0x2c   STACK_COMMAND: kb  FOLLOWUP_IP:  nt!KiInterruptDispatchNoLock+163 fffff800`01886113 f685f3000000ff test byte ptr [rbp+0F3h],0FFh  SYMBOL_STACK_INDEX: 1  SYMBOL_NAME: nt!KiInterruptDispatchNoLock+163  FOLLOWUP_NAME: MachineOwner  MODULE_NAME: nt  IMAGE_NAME: ntkrnlmp.exe  DEBUG_FLR_IMAGE_TIMESTAMP: 521ea035  FAILURE_BUCKET_ID: X64_0x80_nt!KiInterruptDispatchNoLock+163  BUCKET_ID: X64_0x80_nt!KiInterruptDispatchNoLock+163  Followup: MachineOwner ---------

und das...

1: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * *******************************************************************************  NMI_HARDWARE_FAILURE (80) This is typically due to a hardware malfunction. The hardware supplier should be called. Arguments: Arg1: 00000000004f4454 Arg2: 0000000000000000 Arg3: 0000000000000000 Arg4: 0000000000000000  Debugging Details: ------------------   DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT  BUGCHECK_STR: 0x80  PROCESS_NAME: System  CURRENT_IRQL: 0  LAST_CONTROL_TRANSFER: from fffff80001892709 to fffff880033cd9c2  STACK_TEXT:  fffff880`009fbc98 fffff800`01892709 : 00000000`00369e99 fffffa80`0249b598 fffff880`009f2f40 00000000`00000001 : intelppm!C1Halt+0x2 fffff880`009fbca0 fffff800`0188189c : fffff880`009e8180 fffff880`00000000 00000000`00000000 fffff800`01941430 : nt!PoIdle+0x52a fffff880`009fbd80 00000000`00000000 : fffff880`009fc000 fffff880`009f6000 fffff880`009fbd40 00000000`00000000 : nt!KiIdleLoop+0x2c   STACK_COMMAND: kb  FOLLOWUP_IP:  intelppm!C1Halt+2 fffff880`033cd9c2 c3 ret  SYMBOL_STACK_INDEX: 0  SYMBOL_NAME: intelppm!C1Halt+2  FOLLOWUP_NAME: MachineOwner  MODULE_NAME: intelppm  IMAGE_NAME: intelppm.sys  DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc0fd  FAILURE_BUCKET_ID: X64_0x80_intelppm!C1Halt+2  BUCKET_ID: X64_0x80_intelppm!C1Halt+2  Followup: MachineOwner ---------

Obwohl dies auf ein Hardwareproblem hindeutet (soweit ich das beurteilen kann), ist dies schwer zu glauben, da wir mehrere Farmen mit unterschiedlicher Hardware haben und auf allen von ihnen vorkommen.

Kann ich irgendetwas tun, um dieses Problem weiter zu beheben? Meine Erfahrung mit Windbg ist sehr grundlegend.

0
Vermutlich - alle Intel-CPUs, richtig? Soweit ich wissen kann, gehen die CPUs der Host-Maschinen aus irgendeinem Grund in den Energiesparmodus. Der Intel C1Halt ist Teil des Energiesparmodus der CPUs, der auf VM-Hosts deaktiviert sein sollte Fazer87 vor 10 Jahren 2
Ich bin mir ziemlich sicher, dass dies alles bereits deaktiviert ist. Die meisten unserer Server liefen seit fast einem Jahr ohne Probleme und plötzlich kam es zum Einfrieren. Ich habe die Zeitstempel aller Dateien überprüft, die in den Speicherabbildern erwähnt wurden, und auch keine wurden kürzlich aktualisiert. SO bin ich verloren :( JM3 vor 9 Jahren 0
Hast du das je sortiert? Wir haben genau das gleiche Problem. Mike Barry vor 6 Jahren 0

1 Antwort auf die Frage

0
Don

Ich habe nach einem Problem mit 2008 Servern gesucht, die zufällig einfrieren, eine dmp-Datei aus den vmss-Dateien erhalten und genau die gleiche Ausgabe gesehen. Ich habe mich in die dmp-Datei eingearbeitet und die endgültigen Speicherorte auf eine Art System-Level-API festgelegt, die darauf hinweist, dass ein Interrupt bezüglich der Prozessoren empfangen wurde, aber noch nicht abgeschlossen war.

Ich habe meinen Vorgesetzten zuversichtlich erklärt, dass dies einen Hardwarefehler bedeutete, obwohl mehrere Hosts in zwei Rechenzentren beteiligt waren. Bei einem Hypervisor, der von der Hardware selbst abstrahiert, könnte irgendwo ein Interrupt ausgelöst werden, der nicht von der Hardware selbst stammt.

Dann hatte ich einen schrecklichen Gedanken und schaltete eine funktionierende virtuelle Maschine in die Workstation ein, setzte sie ab, bekam eine dmp-Datei und lief diese in windbg. Weißt du was - genau die gleiche Ausgabe.

Ich glaube, dass der gezeigte NMI ein Ergebnis des Suspend-Prozesses selbst ist. Sie können andere nützliche Dinge aus der Windbg - Speicherzuordnung usw. herausholen - aber bitte verschwenden Sie nicht Ihre Zeit damit, ein kleines Problem zu finden.

Verwandte Probleme