Blocco casuale sull'ambiente ESXi su più server

Nelle ultime due settimane abbiamo riscontrato alcuni problemi con il nostro ambiente VDI basato su ESXi in base al quale le immagini del desktop di Windows 7 si bloccano in modo casuale durante il giorno.

Questo può accadere su qualsiasi immagine VDI Win7 su uno qualsiasi dei nostri host ESXi e per quanto ne sappiamo, di recente non sono state apportate modifiche al sistema o al software (hmmm ...).

Se guardo la console di un sistema congelato non è sempre del tutto congelato. A volte posso inviargli un ctrl + alt + del segnale e farà qualcosa, ma non sempre. Inoltre, l'utilizzo della CPU per la VM in ESXi è in realtà piuttosto basso (<5% di utilizzo), quindi non sembra essere un processo di fuga che lo trascina verso il basso.

Nel tentativo di diagnosticare il problema, ho scattato un'istantanea di un paio di VM mentre erano congelate e convertivo le loro vms in file dmp. Li ho quindi caricati in windbg e mi hanno dato le seguenti informazioni:

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
---------

e questo...

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
---------

Sebbene stia suggerendo un problema hardware (per quanto posso dire), trovo difficile crederci poiché abbiamo diverse fattorie con hardware diverso e si sta verificando su tutte.

C'è qualcosa che posso fare per risolvere ulteriormente questo problema? La mia esperienza con windbg è molto semplice.

— JM3
fonte

A indovinare: tutte le CPU Intel, giusto? Da quel poco che riesco a raccogliere, le CPU delle macchine host stanno entrando nel risparmio energetico per qualche motivo. L'Intel C1Halt fa parte della modalità di risparmio energetico della CPU - che dovrebbe essere disabilitata per il BIOS su host VM

— Fazer87

Sono abbastanza sicuro che tutto ciò sia già disabilitato. Alcuni dei nostri server hanno funzionato per la maggior parte dell'anno senza problemi e all'improvviso ha iniziato a verificarsi questo blocco. Ho controllato i timestamp di tutti i file menzionati nei dump della memoria e nessuno di questi è stato aggiornato di recente. Quindi mi sono perso :(

— JM3

L'hai mai ordinato? Stiamo riscontrando lo stesso problema EXACT.

— Mike Barry,

Stavo esaminando un problema con il congelamento casuale dei server del 2008, ho ottenuto un file dmp dai file vmss e ho visto esattamente lo stesso output. Ho analizzato il file dmp e ho rintracciato le posizioni di memoria finali in una sorta di API a livello di sistema indicando che un interrupt relativo ai processori era stato ricevuto ma non era stato completato.

Ho affermato con sicurezza ai miei capi che ciò significava un errore hardware, nonostante fossero coinvolti diversi host in due data center. Dopotutto, con un hypervisor coinvolto nell'astrazione dall'hardware stesso, potrebbe esserci un interrupt che viene attivato da qualche parte che non proviene dall'hardware stesso.

Poi ho avuto un pensiero orribile, ho acceso un vm funzionante in workstation, lo ho sospeso, ho ottenuto un file dmp e l'ho eseguito in windbg. Indovina un po '- esattamente lo stesso risultato.

Credo che l'nmi mostrato sia il risultato del processo di sospensione stesso. Puoi ottenere altre cose utili da windbg - allocazione della memoria ecc. - ma per favore non perdere tempo a cercare di rintracciare un problema di nmi.

— don
fonte