![使用嵌套虚拟化支持在 Windows Root OS 中运行另一个非 Hyper-V 虚拟机管理程序](https://linux22.com/image/1591396/%E4%BD%BF%E7%94%A8%E5%B5%8C%E5%A5%97%E8%99%9A%E6%8B%9F%E5%8C%96%E6%94%AF%E6%8C%81%E5%9C%A8%20Windows%20Root%20OS%20%E4%B8%AD%E8%BF%90%E8%A1%8C%E5%8F%A6%E4%B8%80%E4%B8%AA%E9%9D%9E%20Hyper-V%20%E8%99%9A%E6%8B%9F%E6%9C%BA%E7%AE%A1%E7%90%86%E7%A8%8B%E5%BA%8F.png)
我正在尝试更好地了解虚拟机管理程序的工作原理。我知道一次只有一个虚拟机管理程序可以使用 CPU 的虚拟化支持。我还知道 Hyper-V 是 1 类虚拟机管理程序,因此当启用它时,它会在 Windows 之前“启动”,然后将 Window 作为具有硬件特权访问权限的特殊 VM 运行。
Hyper-V 支持嵌套虚拟化,通过(以某种方式)向其客户机公开虚拟化扩展,但据我所知,它仅在客户机也使用 Hyper-V 时才有效。我想知道这个限制的原因,为什么另一个虚拟机管理程序(例如 VirtualBox)不能使用公开的虚拟化扩展?
这个问题与我的非常相似,但没有令人满意的答案。
编辑: 我认为这是不可能的(因此我问为什么)的原因如下:
- 微软官方页面上是这样写的:
Hyper-V 虚拟机不支持除 Hyper-V 之外的虚拟化应用程序,并且这些应用程序可能会失败。这包括任何需要硬件虚拟化扩展的软件。
公开虚拟化扩展的命令明确要求您将其指向 Hyper-V VM:Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
编辑2: 抱歉,由于我理解能力不足,无法清楚地表达这个问题。我会尽量说得更清楚。我想做的是:
引用微软页面:
Hyper-V 向其虚拟机公开硬件虚拟化扩展。启用嵌套后,来宾虚拟机可以安装自己的虚拟机管理程序并运行自己的来宾 VM。
再加上Windows 根操作系统本身就是一个特殊的虚拟机,这让我相信我应该能够暴露虚拟化扩展到主Windows 根操作系统并使用它们在其中运行另一个虚拟机管理程序。
在搜索如何执行此操作时,我遇到了这个命令:
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
它需要虚拟机名称。
- 我现在明白的是,Hyper-V 可以让你暴露虚拟化扩展到您选择的虚拟机之一,但您不能选择Windows 根操作系统(为什么?)在所选的虚拟机中,您可以正式将 Virt. Ext. 与另一个 Hyper-V 实例一起使用,但它也可能与其他虚拟机管理程序一起使用。
- 当我第一次问这个问题时,我没有意识到Hyper-V 管理工具您可以在Windows 根操作系统在运行Windows 根操作系统本身。我以为它是在另一个 Hyper-V 实例上运行的,再加上需要 Hyper-V VM 名称的命令,让我相信它只能通过两个 Hyper-V 虚拟机管理程序来完成。
总而言之,我的问题实际上由两部分组成:
- 你能将非 Hyper-V 虚拟机管理程序嵌套在 Hyper-V 驱动的虚拟机内吗?答案是:它没有得到明确支持,但它应该/可能起作用(参见接受的答案)。
为什么你不能揭露虚拟化扩展到Windows 根操作系统?答案是:
[@harrymc] 虚拟化扩展始终对根操作系统可见,因为它们是 CPU 的一部分,并且所有硬件始终传递到该操作系统,没有任何东西被虚拟化。 Set-VMProcessor 不适用,因为它不是真正的 VM,或者您可能会说它是一种特殊且微不足道的半 VM。
[我] 因此,root os 已经可以“直接”看到 virt.ext。(因为它可以看到所有其余硬件),但它无法将它们用于(比方说)VirtualBox,因为它们已被 Hyper-V 使用。如果我创建一个启用了 virt.ext 的“普通”Hyper-V VM,那么我应该能够在其中运行另一个虚拟机管理程序,对吗?
[@harrymc] 对,就是这样的。
答案1
嵌套虚拟化 不需要您运行相同的虚拟机管理程序,因为它仅意味着通过 Intel VT-x 或 AMD-V CPU 扩展。虽然可能,但这并不意味着嵌套不同的虚拟机管理程序很容易,因为这不受相关公司的官方支持。
使用不同的虚拟机管理程序时,您将遇到硬件支持的问题,因为每个虚拟机管理程序都会创建不同的虚拟设备,这些虚拟设备可能不受支持或在其他虚拟机管理程序或目标虚拟机上具有驱动程序。
例如,Hyper-V 将网络适配器作为与 Hyper-V 虚拟网络交换机绑定的虚拟网络适配器公开给虚拟机。这意味着,无论服务器中实际安装了哪种类型的网络适配器,嵌套虚拟机管理程序都需要 Microsoft Hyper-V 网络适配器或 Microsoft Legacy 网络适配器的驱动程序,而 VMware 可能不支持这些驱动程序。即使存在正确的驱动程序,将设备模拟作为多个相互伪装的设备通过多个模拟层传递肯定不会提高性能。
解决这些模拟和性能问题的一个方法是使用离散设备分配,即硬件直通。离散设备分配是在 Windows Server 2016 中引入的,因此对于嵌套虚拟化,例如,基于 PCIe 的网络适配器可以直接映射到运行虚拟化管理程序的 VM。这可以消除对虚拟设备驱动程序的需求,并让设备制造商的设备驱动程序正常安装在来宾虚拟机内。
虽然离散设备分配解决了一些问题,但也带来了新的问题和限制。例如,在 Hyper-V 中,分配了此类设备的虚拟机可能不支持保存/恢复、实时迁移或使用动态内存,也无法添加到故障转移群集。(由于该领域仍在发展,这些限制可能会在未来消失。)
也有报道称,一些多供应商嵌套虚拟机管理程序环境要求为嵌套虚拟机管理程序内运行的任何虚拟机启用嵌套。这意味着嵌套虚拟机管理程序运行时没有问题,但虚拟机将无法启动,直到在 VM 级别安装虚拟机管理程序。
由于上述考虑因素以及我未列出的其他因素,让相互竞争的虚拟机管理程序协同工作并非易事。即使在安装了嵌套虚拟机管理程序之后,您仍可能需要进行大量尝试和错误,才能让虚拟机以可靠且高效的方式运行。
最后,为了支持我的断言,即不同的虚拟机管理程序可以嵌套,这里有一些文章提供了有关如何执行此操作的说明(尽管我没有测试过任何一个):