http://www.zhihu.com/question/24123210
vmware workstation和virtual box就不是基于内核的虚拟机吗？
它这样做有哪些好处呢？对于物理机和虚拟机而言分别有那些好事呢？
++++++++++++++++++++++++++++
作者：in nek
链接：http://www.zhihu.com/question/24123210/answer/100874195
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
链接：http://www.zhihu.com/question/24123210/answer/100874195
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
这个问题下面好几个答案是完全错的，也有些是对的，但写得很简单，看相关的讨论，估计读者都没有读懂。这里的关键问题是概念比较乱，我来帮忙整理一下。
下面的概念定义很多来自我自己的定义，但和现有的概念基本上不会冲突，也应该更容易帮助读者理解虚拟化技术，所以我猜应该没有什么问题。
虚拟化技术，一般理解上，是在一个操作系统之上，模拟另一个操作系统的执行环境。我们看到的各种游戏机模拟器，还有为开发CPU做仿真而做的模拟程序，就是早期比较常见的虚拟化解决方案，它的工作原理很简单：把CPU的所有寄存器都写在一组变量中（这组变量我们称为CPUFile），然后用一片内存当作被模拟CPU的内存（这片内存这里称为vMEM），然后在用一些数据结构表示IO设备的状态（这里称为vIO），三者的数据结构综合在一起，就是代表一个虚拟化的环境了（这里称之为VM），之后按顺序读出一条条的指令，根据这个指令的语义，更改VM的数据结构的状态（如果模拟了硬件，还要模拟硬件的行为，比如发现显存被写了一个值，可以在虚拟屏幕上显示一个点等），这样，实施虚拟的那个程序就相当于给被虚拟的程序模拟了一台计算机，这种技术，我称它为“解释型虚拟化技术”。指令是被一条一条解释执行的。
在这个方案中，我们有三个对象：
Host：执行虚拟程序的系统
Emulator：实施虚拟的，运行在Host上的那个程序
Guest：被虚拟出来的系统，也就是运行了软件（例如操作系统）的VM
这些概念在技术演进的过程中会一定程度变化，读者要注意这一点，记住它的原始含义，否则很容易乱掉。
解释型虚拟化技术很简单，直接，概念也容易理解，但很明显，这个效率是很低的。优化得比较成功的是qemu，它使用一种所谓“编译型”的技术，把每条被虚拟的设备的指令都写成一段C代码，用这段C代码去修改CPUFile等VM数据，然后再用编译器去编译这些C代码，借用了编译器的优化能力，最后在解释Guest的指令的时候，用一个“翻译区“，把这些C代码的编译结果拼起来，然后直接执行。这种方法有效提高了”解释”的效率（所以qemu才称为Quick-emulator），但效率很明显还是非常低的。Android的SDK模拟基于ARM的手机，用的就是这种技术。
随着技术的发展，有人就开始取巧了：很多时候，我们仅仅是在x86上模拟x86，这些指令何必要一条条解释执行？我们可以用CPU直接执行这些指令啊，执行到特权指令的时候，我们直接异常，然后在异常中把当前CPU的状态保存到CPUFile中，然后再解释执行这个特权指令，这样不是省去了很多”解释“的时间了？用这种技术实现的虚拟机，就称为”调度型虚拟化技术“，这种情况下，Emulator的主要工作就不是解释了，它的主要工作是调度，调度Host和所有的Guest来分时（或者分核）使用CPU。
qemu也可以工作在这种模式。要工作在这种模式，它需要在内核中插入一个kqemu.ko，以便处理那些特殊的，由它的模拟程序产生的异常。
这种情况下，我们会发现，Emulator已经不是原来那个意思了，虽然我们仍需要使用这个程序，但仅仅靠这个程序，它作为Host上的一个程序，没有办法调度Host的资源。所以我们引入另一个实体，所谓Hypervisor，Hypervisor负责调度，Emulator只是给它提请求而已。
（这里，Emulator的语义也发生变更了，读者有必要注意这一点）
Hypervisor需要掌控整个系统的资源，这样它就需要有所有设备的驱动，这样会让Hypervisor变得非常复杂的。所以Host的概念仍然存在，一种简化的理解可以是，BIOS启动Hypervisor，Hypervisor首先启动第一个OS，那个就是Host，之后Host上的Emulator启动Guest，Emulator向Hypervisor请求资源，Hypervisor模拟一个环境给新的Guest，但如果Guest向Hypervisor请求IO或者其他特殊能力，这些请求就会被Hypervisor调度到Host上，让Host执行。
在Xen上，这个Host称为DOM0，说明Xen是认为Host和Guest在调度上没有本质区别的，都是一个调度的对象，但DOM0带有所有的驱动，管理程序也可以放在这里直接和Hypervisor通讯。
好了，现在你可以明白为什么KVM称为”内核（K）的VM"技术了，Xen的Hypervisor是一个独立的部件，由BIOS（其实是grub了）直接加载，然后和DOMx的各个操作系统通讯。而KVM的Hypervisor直接就是内核的一部分，这个Hypervisor的代码直接就在Linux的内核中，当Host启动的时候，它们一起加载，一同初始化，只是Hypervisor的代码工作在虚拟机调度器的状态，而其他代码工作在普通内核状态而已。
这个用ARM64平台特别好理解，ARM64平台（不考虑安全态）3个特权级，EL0用户态，EL1内核态，EL2 Hypervisor态。这样，内核启动先进入EL2，初始化Hypervisor部分的状态，然后切换入EL1，初始化内核的状态，然后才fork init，进入EL0。这之后，你启动qemu-kvm，这个程序就可以通过系统调用（对/dev/kvm文件做ioctl）进入内核，调用KVM的请求，执行调度，从内核中直接做Hypervisor请求，进入Hypervisor要求调度Guest。
这样，很明显，KVM确实是”Linux内核提供的虚拟化技术“，这就是它和其他虚拟化技术不同的地方了。
vmware和virtualbox的技术和Xen类似，无论它们如何加载，是否独立，或者作为一个内核模块加载，毕竟它们不是内核原始设计的一部分。
至于是全虚拟化（Guest不知道你自己是被模拟的系统），还是Para虚拟化（Guest知道自己是模拟的系统，用直接和Hypervisor通讯的方法实现IO），这个问题和是否KVM没有关系（kvm两种模式都可以支持），和性能也没有关系。这仅仅是构架的不同。
讨论区有读者问，为什么没有看到VirtualBox从BIOS加载Hypervisor呢？这个涉及到两个要素：
第一，kqemu.ko也可以不从BIOS加载，这种模式我仍把kqemu称为Hypervisor，但这个Hypervisor并非工作在Hypervisor状态，它是和内核互相妥协从而工作在Hypervisor的角色上的，它的工作级别并不比Host高，但仍可以为Guest模拟出一个运行环境来。VirtualBox使用一样的技术。
第二，VirtualxBox还可以支持VT-x这样的硬件加速的虚拟工作状态。这个事情和VT-x的设计有关，VT-x的特权级继承自传统的x86特权级，就是0-3，0是最高优先级，3是最低优先级。像Linux就只用了0和3级表示内核和用户态。刚开始支持虚拟化的时候，Intel考虑0是Hypervisor级（VMM级），1是内核，3是用户。但这种设计造成不兼容和复杂度。所以到了64位后，新的模式是：系统刚启动的时候，是Host态0级，在这个级别你可以用VMXON进入VMM级，然后你可以在这个级别创建虚拟机，再用VMXON进入虚拟机，VMXOFF退出虚拟机。虚拟机中仍可以有0-3级。这样一来，在Host中，你只要能进入0级，就可以把自己提升到VMM级。VirtualBox只要能在内核中插入一个模块，就可以为自己获得VMM的权限。但这个方法在ARM64上是行不通的。
（读者应该已经注意到了，这里面的定义在整个发展过程中不断发生语义的变化，这造成很多人对技术误解，所以，我们理解计算的概念，更多看我们如何用和如何建模，如果你认为某个概念是持久不变的，基本上你很快就被计算机技术抛弃了。因为基于概念保持部分使用模式不变，然后进行技术演进，是计算机发展的常态）
下面的概念定义很多来自我自己的定义，但和现有的概念基本上不会冲突，也应该更容易帮助读者理解虚拟化技术，所以我猜应该没有什么问题。
虚拟化技术，一般理解上，是在一个操作系统之上，模拟另一个操作系统的执行环境。我们看到的各种游戏机模拟器，还有为开发CPU做仿真而做的模拟程序，就是早期比较常见的虚拟化解决方案，它的工作原理很简单：把CPU的所有寄存器都写在一组变量中（这组变量我们称为CPUFile），然后用一片内存当作被模拟CPU的内存（这片内存这里称为vMEM），然后在用一些数据结构表示IO设备的状态（这里称为vIO），三者的数据结构综合在一起，就是代表一个虚拟化的环境了（这里称之为VM），之后按顺序读出一条条的指令，根据这个指令的语义，更改VM的数据结构的状态（如果模拟了硬件，还要模拟硬件的行为，比如发现显存被写了一个值，可以在虚拟屏幕上显示一个点等），这样，实施虚拟的那个程序就相当于给被虚拟的程序模拟了一台计算机，这种技术，我称它为“解释型虚拟化技术”。指令是被一条一条解释执行的。
在这个方案中，我们有三个对象：
Host：执行虚拟程序的系统
Emulator：实施虚拟的，运行在Host上的那个程序
Guest：被虚拟出来的系统，也就是运行了软件（例如操作系统）的VM
这些概念在技术演进的过程中会一定程度变化，读者要注意这一点，记住它的原始含义，否则很容易乱掉。
解释型虚拟化技术很简单，直接，概念也容易理解，但很明显，这个效率是很低的。优化得比较成功的是qemu，它使用一种所谓“编译型”的技术，把每条被虚拟的设备的指令都写成一段C代码，用这段C代码去修改CPUFile等VM数据，然后再用编译器去编译这些C代码，借用了编译器的优化能力，最后在解释Guest的指令的时候，用一个“翻译区“，把这些C代码的编译结果拼起来，然后直接执行。这种方法有效提高了”解释”的效率（所以qemu才称为Quick-emulator），但效率很明显还是非常低的。Android的SDK模拟基于ARM的手机，用的就是这种技术。
随着技术的发展，有人就开始取巧了：很多时候，我们仅仅是在x86上模拟x86，这些指令何必要一条条解释执行？我们可以用CPU直接执行这些指令啊，执行到特权指令的时候，我们直接异常，然后在异常中把当前CPU的状态保存到CPUFile中，然后再解释执行这个特权指令，这样不是省去了很多”解释“的时间了？用这种技术实现的虚拟机，就称为”调度型虚拟化技术“，这种情况下，Emulator的主要工作就不是解释了，它的主要工作是调度，调度Host和所有的Guest来分时（或者分核）使用CPU。
qemu也可以工作在这种模式。要工作在这种模式，它需要在内核中插入一个kqemu.ko，以便处理那些特殊的，由它的模拟程序产生的异常。
这种情况下，我们会发现，Emulator已经不是原来那个意思了，虽然我们仍需要使用这个程序，但仅仅靠这个程序，它作为Host上的一个程序，没有办法调度Host的资源。所以我们引入另一个实体，所谓Hypervisor，Hypervisor负责调度，Emulator只是给它提请求而已。
（这里，Emulator的语义也发生变更了，读者有必要注意这一点）
Hypervisor需要掌控整个系统的资源，这样它就需要有所有设备的驱动，这样会让Hypervisor变得非常复杂的。所以Host的概念仍然存在，一种简化的理解可以是，BIOS启动Hypervisor，Hypervisor首先启动第一个OS，那个就是Host，之后Host上的Emulator启动Guest，Emulator向Hypervisor请求资源，Hypervisor模拟一个环境给新的Guest，但如果Guest向Hypervisor请求IO或者其他特殊能力，这些请求就会被Hypervisor调度到Host上，让Host执行。
在Xen上，这个Host称为DOM0，说明Xen是认为Host和Guest在调度上没有本质区别的，都是一个调度的对象，但DOM0带有所有的驱动，管理程序也可以放在这里直接和Hypervisor通讯。
好了，现在你可以明白为什么KVM称为”内核（K）的VM"技术了，Xen的Hypervisor是一个独立的部件，由BIOS（其实是grub了）直接加载，然后和DOMx的各个操作系统通讯。而KVM的Hypervisor直接就是内核的一部分，这个Hypervisor的代码直接就在Linux的内核中，当Host启动的时候，它们一起加载，一同初始化，只是Hypervisor的代码工作在虚拟机调度器的状态，而其他代码工作在普通内核状态而已。
这个用ARM64平台特别好理解，ARM64平台（不考虑安全态）3个特权级，EL0用户态，EL1内核态，EL2 Hypervisor态。这样，内核启动先进入EL2，初始化Hypervisor部分的状态，然后切换入EL1，初始化内核的状态，然后才fork init，进入EL0。这之后，你启动qemu-kvm，这个程序就可以通过系统调用（对/dev/kvm文件做ioctl）进入内核，调用KVM的请求，执行调度，从内核中直接做Hypervisor请求，进入Hypervisor要求调度Guest。
这样，很明显，KVM确实是”Linux内核提供的虚拟化技术“，这就是它和其他虚拟化技术不同的地方了。
vmware和virtualbox的技术和Xen类似，无论它们如何加载，是否独立，或者作为一个内核模块加载，毕竟它们不是内核原始设计的一部分。
至于是全虚拟化（Guest不知道你自己是被模拟的系统），还是Para虚拟化（Guest知道自己是模拟的系统，用直接和Hypervisor通讯的方法实现IO），这个问题和是否KVM没有关系（kvm两种模式都可以支持），和性能也没有关系。这仅仅是构架的不同。
讨论区有读者问，为什么没有看到VirtualBox从BIOS加载Hypervisor呢？这个涉及到两个要素：
第一，kqemu.ko也可以不从BIOS加载，这种模式我仍把kqemu称为Hypervisor，但这个Hypervisor并非工作在Hypervisor状态，它是和内核互相妥协从而工作在Hypervisor的角色上的，它的工作级别并不比Host高，但仍可以为Guest模拟出一个运行环境来。VirtualBox使用一样的技术。
第二，VirtualxBox还可以支持VT-x这样的硬件加速的虚拟工作状态。这个事情和VT-x的设计有关，VT-x的特权级继承自传统的x86特权级，就是0-3，0是最高优先级，3是最低优先级。像Linux就只用了0和3级表示内核和用户态。刚开始支持虚拟化的时候，Intel考虑0是Hypervisor级（VMM级），1是内核，3是用户。但这种设计造成不兼容和复杂度。所以到了64位后，新的模式是：系统刚启动的时候，是Host态0级，在这个级别你可以用VMXON进入VMM级，然后你可以在这个级别创建虚拟机，再用VMXON进入虚拟机，VMXOFF退出虚拟机。虚拟机中仍可以有0-3级。这样一来，在Host中，你只要能进入0级，就可以把自己提升到VMM级。VirtualBox只要能在内核中插入一个模块，就可以为自己获得VMM的权限。但这个方法在ARM64上是行不通的。
（读者应该已经注意到了，这里面的定义在整个发展过程中不断发生语义的变化，这造成很多人对技术误解，所以，我们理解计算的概念，更多看我们如何用和如何建模，如果你认为某个概念是持久不变的，基本上你很快就被计算机技术抛弃了。因为基于概念保持部分使用模式不变，然后进行技术演进，是计算机发展的常态）