Назад | Перейти на главную страницу

Windows Server 2012 R2 (виртуальные машины Hyper-V) - случайный BSOD


У меня проблема. Мои виртуальные машины (Hyper-V) - Windows Server 2012 R2 перезагружается довольно часто (BSOD: CRITICAL_STRUCTURE_CORRUPTION (109)). В прошлый раз за выходные было 11х. У меня новый HW, 2x Supermicro server. Я установил Windows Server 2012 R2 и роль Hyper ‑ V на оба сервера (установлены + драйверы с сайта Supermicro). В качестве гостевых систем (виртуальных машин) у меня есть 2x Windows Server 2012 и 1x Windows Server 2012 R2 на каждом хосте Hyper-V. Как я уже писал, проблема в том, что виртуальные машины W2012R2 случайным образом перезагружаются. Но только ВМ W2012R2. Виртуальные машины с W2012 в порядке. Все системы чистые, приложений не установлено и нагрузки нет.

После перезагрузки на виртуальных машинах регистрируются следующие события:

Ядро-Сила 41

EventData:
BugcheckCode 265 
BugcheckParameter1 0xa3a01f59e148b50a 
BugcheckParameter2 0xb3b72be033c8b301 
BugcheckParameter3 0x1a0 
BugcheckParameter4 0x7 
SleepInProgress 0 
PowerButtonTimestamp 0 
BootAppStatus 0 

BugCheck 1001

EventData 
param1 0x00000109 (0xa3a01f59e148b50a, 0xb3b72be033c8b301, 0x00000000000001a0, 0x0000000000000007) 
param2 C:\Windows\MEMORY.DMP 
param3 021516-3093-01

Вывод WinDbg:

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
 or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
 debugger that was not attached when the system was booted. Normal breakpoints,
 "bp", can only be set if the debugger is attached at boot time. Hardware
 breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a01f5a69a8b6bb, Reserved
Arg2: b3b72be0bc28b4a2, Reserved
Arg3: 00000000000001a0, Failure type dependent information
Arg4: 0000000000000007, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification  

Детали отладки:

PG_MISMATCH:  40000
CUSTOMER_CRASH_COUNT:  1
DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT_SERVER
BUGCHECK_STR:  0x109
PROCESS_NAME:  System
CURRENT_IRQL:  2
ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre
STACK_TEXT:  
ffffd001\`1bb7e088 00000000\`00000000 : 00000000\`00000109 a3a01f5a\`69a8b6bb b3b72be0\`bc28b4a2 00000000\`000001a0 : nt!KeBugCheckEx
STACK_COMMAND:  kb
SYMBOL_NAME:  ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME:  Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP:  0
IMAGE_VERSION:  
BUCKET_ID:  BAD_STACK
FAILURE_BUCKET_ID:  BAD_STACK
ANALYSIS_SOURCE:  KM
FAILURE_ID_HASH_STRING:  km:bad_stack
FAILURE_ID_HASH:  {75814664-faf6-4b70-bbc7-dc592132ecdd}
Followup: MachineOwner

Иногда это событие регистрируется на хост-сервере. Но не каждый раз при выходе из строя ВМ:

Hyper-V-Worker 18590

VmErrorCode0 0x109
VmErrorCode1 0xbb8d251d
VmErrorCode2 0xe0d2304
VmErrorCode3 0x1a0
VmErrorCode4 0x7

Не могли бы вы помочь мне решить эту проблему?

Настройка "Предел состояния пакета C - состояние C0 / C1"причины BSOD (а также установка Power Technology - [Отключить]). Поскольку я не могу установить «C0 / C1 State», я выбрал «C2 state», который работает без проблем. Вкратце: чем выше выбранный вами предел состояния пакета C, тем более энергоэффективным будет ЦП (за счет остановки тактовых импульсов, снижения напряжения ...).

Оптимальными настройками производительности в этом случае должны быть:

Расширенная конфигурация управления питанием:

Power Technology - [Custom]
Настройка энергоэффективности - [Отключить]
Настройка Energy Performance BIAS. - [Производительность]
Energy Efficient Turbo - [Отключить]

Контроль состояния CPU P:

EIST (P-состояния) - [Включить]
Турбо-режим - [Включить]
Координация P-состояния - [HW_ALL]

Контроль состояния CPU C:

Предел состояния пакета C - [состояние C2]
Отчет CPU C3 - [Отключить]
Отчет CPU C6 - [Отключить]
Улучшенное состояние остановки (C1E) - [Отключить]


Я обнаружил, что проблема такого типа возникала несколько раз в прошлом и решалась путем обновления ПЗУ или обновления микрокода хоста следующим образом: KB2970215. Но пока не нашел рабочего обновления.

источники:
http://www.supermicro.com/support/faqs/faq.cfm?faq=21555 http://www.supermicro.com/support/faqs/faq.cfm?faq=21499

Решение, которое сработало для меня:

  • Установите следующие пользовательские параметры питания в расширенной конфигурации управления питанием:

Примечание: выделенные строки - важные изменения, но убедитесь, что другие настройки такие же, как на изображениях.

Другие вещи, которые я сделал, которые, возможно, помогли (я сделал это до того, как сделать выше, поэтому я не уверен, актуально это или нет):

Источники:

У нас тоже были такие же ошибки. Ответ от @KeyszerS - действительно хороший намек.

Похоже, что ошибки связаны с управлением питанием плат X10 (по крайней мере, для supermicro). Я провел несколько тестов с любым управлением питанием и без него - иногда BSOD возникали чаще, а иногда они почти проходили.

Уже несколько дней у меня есть решение, которое работает (по крайней мере, для нас) надежно. Мы оценили стабильность с 20 виртуальными машинами на одном пораженном сервере - сбоев больше нет.

Итак, как это получить: Самый простой способ - вернуть настройки BIOS к значениям по умолчанию и просто отключить "энергоэффективный турбо".

Обновить:

Примерно 7 дней никаких проблем - рабочая нагрузка достаточно стабильная. Вот скриншот настроек управления питанием в BIOS - похоже, это связано с "Energy Efficient Turbo".