非虚拟机管理程序虚拟化与 Type2 虚拟机管理程序

Question

根据 stackoverflow.com 此处 和另一个的标记答案参考这里，我的理解是：

Hypervisor虚拟化=低于操作系统和硬件虚拟化，其中硬件被设计为支持虚拟化

非虚拟机管理程序虚拟化 = 在操作系统之上（如应用程序软件），即纯粹的软件虚拟化

但我们也有 Type1 和 Type2 虚拟机管理程序的分类 在我看来，Type2 纯粹是软件虚拟化...这是否意味着非虚拟机管理程序虚拟化相当于类型 2管理程序还是有一些细微的差别？

或者这些术语的定义都是松散的？

提前致谢。

Answer 1

在我看来，Type2 纯粹是软件虚拟化

不要将“Type 1 与 Type 2”和“硬件与软件”虚拟化混为一谈。事实上，硬件和软件之间实际上存在一个中间立场：有全硬件（HVM）、“部分”硬件（PVM）和纯软件（SW）。

我将尝试通过展开所有 6 种组合来进行澄清：

类型 1 + 全硬件 (HVM) - 这允许像 Xen HVM 这样的虚拟机管理程序引导未修改的来宾操作系统。这实际上很慢，因为管理程序必须解码来宾操作系统尝试发送到硬件的“电报消息”。 （即写入磁盘驱动器涉及在位置 0xblahblah 中重复存储字节。）

类型 1 + 半虚拟化 (PVM) - 这是当您稍微修改来宾操作系统以直接调用虚拟机管理程序来执行某些任务时，就像磁盘 I/O 一样。这更快，因为来宾只需说“在这里，写入这一页字节”，而不必在每个字节上执行（虚拟化）I/O。当您安装特殊驱动程序时，您就知道您正在执行 PVM。当然，有时操作系统已经内置了虚拟驱动程序。例如，当任何现代 Linux 内核检测到它在 Xen、KVM、UML 等下运行时，它都会在启动时自动切换到 PVM 模式。

类型 1 + 纯软件 (SW) - 我不确定如果存在的话，但构建起来并不难。由于软件模拟速度很慢，因此启动真实操作系统和运行 Type 2 的开销并不是什么大问题。

类型 2 + 全硬件 (HVM) - 这允许您在 VirtualBox 或 KVM 下启动未经修改的 Windows。当您可以重新启动所有来宾并仍然在后台播放 MP3 时，您就知道这是类型 2 :)

类型 2 + 半虚拟化 (PVM) - 每当您安装来宾驱动程序或启动现代 Linux 时都会发生这种情况VirtualBox/KVM 下的内核。

类型 2 + 纯软件 (SW) - Bochs 和 Qemu 的早期版本。 （后来的版本实际上也有硬件辅助模式。）您可以说它们是“纯软件”，因为它们允许您运行通常没有它就无法运行的软件。 （即我在 ARM 处理器上的 Bochs 下运行了 Windows '95，并且在 Qemu 下的 x86 上启动了 ARM 发行版。）

还有另一个主题与上述不同：

容器技术。像 Docker/Rkt/LXD 这样的容器不适合上表。容器中的应用程序是以普通方式调用内核的普通程序，不涉及虚拟机管理程序。

只是容器使用 cgroup 和命名空间的内核功能来使应用程序“感觉”就像在虚拟机中一样。每个容器都有系统的“分区”视图：它自己的文件系统、它自己的用户 ID、它自己的进程 ID、它自己的主机名 + IP 地址等。但是从外部，您可以使用“查看所有容器中的所有进程”。附言。

Answer 2

在我看来，非虚拟化管理程序虚拟化是指在其之上运行除操作系统之外的其他内容的虚拟化层——最常见的是虚拟化其他操作系统的用户级环境。例如，WINE 项目是非管理程序虚拟化——它允许在 Linux（或其他）主机上运行 win32 程序。没有尝试运行实际的 Windows 操作系统或为虚拟化操作系统模拟“裸”硬件。相反，虚拟层直接为窗口提供用户级抽象和系统调用。

将此与虚拟机管理程序进行对比，虚拟机管理程序可以是类型 1（在裸机上运行）或类型 2（在操作系统上运行），并且提供硬件级抽象，并且您可以在其上运行整个操作系统。

