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

1669
JM3

За последние пару недель у нас возникли некоторые проблемы с нашей средой 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 очень прост.

0
На предположение - все процессоры Intel, верно? Из того небольшого, что я могу собрать, процессоры хост-машин по какой-то причине переходят в режим энергосбережения. Intel C1Halt является частью режима энергосбережения ЦП, который должен быть отключен BIOS на хостах VM Fazer87 9 лет назад 2
Я уверен, что все это уже отключено. Некоторые из наших серверов работали большую часть года без каких-либо проблем, и внезапно это замораживание начало происходить. Я проверил временные метки всех файлов, упомянутых в дампах памяти, и ни один из них не был обновлен в последнее время. ТАК Я потерян :( JM3 9 лет назад 0
Вы когда-нибудь сортировали это? У нас ТОЧНАЯ та же проблема. Mike Barry 6 лет назад 0

1 ответ на вопрос

0
Don

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

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

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

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

Похожие вопросы