Hyper-V 2012 R2 虚拟机上的 INACCESSIBLE_BOOT_DEVICE

Hyper-V 2012 R2 虚拟机上的 INACCESSIBLE_BOOT_DEVICE

我有一个 Hyper-V 2012 R2 集群,4 台 Dell PowerEdge R620 服务器通过 FC 连接连接到 Dell PowerVault MD3600F 存储阵列;一切都非常简单,所有服务器都运行 WS2012R2,集群是几个月前新构建的,所有驱动程序和固件都是最新的,Windows 已更新到最新的可用补丁(甚至是两天前发布的补丁)。还有一个 SCVMM 2012 R2 服务器管理整个事情,但这似乎对当前的问题并不重要。

该集群上运行着多台虚拟机;其中一些是运行 Windows Server 2008 R2 的第一代虚拟机,而大多数是运行 Windows Server 2012 R2 的第二代虚拟机;这些虚拟机也包含最新的可用更新;它们实际上是从集群之后不久构建的模板部署的,并且在 Microsoft 发布新补丁时定期更新。

一切都运行良好,但有时(即没有明显的原因或原因)虚拟机无法启动,并崩溃并显示可怕的INACCESSIBLE_BOOT_DEVICE错误代码;这只会在启动(或重新启动)时发生:没有任何虚拟机在运行时崩溃过。

每当发生这种情况时,就没有办法让故障的虚拟机再次启动;这种情况第一次发生在两周前,当时的虚拟机还没有运行任何生产工作负载(刚刚部署);我们急于让它工作,因此我们只是把它弄脏并部署了一个新的;但问题的根本原因并没有找到。

两天前,当我们修补几台虚拟机后重新启动它们时,又发生了这种情况;其中三台没有重新启动,而其他一些启动没有任何问题。

即使在安全模式下,故障虚拟机也无法启动;但是,当启动到 Windows 恢复环境(从系统本身,即从本地(虚拟)磁盘,而不是从 Windows DVD;这意味着虚拟磁盘确实可以访问)时,一切似乎都正常:启动管理器正确列出了要启动的系统(的输出bcdedit /enum all /v实际上与正常工作的虚拟机的输出相同),所有卷都可以访问,甚至chkdsk根本没有显示任何错误。唯一的异常是,当运行bootrec /scanos或 时bootrec /rebuildbcd,该工具说它找不到任何 Windows 安装(尽管 C: 卷在那里并且完全可读)。

这仅发生于(至少到目前为止)WS2012R2 第二代虚拟机中,因此我假设它是由 EFI 仿真和/或 EFI 引导加载程序中的某些问题引起的;但是,这只是我的假设。

我之所以提到更新是因为我知道这之前发生过, 和KB2919355对此负责;此外,微软最近发布了另一个大型更新,KB3000850,这也适用于主机、虚拟机和 WS2012R2 模板。

(巧合的是,在此更新发布的第二天,微软的整个 Azure 云平台在全球范围内崩溃了,这与我们的集群发生的情况非常相似;但我只是在这里猜测)。

我已经向微软提交了支持案例,但我也在这里发布,也许有人可以提供帮助;当然,如果微软提供了解决方案,我会在虚拟机恢复在线后立即发布。

答案1

我们将问题上报给微软高级支持,并让一位内核调试专家处理该问题;他发现某些东西从客户虚拟机中卸载了所有 Hyper-V 驱动程序,从而导致它们完全无法启动;他设法通过在虚拟机的文件系统和注册表中手动注入驱动程序来启动其中一个虚拟机,并且我们能够找回一些关键数据(它是一个认证机构);但是,虚拟机现在处于完全不受支持的状态,因此我们决定重建它;我们还重建了所有其他没有关键数据的虚拟机。

至于什么实际上导致了驱动程序卸载,案件仍然悬而未决,原因尚未找到;问题隐藏在我们所使用的模板中,因为它迟早会影响使用该模板部署的所有虚拟机;我们构建了另一个模板,而这个模板没有出现同样的问题,所以我们现在运行良好......但我们仍然不知道是什么导致了这个问题。


更新:

过了一会儿,我们最后发现发生了什么(我只是忘了之前更新这个答案)。

似乎有人或某物强制更新了基础模板中的 Hyper-V 集成服务,这已经有了,基于与主机完全相同的操作系统版本;这在客户系统中引起了一个潜在问题,即这些驱动程序将被标记为重复和/或被取代,因此需要被删除;但此事件只会在可变的时间间隔后触发,即当 Windows 执行一些定期的自动清理过程时。这最终导致从该模板实例化的每个虚拟机上的所有 Hyper-V 驱动程序被完全卸载,导致其完全无法启动。

至于谁或什么执行了此更新(无法通过插入 Integration Services 安装磁盘并运行其安装程序来完成,因为安装程序正确检测到驱动程序已安装并退出),我们仍然不知道。要么是应该更了解的人手动使用电源外壳或者分布式系统管理或者 SCVMM 是罪魁祸首。

答案2

事件发生近 10 年后,我觉得有必要承认:罪魁祸首是

请参阅我的其他答案以了解技术细节,但我必须将其解决,因此我发布了一个新的答案并将其标记为已接受。

是我的错。

在尝试获取最新的 Hyper-V 驱动程序时出现了错误,已经有了,我使用 强行注射了它们DISM

这才是问题的根源。

我当时羞于承认这一点,所以我把责任归咎于任何,但其实这是我的错。

答案3

导出虚拟机并附加到单独的 Hyper-V 主机

在新的 Hyper v 主机中启动此虚拟机,然后启动并检查一切是否正常工作?

我们的案件成功了。

尝试。

相关内容