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

Является ли событие 41 нормальным при выключении VPS в гипервизоре?

У меня есть размещенный VPS (Windows Server 2012), и его выключение в гипервизоре вызывает следующее критическое событие в системном представлении журналов Windows:

> Log Name: System Source: Microsoft-Windows-Kernel-Power Date:
> 4/13/2015 12:05:28 PM Event ID: 41 Task Category: (63) Level: Critical
> Keywords: (2) User: SYSTEM Computer: ********** Description: The
> system has rebooted without cleanly shutting down first. This error
> could be caused if the system stopped responding, crashed, or lost
> power unexpectedly. Event Xml: <Event
> xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
> <System> <Provider Name="Microsoft-Windows-Kernel-Power"
> Guid="{331C3B3A-2005-44C2-AC5E-77220C37D6B4}" /> <EventID>41</EventID>
> <Version>3</Version> <Level>1</Level> <Task>63</Task>
> <Opcode>0</Opcode> <Keywords>0x8000000000000002</Keywords>
> <TimeCreated SystemTime="2015-04-13T10:05:28.557824700Z" />
> <EventRecordID>594549</EventRecordID> <Correlation /> <Execution
> ProcessID="4" ThreadID="8" /> <Channel>System</Channel>
> <Computer>**********</Computer> <Security UserID="S-1-5-18" />
> </System> <EventData> <Data Name="BugcheckCode">239</Data> <Data
> Name="BugcheckParameter1">0xfffffa8007110700</Data> <Data
> Name="BugcheckParameter2">0x0</Data> <Data
> Name="BugcheckParameter3">0x0</Data> <Data
> Name="BugcheckParameter4">0x0</Data> <Data
> Name="SleepInProgress">0</Data> <Data
> Name="PowerButtonTimestamp">0</Data> <Data
> Name="BootAppStatus">0</Data> </EventData> </Event>

Информация о мероприятии (41) находится здесь: https://support.microsoft.com/en-us/kb/2028504#method1

И информация о проверке ошибок здесь (239 = 0xEF): https://msdn.microsoft.com/en-us/library/windows/hardware/ff560358(v=vs.85).aspx

Это событие было вызвано подключением моего VPS ко второй сети Ethernet.

Я сообщил об этом принимающей стороне, и они уверяют меня, что:

"это нормальное событие, когда VPS отключается в гипервизоре"

Это очень надежный поставщик, поэтому я склонен им верить, но тоже не совсем уверен. Итак, мой вопрос: является ли это событие тревожным или нормальным в данном сценарии?

--- ОБНОВЛЕНИЕ от хостера (transip.nl)

Сообщение «Система перезагрузилась без предварительного завершения работы. Эта ошибка могла быть вызвана, если система перестала отвечать, аварийно завершила работу или неожиданно отключила питание». логично.

Поскольку у нас нет доступа к самой ОС и, следовательно, мы не можем выполнить перезагрузку оттуда, мы делаем это, отключая VPS в гипервизоре, что действительно приведет к появлению такого отчета.

Настаивая на элобаратинге:

Что ж, я действительно не могу дать вам другого ответа. Когда вы добавляете VPS в частную сеть или удаляете его, или когда вы перезапускаете его через консоль, это никогда не приведет к «чистому завершению работы».

Если бы мы сделали это, то в случае паники ядра или другой критической проблемы в ОС, он не смог бы перезапуститься, потому что не ответил бы на эту команду.

ОБНОВИТЬ После совместного использования опции ACPI:

ACPI действительно был бы возможен, если бы не тот факт, что для этого потребовался бы демон, работающий в ОС, и поэтому у клиентов всегда была возможность отключить его. Кроме того, это не будет иметь никакого эффекта в случае паники ядра / BSOD, потому что демон в ОС также остановлен.

Это не дало бы нам никакой гарантии, что выключение / перезагрузка действительно выполняется, и это сделало бы параметр «сброс» довольно ненадежным.

Очевидно, это не нормально. Почему это могло быть? Это чушь. Вы бы не убили процесс инициализации в Linux, так почему это можно сделать в Windows?

Обновить
Видимо, они не поддерживают выключение через ACPI (что не так уж и круто), а просто «убивают мощность». Вы должны поощрить их реализовать решение кнопки питания ACPI. Это то, что делает VirtualBox, и он отлично работает, вероятно, с любой ОС.

Однако это все еще не объясняет, почему вы получаете BSOD.

А пока вы должны выключить свой VPS через RDP, чтобы избежать повреждения данных.