Congelamento aleatório no ambiente ESXi em vários servidores

0

Nas últimas duas semanas, tivemos alguns problemas com o ambiente VDI baseado em ESXi, no qual as imagens do Windows 7 Desktop congelavam aleatoriamente ao longo do dia.

Isso pode acontecer em qualquer imagem VDI Win7 em qualquer um dos nossos hosts ESXi e, até onde sabemos, nenhuma alteração no sistema ou no software foi feita recentemente (hmmm ...).

Se eu olhar para o console de um sistema congelado, nem sempre ele está totalmente congelado. Às vezes eu posso enviar um sinal ctrl + alt + del e ele fará alguma coisa, mas nem sempre. Além disso, o uso da CPU para a VM no ESXi é realmente muito baixo (< 5% de uso), portanto, não parece ser um processo de fuga arrastando-a para baixo.

Em uma tentativa de diagnosticar o problema, tirei um instantâneo de algumas VMs enquanto congelava e convertia seus vmss em arquivos dmp. Eu então os carreguei no windbg e recebi as seguintes informações:

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

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

Embora esteja sugerindo um problema de hardware (até onde eu posso dizer), acho isso difícil de acreditar, já que temos vários farms diferentes com hardware variável e está ocorrendo em todos eles.

Existe algo que eu possa fazer para solucionar isso ainda mais? Minha experiência de windbg é muito básica.

    
por JM3 02.05.2014 / 16:15

1 resposta

0

Eu estava olhando para um problema com servidores de 2008 congelando aleatoriamente, obtive um arquivo dmp dos arquivos vmss e vi exatamente a mesma saída. Fiz o detalhamento no arquivo dmp e tracei os locais finais da memória em algum tipo de API no nível do sistema, indicando que uma interrupção referente aos processadores havia sido recebida, mas não concluída.

Confiantemente afirmei para meus chefes que isso significava um erro de hardware, apesar de vários hosts em dois datacenters estarem envolvidos. Afinal, com um hipervisor envolvido abstraindo do próprio hardware, pode haver uma interrupção sendo acionada em algum lugar que não veio do próprio hardware.

Então eu tive um pensamento horrível, e liguei um vm trabalhando na estação de trabalho, suspendi, peguei um arquivo dmp e rodei isso no windbg. Adivinha o quê - exatamente a mesma saída.

Eu acredito que o nmi mostrado é resultado do próprio processo de suspensão. Você pode obter outras coisas úteis de windbg - alocação de memória, etc - mas por favor não perca seu tempo tentando rastrear um problema nmi.

    
por 17.11.2014 / 16:37