Случайное зависание в среде ESXi на нескольких серверах

Question

За последние пару недель у нас возникли некоторые проблемы с нашей средой VDI на основе ESXi, из-за которых образы рабочего стола Windows 7 случайно зависали в течение дня.

Это может происходить на любом образе VDI Win7 на любом из наших хостов ESXi, и, насколько нам известно, в последнее время не было никаких изменений в системе или программном обеспечении (хммм ...).

Если я смотрю на консоль замороженной системы, она не всегда полностью заморожена. Иногда я могу послать ему сигнал ctrl+alt+del, и он что-то сделает, но не всегда. Кроме того, загрузка ЦП для виртуальной машины в ESXi на самом деле довольно низкая (использование <5%), поэтому, похоже, это не утомительный процесс, тянущий его вниз.

В попытке диагностировать проблему, я сделал снимок нескольких виртуальных машин в замороженном состоянии и преобразовал их vmss в файлы dmp. Затем я загрузил их в windbg и получил следующую информацию:

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

и это...

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

Хотя это наводит на мысль о проблеме с оборудованием (насколько я могу судить), мне трудно в это поверить, поскольку у нас есть несколько разных ферм с различным оборудованием, и это происходит на всех из них.

Есть ли что-нибудь, что я могу сделать, чтобы устранить эту проблему дальше? Мой опыт Windbg очень прост.

Answer 1

Я искал проблему с случайным зависанием серверов 2008, получил файл dmp из файлов vmss и увидел точно такой же вывод. Я углубился в файл dmp и проследил окончательные места в памяти до некоторого API-уровня системного уровня, указывая, что прерывание, касающееся процессоров, было получено, но не завершено.

Я уверенно заявил своим начальникам, что это означало аппаратную ошибку, несмотря на то, что было задействовано несколько хостов в двух центрах обработки данных. В конце концов, если гипервизор вовлечен в абстрагирование от самого оборудования, может произойти прерывание где-то, которое не исходит от самого оборудования.

Затем у меня возникла ужасная мысль, и я запустил работающий виртуальный компьютер на рабочей станции, приостановил его, получил файл dmp и запустил его в windbg. Угадайте, что - точно такой же вывод.

Я считаю, что показанный nmi - результат самого процесса приостановки. Вы можете получить другие полезные вещи из windbg - распределение памяти и т.д. - но, пожалуйста, не тратьте свое время, пытаясь отследить проблему nmi.