У меня есть кластер Hyper-V 2012 R2, 4 сервера Dell PowerEdge R620, подключенные к массиву хранения Dell PowerVault MD3600F с помощью соединений FC; все довольно просто, все серверы работают под управлением WS2012R2, кластер был недавно построен пару месяцев назад, все драйверы и прошивки обновлены, Windows обновлена до последних доступных патчей (даже выпущенных два дня назад). Существует также сервер SCVMM 2012 R2, управляющий всем этим, но это, похоже, не имеет большого значения для рассматриваемой проблемы.
В этом кластере работает несколько виртуальных машин; некоторые из них представляют собой виртуальные машины поколения 1 под управлением Windows Server 2008 R2, в то время как большинство из них представляют собой виртуальные машины поколения 2 под управлением Windows Server 2012 R2; они тоже включают последние доступные обновления; они фактически были развернуты из шаблона, который был создан вскоре после кластера и периодически обновляется, когда Microsoft выпускает новые исправления.
Все работает очень хорошо, но иногда (то есть без видимой причины или причины) виртуальная машина не загружается, что приводит к сбоям в работе. INACCESSIBLE_BOOT_DEVICE код ошибки; это происходит только при загрузке (или перезагрузке): ни одна виртуальная машина никогда не аварийно завершала работу во время работы.
Когда бы это ни случилось, невозможно снова запустить неисправную виртуальную машину; это произошло впервые две недели назад с виртуальной машиной, на которой еще не выполнялась рабочая нагрузка (она была недавно развернута); мы очень торопились заставить его работать, поэтому просто поцарапали его и установили новый; но первопричина проблемы не была найдена.
Затем это случилось снова два дня назад, когда мы перезагрузили несколько виртуальных машин после их исправления; три из них не вернулись, а некоторые другие загрузились без проблем.
Неисправные виртуальные машины не могут загрузиться даже в безопасном режиме; однако при загрузке в среду восстановления Windows (из самой системы, то есть с локального (виртуального) диска, а не с DVD-диска Windows; это означает, что к виртуальному диску действительно можно получить доступ), все вроде бы в порядке: диспетчер загрузки правильно отображает загружаемая система (вывод bcdedit /enum all /v фактически идентична рабочей ВМ), доступны все тома и даже chkdsk не показывает ошибок вообще. Единственная аномалия - при беге bootrec /scanos или bootrec /rebuildbcd, инструмент сообщает, что не может найти какую-либо установку Windows (хотя том C: есть, и он отлично читается).
Это произошло (по крайней мере, пока) с виртуальными машинами WS2012R2 поколения 2, поэтому я предполагаю, что это вызвано какой-то проблемой в эмуляции EFI и / или загрузчике EFI; однако это только мое предположение.
Я упомянул обновления потому, что знаю это случилось раньше, и KB2919355 был ответственен за это; Кроме того, Microsoft недавно выпустила еще одно мега-обновление, KB3000850, и это также применялось как к хостам, виртуальным машинам, так и к шаблону WS2012R2.
(По совпадению, на следующий день после выпуска этого обновления Microsoft испытала всемирный сбой всей облачной платформы Azure, который имеет поразительное сходство с тем, что происходит с нашим кластером; но я просто разбрасываюсь догадками).
Я уже обратился в службу поддержки Microsoft, но я также пишу здесь, может быть, кто-то может помочь; конечно, если Microsoft предоставит решение, я опубликую его, как только виртуальные машины вернутся в сеть.
Мы передали проблему в службу поддержки Microsoft Premier, и над ней работал специалист по отладке ядра; он обнаружил, что что-то удалило все драйверы Hyper-V с гостевых виртуальных машин, в результате чего они полностью не смогли загрузиться; ему удалось заставить один из них загрузиться, вручную внедрив драйверы в файловую систему и реестр виртуальной машины, и мы смогли вернуть некоторые важные данные (это был центр сертификации); однако виртуальная машина теперь находилась в полностью неподдерживаемом состоянии, и поэтому мы решили перестроить ее; мы также перестроили все другие виртуальные машины, на которых не было критических данных.
Что касается какие фактически вызвал удаление драйвера, кейс все еще открыт, а причина пока не найдена; проблема была скрыта в шаблоне, который мы использовали, потому что рано или поздно она затронула все виртуальные машины, которые были развернуты с использованием этого шаблона; мы создали еще один шаблон, и в нем не было той же проблемы, поэтому сейчас все работает нормально ... но мы до сих пор не знаем, что изначально вызвало проблему.
Через некоторое время мы НУ НАКОНЕЦ ТО обнаружил, что произошло (я просто забыл обновить этот ответ раньше).
Похоже, кто-то или что-то принудительно обновили службы интеграции Hyper-V в базовом шаблоне, который они уже были, основанный на том же самом О. освобождение хозяев; это вызвало скрытую проблему в гостевой системе, когда эти драйверы были помечены как дублирующиеся и / или замененные и, следовательно, нуждались в удалении; но это событие сработает только через переменный интервал времени, когда Windows выполняет некоторый периодический процесс автоматической очистки. В конечном итоге это привело к полному удалению всех драйверов Hyper-V на каждой виртуальной машине, созданной из этого шаблона, что полностью лишило ее возможности загружаться.
Что касается того, кто или что выполнило это обновление (что невозможно сделать, вставив установочный диск служб Integration Services и запустив его установку, поскольку установщик правильно определяет, что драйверы уже установлены, и завершает работу), мы по-прежнему понятия не имею. Либо тот, кто должен был знать лучше, сделал это вручную, используя PowerShell или DISM, или SCVMM был виноват.
Экспортируйте виртуальную машину и подключите ее к отдельному хосту Hyper-V.
загрузите эту виртуальную машину на новом хосте Hyper v, затем загрузитесь и проверьте, все ли работает нормально или нет?
в нашем случае мы добились успеха.
пытаться.