根据stackoverflow.com here上的明确答案和另一个参考here，我理解：
虚拟机管理程序虚拟化=低于操作系统和硬件虚拟化，其中硬件旨在支持虚拟化
非虚拟机管理程序虚拟化=在操作系统之上（如应用程序软件），纯粹是软件虚拟化
但我们也有Type1和Type2 classifications for hypervisors，在我看来，Type2纯粹是软件虚拟化......所以这是否意味着非Hypervisor虚拟化等同于Type 2 Hypervisor或者是否有一些微妙的差异??
或者这些术语都是松散定义的吗？
提前致谢。
答案 0 :(得分：2)
在我看来，非虚拟机管理程序虚拟化意味着运行除了操作系统之外的其他东西的虚拟化层 - 最常见的是虚拟化某些其他操作系统的用户级环境。例如，WINE项目是非虚拟机管理程序虚拟化 - 它允许在Linux（或其他）主机上运行win32程序。没有尝试运行实际的Windows操作系统或模拟虚拟化操作系统的“裸”硬件。而是虚拟层直接为窗口提供用户级抽象和系统调用。
将此与管理程序进行对比，管理程序可以是类型1（在裸机上运行）或类型2（在操作系统上运行），它提供硬件级抽象，并且您可以在其上运行整个操作系统。
答案 1 :(得分：2)
在我看来，Type2纯粹是软件虚拟化
不要混淆“类型1与类型2”和“硬件与软件”虚拟化。事实上，硬件和软件之间实际上存在中间立场：有全硬件（HVM），“部分”硬件（PVM）和纯软件（SW）。
我将尝试通过扩展所有6种组合来澄清：
类型1 +完整硬件（HVM） - 这允许像Xen HVM这样的虚拟机管理程序引导未修改的来宾操作系统。这实际上很慢，因为管理程序必须解析客户操作系统试图发送给硬件的“电报消息”。 （即写入磁盘驱动器涉及在0xblahblah位置重复存储字节。）
类型1 +半虚拟化（PVM） - 这是您稍微修改guest虚拟机操作系统以直接为某些任务（如磁盘I / O）调用Hypervisor。这更快，因为客户只是说“在这里写这个字节页”而不必在每个字节上做（虚拟化）I / O.您知道在安装特殊驱动程序时正在进行PVM。当然，有时操作系统已经内置了虚拟驱动程序。例如，任何现代Linux内核在检测到它在Xen，KVM，UML等下运行时会自动切换到PVM模式。
类型1 +纯软件（SW） - 我不确定这是否存在，但构建起来并不难。由于软件仿真速度很慢，因此启动实际操作系统和运行Type 2的开销并不是很大。
类型2 +完整硬件（HVM） - 这允许您在VirtualBox或KVM下引导未修改的Windows。你知道它是类型2，你可以重新启动所有的客人，仍然在后台播放MP3：）
类型2 +半虚拟化（PVM） - 每次安装来宾驱动程序或在VirtualBox / KVM下启动现代Linux内核时都会发生这种情况。
Type 2 + Pure Software（SW） - 早期版本的Bochs和Qemu。 （后期版本实际上也有硬件辅助模式。）你可以说它们是“纯软件”，因为它们允许你运行你通常无法运行的软件。 （即我在ARM处理器上运行Bochs下的Windows '95，我在Qemu下的x86上启动了ARM发行版。）
还有另一个与上述不同的主题：
容器技术。 Docker / Rkt / LXD等容器不适合上表。容器中的应用程序是以普通方式调用内核的普通程序，不涉及Hypervisor。
只是容器使用cgroups和命名空间的内核功能来使应用程序“感觉”像在VM中一样。每个容器都获得系统的“分区”视图：它是自己的文件系统，它自己的用户ID，它自己的进程ID，它自己的主机名+ IP地址等。但是从外部，你可以看到所有容器中的所有进程都有' PS'。
答案 2 :(得分：1)
根据定义，Hypervisor模拟硬件。 （这可能存在也可能不存在） - 它可以虚拟化一些。
虚拟化拦截一个呼叫并将其重定向到其他地方。
它们是两个不同但相互关联的主题。
Type 1 Hypervisors 在“裸机”上运行，位于硬件和虚拟操作系统之间（虚拟机管理程序本身就是操作系统）。例如，VMWare ESX，Citrix XenServer或Microsoft Hyper-V
Type 2 Hypervisors 在您现有的操作系统之上运行，可能支持硬件或软件虚拟化。例如，QEmu和Bochs都模拟整个CPU，可选地甚至是不同的CPU架构。两者都是Type 2 Hypervisor，但由于需要仿真，因此性能开销很大。
VMware Workstation / Server / Player / Fusion，Parallels，Virtualbox都是支持的第2类虚拟机管理程序的示例Hardware-assisted Virtualization - 这意味着CPU指令不是模拟CPU指令，而是直接通过，无需仿真或转换 - 如果处理器支持，则可以在不损失性能的情况下有效运行。
接下来，非虚拟机管理程序虚拟化，这是（有效）应用程序虚拟化。硬件本身并没有以任何方式进行仿真，虚拟化层只是拦截某些系统调用并对其进行虚拟化。此类别中的示例包括VMWare Thinapp，Microsoft App-V等等。 Windows Vista本身虚拟化某些注册表和磁盘写入到用户无权写入的区域。 Vista中的虚拟化对于向后兼容许多传统应用程序至关重要。
最后我们有纯粹的模拟器 - 这里没有虚拟化。在此类别中，我们WINE并且在某种程度上Cygwin。此外，Bochs适用于此类别以及Type 2 Hypervisor，因为没有虚拟化，只有硬件仿真。 DOSEMU是另一个适合这里的人。
我确定我错过了很多例子，但是
答案 3 :(得分：0)
（我将此评论发布到＃answer-16868851，因为我错过了几个要点＆＃34;你必须有50个评论的声誉和＃34; 要求）
类型1 +纯软件（SW） - 我不确定这是否存在，但它不会难以构建。由于软件仿真速度慢，启动真实操作系统和运行Type 2的开销并不大。
到目前为止，我发现只有一个 Type 1 虚拟机管理程序能够执行此操作 - 它的 VMware ESXi 。
vSphere 5文档中心| ESXi Hardware Requirements说：
■要支持64位虚拟机，必须在x64 CPU上启用对硬件虚拟化（Intel VT-x或AMD RVI）的支持。
因此，32位客人在没有VT-x的情况下工作。
由于我认为它没有竞争（无论是专有还是开源），我想在没有VT-x支持的情况下捕获敏感的CPU指令（即纯软件中的 ）在实践中是一个严峻的挑战。 / p>
虽然以下内容与原始问题没有关系，但v5.0（和v4.x）需要来自CPU的64位支持：
■ESXi 5.0仅在具有64位x86 CPU的服务器上安装和运行。
■ESXi 5.0要求主机至少具有两个核心。
那些对在32位计算机上运行 Type 1 + SW 虚拟机管理程序感兴趣的人（比如我）可能会使用它的早期版本。 Minimum system requirements for installing 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 Installation Guide在以下部分/小节中重复这一点：
ESX Server 3要求
本节讨论ESX Server 3版本3.5支持的最小和最大硬件配置。
最低服务器硬件要求
...
因此， Pure（和仅32位）软件：）