Answer 3

根据定义，虚拟机管理程序模拟硬件。 （这可能物理存在，也可能不存在） - 它可能也可以虚拟化一些。

虚拟化拦截呼叫并将其重定向到其他地方。

它们是两个不同但相互关联的主题。

类型 1 虚拟机管理程序在“裸机”上运行，位于硬件和虚拟操作系统之间（虚拟机管理程序本身就是操作系统）。例如，VMWare ESX、Citrix XenServer 或 Microsoft Hyper-V

2 类虚拟机管理程序 在现有操作系统之上运行，并且可以支持硬件或软件虚拟化。例如 QEmu 和 Bochs）模拟整个 CPU，甚至可以选择不同的 CPU 架构。两者都是 Type 2 Hypervisor，但由于需要仿真，因此在性能上有很大的开销。

VMware Workstation/服务器/播放器/Fusion、Parallels、Virtualbox 都是支持 硬件辅助虚拟化 - 这意味着CPU指令可以直接通过，无需模拟或翻译 - 有效运行，无损失如果处理器支持的话，会影响性能。

接下来是非管理程序虚拟化，它是（有效的）应用程序虚拟化。硬件本身根本没有以任何方式进行模拟，虚拟化层只是拦截某些系统调用并将其虚拟化。此类别中的示例包括 VMWare Thinapp、Microsoft App-V 等等。 Windows Vista 本身将某些注册表和磁盘写入虚拟到用户无权写入的区域。 Vista 中的虚拟化对于向后兼容许多遗留应用程序至关重要。

最后，我们有了纯模拟器 - 这里没有发生虚拟化。在这个类别中，我们有WINE，并且在某种程度上Cygwin。此外，Bochs 以及 Type 2 Hypervisor 都属于这一类别，因为没有虚拟化，只有硬件模拟。 DOSEMU 是另一个适合这里的。

我确信我错过了很多例子，但是

Answer 4

（我将在这里发布我的评论到#answer-16868851，因为我错过了一些要点“您必须有 50 点声誉才能发表评论”要求）

BraveNewCurrency写道：

类型 1 + 纯软件 (SW) - 我不确定这是否存在，但构建起来并不难。由于软件模拟速度很慢，因此启动真实操作系统和运行 Type 2 的开销并不是什么大问题。

到目前为止，我发现只有一个 Type 1 虚拟机管理程序能够执行此操作 - 它是 VMware ESXi。

vSphere 5 文档中心 | ESXi 硬件要求 说：

■ 要支持 64 位虚拟机，必须在 x64 CPU 上启用硬件虚拟化支持（Intel VT-x 或 AMD RVI）。

因此，32 位客户机可以在没有 VT-x 的情况下工作。

由于我看到它的零竞争（无论是专有的还是开源的），我猜想在没有 VT-x 支持的情况下捕获敏感的 CPU 指令（即在纯软件中）在实践中是一个严峻的挑战。

---

虽然以下内容与原始问题无关，但 v5.0（和 v4.x）需要 CPU 的 64 位支持：

■ ESXi 5.0 将仅在具有 64 位 x86 CPU 的服务器上安装和运行。

■ ESXi 5.0 需要至少具有两个内核的主机。

那些对在 32 位计算机上运行 Type 1 + SW 虚拟机管理程序感兴趣的人（比如我）可能会使用它的早期版本。 安装 ESXi/ESX 的最低系统要求（1003661） 说：

ESX 3.5.x

ESX 3.5.x 的硬件要求与 ESX 3.0.x 部分中列出的硬件要求相同，并添加了以下内容。

[...]

ESX 3.0.x

您需要这些硬件和系统资源来安装和使用 ESX 3：

至少两个处理器：
    1500 MHz Intel Xeon 及更高版本，或适用于 ESX 的 AMD Opteron（32 位模式）
    1500 MHz Intel Xeon 及更高版本，或适用于虚拟 SMP 的 AMD Opteron（32 位模式）
    1500 MHz Intel Viiv 或 AMD A64 x2 双核处理器

+ ESX 3.5 安装指南 在以下部分/小节中重复了这一点：

ESX Server 3 要求

本节讨论 ESX Server 3 版本 3.5 支持的最低和最高硬件配置。

最低服务器硬件要求

...

因此，纯（且仅限 32 位）软件 :)