根据此处 stackoverflow.com 上的标记答案和此处的另一个参考，我了解：
管理程序虚拟化 = 低于操作系统和硬件虚拟化，其中硬件旨在支持虚拟化
非 Hypervisor 虚拟化 = 在操作系统之上（如应用软件），即纯粹的软件虚拟化
但是我们也有针对虚拟机管理程序的 Type1 和 Type2 分类，在我看来 Type2 是纯粹的软件虚拟化......那么这是否意味着非虚拟机管理程序虚拟化等同于 Type 2 虚拟机管理程序，还是有一些细微的差异？
还是这些术语都是松散定义的？
提前致谢。
在我看来，Type2 是纯粹的软件虚拟化
不要将“类型 1 与类型 2”和“硬件与软件”虚拟化混为一谈。事实上，硬件和软件之间实际上存在一个中间地带：有完整硬件（HVM）、“部分”硬件（PVM）和纯软件（SW）。
我将尝试通过扩展所有 6 种组合来澄清：
类型 1 + 全硬件 (HVM) - 这允许像 Xen HVM 这样的管理程序启动未修改的客户操作系统。这实际上很慢，因为管理程序必须解码客户操作系统试图发送到硬件的“电报消息”。（即写入磁盘驱动器涉及在位置 0xblahblah 重复存储字节。）
类型 1 + 半虚拟化 (PVM) - 这是当您稍微修改来宾操作系统以直接调用 Hypervisor 执行某些任务时，例如磁盘 I/O。这更快，因为客人只是说“在这里，写这个字节页”并且不必对每个字节进行（虚拟化）I/O。当您安装特殊驱动程序时，您知道您正在执行 PVM。当然，有时操作系统已经内置了虚拟驱动程序。例如，任何现代 Linux 内核都会在启动时自动切换到 PVM 模式，当它检测到它在 Xen、KVM、UML 等下运行时。
Type 1 + Pure Software (SW) - 我不确定这是否存在，但构建起来并不难。由于软件仿真很慢，因此启动真实操作系统和运行 Type 2 的开销并不是什么大问题。
类型 2 + 全硬件 (HVM) - 这允许您在 VirtualBox 或 KVM 下启动未修改的 Windows。当您可以重新启动所有客人并仍然在后台播放 MP3 时，您知道它是类型 2 :)
类型 2 + 半虚拟化 (PVM) - 每当您安装客户驱动程序或在 VirtualBox/KVM 下启动现代 Linux 内核时都会发生这种情况。
Type 2 + Pure Software (SW) - Bochs 和 Qemu 的早期版本。（后来的版本实际上也有硬件辅助模式。）您可以说它们是“纯软件”，因为它们允许您运行通常没有它就无法运行的软件。（即，我在 ARM 处理器上的 Bochs 下运行 Windows '95，并且在 Qemu 下的 x86 上启动了 ARM 发行版。）
还有一个与上述不同的主题：
容器技术。Docker/Rkt/LXD 等容器不适合上表。容器中的应用程序是以普通方式调用内核的普通程序，不涉及 Hypervisor。
只是容器使用 cgroups 和命名空间的内核特性来让应用“感觉”就像在虚拟机中一样。每个容器都有一个系统的“分区”视图：它是自己的文件系统、它自己的用户 ID、它自己的进程 ID、它自己的主机名 + IP 地址等。但是从外部，你可以看到所有容器中的所有进程都带有 ' ps'。
在我看来，非 Hypervisor 虚拟化是指在其上运行除操作系统之外的其他东西的虚拟化层——最常见的是虚拟化其他操作系统的用户级环境。例如，WINE 项目是非管理程序虚拟化——它允许在 linux（或其他）主机上运行 win32 程序。没有尝试运行实际的 Windows 操作系统或模拟虚拟化操作系统的“裸”硬件。相反，虚拟层直接为 Windows 提供用户级抽象和系统调用。
将其与可能是类型 1（在裸机上运行）或类型 2（在操作系统上运行）的管理程序进行对比，它提供硬件级别的抽象，您可以在其上运行整个操作系统。
根据定义，Hypervisor 模拟硬件。（物理上可能存在也可能不存在） - 它也可能虚拟化一些。
虚拟化拦截呼叫并将其重定向到其他地方。
它们是两个不同但相互关联的主题。
类型 1 管理程序在“裸机”上运行，位于硬件和虚拟操作系统之间（管理程序本身就是操作系统）。例如，VMWare ESX、Citrix XenServer或Microsoft Hyper-V
Type 2 Hypervisor在您现有的操作系统之上运行，可能支持硬件或软件虚拟化。例如，QEmu和Bochs都模拟整个 CPU，甚至可以选择不同的 CPU 架构。两者都是 Type 2 Hypervisor，但由于需要仿真，性能开销很大。
VMware Workstation / Server / Player / Fusion、Parallels、Virtualbox都是支持硬件辅助虚拟化的 Type 2 虚拟机管理程序的示例——这意味着 CPU 指令无需模拟或转换即可直接通过——有效如果处理器支持，则不会损失性能。
接下来是非管理程序虚拟化，它（有效地）是应用程序虚拟化。硬件本身根本没有被模拟，虚拟化层只是拦截某些系统调用并将它们虚拟化。此类别中的示例包括 VMWare Thinapp、Microsoft App-V等等。Windows Vista 本身将某些注册表和磁盘写入虚拟化到用户无权写入的区域。Vista 中的这种虚拟化对于向后兼容许多遗留应用程序至关重要。
最后我们有了纯模拟器——这里没有虚拟化。在这个类别中，我们有WINE和某种程度上的Cygwin。由于没有虚拟化，只有硬件仿真， Bochs也属于这一类以及 Type 2 Hypervisor。DOSEMU是另一个适合这里的。
我敢肯定我错过了很多例子，但是
（我会在此处将我的评论发布到#answer-16868851，因为我错过了几个点来满足“您必须有 50 名声望才能发表评论”的要求）
Type 1 + Pure Software (SW) - 我不确定这是否存在，但构建起来并不难。由于软件仿真很慢，因此启动真实操作系统和运行 Type 2 的开销并不是什么大问题。
到目前为止，我发现只有一个1 类管理程序能够做到这一点——它是VMware ESXi。
vSphere 5 文档中心 | ESXi 硬件要求说：
■ 要支持 64 位虚拟机，必须在 x64 CPU 上启用对硬件虚拟化（Intel VT-x 或 AMD RVI）的支持。
因此，32 位客户机可以在没有 VT-x 的情况下工作。
当我看到它出现了零竞争（专有或开源）时，我猜想在没有 VT-x 支持的情况下捕获敏感的 CPU 指令（即在 Pure Software 中）在实践中是一个严峻的挑战。
虽然以下已经与原始问题无关，但 v5.0（和 v4.x）需要 CPU 的 64 位支持：
■ ESXi 5.0 将仅在具有 64 位 x86 CPU 的服务器上安装和运行。
■ ESXi 5.0 要求主机至少具有两个内核。
那些对在32 位机器上 运行Type 1 + SW hypervisor 感兴趣的人（比如我）可能会使用它的早期版本。安装 ESXi/ESX (1003661) 的最低系统要求说：
ESX 3.5.x
ESX 3.5.x 的硬件要求与 ESX 3.0.x 部分中列出的相同，但添加了以下内容。
[...]
ESX 3.0.x
您需要以下硬件和系统资源来安装和使用 ESX 3：
At least two processors: 1500 MHz Intel Xeon and above, or AMD Opteron (32bit mode) for ESX 1500 MHz Intel Xeon and above, or AMD Opteron (32bit mode) for Virtual SMP 1500 MHz Intel Viiv or AMD A64 x2 dual-core processors
+ ESX 3.5 安装指南在以下部分/小节中重复了这一点：
ESX Server 3 要求
本节讨论 ESX Server 3 版本 3.5 支持的最低和最高硬件配置。
最低服务器硬件要求
...
因此，纯（仅限 32 位）软件:)