值得一提的是，这个研究用的原型系统不仅开启了虚拟化技术的时代，也提出了 “分页” 这样一个重要的概念（因为每个虚拟机需要使用虚拟地址，这就需要一层虚拟地址到物理地址的映射）。

在那个 “进程” 概念尚未被发明的年代，多任务操作系统和虚拟化技术事实上是难以分开的，因为 “虚拟机” 就是一个任务，而且当时还没有 Intel x86 这种霸主地位的体系结构，各家的大型机各自为政，也谈不上兼容别家的体系结构。这种 “任务级” 或者说 “进程级” 虚拟化，从概念上延续到今天，就是以 LXC 和 OpenVZ 为代表的操作系统级虚拟化。

这种主要依赖定制的硬件来实现虚拟化的技术，史称 “硬件虚拟化”。在这个什么都要 “软件定义” 的时代，大型机已经日薄西山，大部分依赖硬件的虚拟化也进了历史博物馆。今天我们看到的虚拟化技术，大多是软件为主，硬件为辅。下图所示的划分没有严格的界限，而且一种虚拟化解决方案可能同时使用了下图中的多种技术，因此不要在意这些细节啦~

思科第一台路由器

在网络协议之间翻译和在指令集之间翻译，都是机械、冗长、繁琐的事情，能把它做对，考虑到各种边角情况，是需要无比天才和细心的事情。指令集比网络协议麻烦的地方是，指令的边界（哪里是第一条指令，哪里是最后一条指令）未知，可能执行特权操作（如重启），还能把动态生成的数据作为代码来执行（冯·诺依曼体系结构中，数据和代码共享线性内存空间）。因此，在二进制代码运行之前就做好指令集之间的静态翻译，是不可能的。

最简单粗暴的解决方法是 “模拟执行”。开一个大数组当 “虚拟机” 的内存，拿来指令集手册，写一个无数个 case 的 switch 语句，判断当前要执行的是什么指令，按照手册的说法模拟执行。这样做自然是可行的，但效率就不敢恭维了，虚拟机至少比物理机慢一个数量级。所谓的 “动态类型语言”，如 Python、PHP、Ruby，在编译成中间代码后，大多也是用这种 “模拟执行” 的方法，因此快不起来。著名的 x86 模拟器 Bochs 就是模拟执行的，虽然慢，但兼容性好，而且不容易有安全漏洞。

不能因为指令翻译难做就因噎废食，一个运行 1 亿次的 for 循环，里面如果都是加加减减一类的操作，翻译成机器码直接执行，肯定比模拟执行要快。在二进制翻译前面，要加上 “动态” 两个字，也就是在程序执行的过程中，能翻译的部分翻译成目标架构的机器码直接执行（并缓存起来以便重复利用），不能翻译的部分就陷入到模拟器里，模拟执行特权指令，再对后面的代码进行翻译。如今 Java、.NET、JavaScript 等使用的 JIT（Just-In-Time）技术也是类似的套路。

有人会问，如果我只是虚拟相同的体系结构，比如在 64 位 x86 系统上虚拟一个 64 位 x86 系统，需要做指令翻译吗？需要的。比如，虚拟机可能读取特权寄存器 GDT、LDT、IDT 和 TR，并不会触发处理器异常（即虚拟机管理器无法捕获到这样的行为），但这些特权寄存器的值又是需要对虚拟机 “伪造” 的。这就需要在虚拟机读取特权寄存器的指令执行之前，把它替换成调用虚拟机管理器的指令。

遗憾的是，在大型机年代，能把动态二进制翻译这件事做好的天才级人物 Fabrice Bellard 才刚刚出生（1972 年）。

Fabrice Bellard

Fabrice Bellard 的 QEMU（Quick EMUlator）是目前最流行的采用动态二进制翻译技术的虚拟化软件。它可以模拟 x86、x86_64、ARM、MIPS、SPARC、PowerPC 等多种处理器架构，无修改地运行这些架构上的操作系统。当我们享受视听的乐趣，当我们流畅地运行各种架构的虚拟机系统时，不应忘记 ffmpeg 和 qemu 的创造者 Fabrice Bellard 大神。

以我们最熟悉的 Intel x86 架构为例，分为四个特权级 0~3。一般情况下，操作系统内核（特权代码）运行在 ring 0（最高特权级），而用户进程（非特权代码）运行在 ring 3（最低特权级）。（即使你是 root，你的进程也在 ring 3！只有进了内核才是 ring 0，无上的权力意味着巨大的责任，内核编程的限制很多，吐槽一下）

使用了虚拟机之后，虚拟机（Guest OS）运行在 ring 1，主机操作系统（VMM，Virtual Machine Monitor）运行在 ring 0。比如在 Windows 上装个 Linux 虚拟机，Windows 内核运行在 ring 0，而被虚拟的 Linux 内核运行在 ring 1，Linux 系统里的应用程序则运行在 ring 3。

当虚拟机系统需要执行特权指令时，虚拟机管理器（VMM）就会立即捕获它（谁让 ring 0 比 ring 1 的特权级高呢！）并模拟执行这条特权指令，再返回到虚拟机系统。为了提高系统调用、中断处理的性能，有时会利用动态二进制翻译的技术，在运行前把这些特权指令替换成调用虚拟机管理器 API 的指令。如果所有特权指令都模拟得天衣无缝，虚拟机系统就像运行在物理机器上一样，完全不能发现自己运行在虚拟机里。（当然，事实上还是有一些破绽的）

Paravirtualization 这个单词的前缀是 para-，即 “with” “alongside” 之意。也就是虚拟机系统与虚拟化层（主机系统）不再是严格的上下级关系，而是互信合作的关系，虚拟化层要在一定程度上信任虚拟机系统。在 x86 架构中，虚拟化层（Virtualization Layer）和虚拟机系统的内核（Guest OS）都运行在 ring 0。

虚拟机系统的内核需要经过特殊修改，把特权指令改成对虚拟化层 API 的调用。在现代操作系统中，由于这些体系结构相关的特权操作都被封装起来了（例如 Linux 内核源码中的 arch/ 目录），比起二进制翻译需要考虑各种边角情况，这种对虚拟机内核源码的修改就简单一些了。

相比使用二进制翻译的全虚拟化（full virtualization），半虚拟化是牺牲了通用性来换取性能，因为任何操作系统都可以无修改地运行在全虚拟化平台上，而每个半虚拟化的操作系统内核都要经过人肉修改。

让硬件帮助软件实现虚拟化的概念也不是新东西了。早在 1974 年，著名论文 Formal requirements for virtualizable third generation architectures 就提出了可虚拟化体系结构的三个基本条件：

早期的 x86 指令集不满足上述条件，因此需要虚拟机管理器做复杂的动态二进制翻译。既然二进制翻译的主要开销在 “捕获” 虚拟机系统的特权指令上，CPU 能做的事就是帮忙把 “捕获” 的事情给做了。Intel 家的解决方案叫做 Virtual Machine Control Structures (VT-x)，于 2005 年冬天推出；AMD 也不甘人后，随后推出了类似的 Virtual Machine Control Blocks (AMD-V)。

Intel 在原有的四个特权级基础上，增加了一个专供虚拟机管理器（VMM）使用的 “Root Mode”。这就好像是天不怕地不怕的孙悟空（ring 0）逃不出如来佛（Root Mode）的手掌心。这样，虚拟机系统尽管运行在 ring 0，其执行的特权指令仍然会被 CPU 自动捕获（触发异常），陷入到 Root Mode 的虚拟机管理器里，处理后再使用 VMLAUNCH 或 VMRESUME 指令返回到虚拟机系统。

为了方便半虚拟化（paravirtualization）中用 API 调用替代 CPU 异常捕获，Intel 还提供了从虚拟机（Non-root Mode）到虚拟机管理器（Root Mode）的 “系统调用”：VMCALL 指令。

看起来很美好，不是吗？事实上，对刚刚开始支持硬件辅助虚拟化的 CPU，使用这个方式未必比动态二进制翻译性能高。因为硬件辅助虚拟化模式对每条特权指令，需要切换到 Root Mode，处理完后再返回，这个模式切换就像实模式和保护模式切换一样，需要初始化很多寄存器，还要保存和恢复现场，更不用说对 TLB、高速缓存的影响了。不过，Intel 和 AMD 的工程师也不是吃白饭的，在较新的 CPU 里，硬件辅助虚拟化的性能开销已经比动态二进制翻译做得更好了。

最后说点实用的：在大多数 BIOS 里，硬件辅助虚拟化都是有开关选项的。只有使能了 Intel Virtualization Technology 这样的选项，虚拟机管理器才能用上硬件加速。因此在使用虚拟机的时候，不要忘了进 BIOS 检查一下。

现在我们用的计算机都有分页机制，应用程序（用户态进程）看到的是一片广阔无涯的虚拟内存（Virtual Memory），似乎整台机器都被自己独占；操作系统负责设置用户态进程的虚拟内存到物理内存的映射关系（如下图 VM1 框内所示）；CPU 中的 MMU（Memory Management Unit）负责在用户态程序运行时，通过查询映射关系（所谓的页表），把指令中的虚拟地址翻译成物理地址。

有了虚拟机，事情就麻烦了一层。虚拟机之间要隔离，虚拟机的操作系统也就不能直接看到物理内存。上图中的红色部分即 “机器内存”（MA）由虚拟化层负责管理，而虚拟机看到的 “物理内存”（PA）事实上是被虚拟化的，也就是形成了两级地址映射关系。

在 Intel 的 Nehalem 架构之前（感谢 jonathan 指正），内存管理器（MMU）只知道按照经典的分段、分页机制来进行内存寻址，不知道虚拟化层的存在。虚拟化层需要负责把两级地址映射 “压缩” 成一级映射，如上图红色箭头所示。虚拟化层的做法是：

有人也许会担心增加的一级映射关系会减慢内存访问速度，事实上不论是否启用二级内存翻译（SLAT），页表高速缓存（Translation Lookaside Buffer，TLB）都会存储虚拟地址（VA）到机器地址（MA）的映射。如果 TLB 的命中率较高，则增加的一级内存翻译不会显著影响内存访问性能。

Hyper-V 中的虚拟设备配置

设备虚拟化一般有三种方式：

在物理设备的辅助下，虚拟出多个 “小设备”

我们以网卡为例，看看上述三种设备虚拟化方式是怎样的：

最时髦的做法 ：物理网卡支持虚拟化，可以虚拟出多个 Virtual Function（VF），虚拟化管理器可以把每个 Virtual Function 分配给一个虚拟机，虚拟机里使用定制的驱动程序，就能看到一个独立的 PCI-E 设备。虚拟机访问网卡时也是通过 CPU 的 I/O MMU 直接进行地址翻译，不需要经过虚拟化层。物理网卡内部则有一个简单的交换机，能够在 Virtual Functions 和外面连接的网线之间做转发。这种方法可以用单块网卡实现高性能，但需要比较高端的网卡，需要 CPU 支持 I/O 虚拟化，还需要虚拟机系统内使用定制的驱动程序。

I/O MMU 是让外设和虚拟机能够直接通信的硬件组件，绕过了虚拟机管理器（VMM），提高了 I/O 性能。Intel 的名字叫做 VT-d，而 AMD 的名字叫做 AMD-Vi。它可以把设备寄存器和 DMA 请求中的物理地址（PA）翻译成机器地址（MA），还可以把设备产生的中断分发到虚拟机里。

又到了实用时间：跟硬件辅助虚拟化一样，I/O MMU 在 BIOS 里也是有开关的，别忘了打开哦~

设备虚拟化也有 “全虚拟化” 和 “半虚拟化” 之分。如果虚拟机系统里的驱动程序能够修改，就可以直接调用虚拟机管理器（VMM）的 API，减少模拟硬件设备的开销，这种修改虚拟机内的驱动程序来提高性能的行为就属于半虚拟化。

通过在虚拟机系统里安装额外的驱动程序，还可以实现一些主机与虚拟机之间的交互（如共享剪贴板、拖动传文件）。这些驱动程序会在虚拟机系统中加载钩子，调用虚拟化管理器提供的 API 完成与主机系统的交互。

在虚拟机里安装额外的驱动程序

做个小结，大家可以去喝杯茶，回味一下：

两河缘何入一渠。为了方便开发和测试，1979 年的 UNIX 第七版引入了 chroot 机制。chroot 就是让一个进程把指定的目录作为根目录，它的所有文件系统操作都只能在这个指定目录里进行，这样就不会危害到主机系统。尽管 chroot 存在经典的跳出漏洞，而且它没有对进程、网络等资源进行任何隔离，chroot 至今仍然被用作构建和测试软件的干净环境。

要成为一个真正的虚拟化解决方案，只有文件系统隔离是不够的。另外两个重要的方面是：

这种虚拟机里运行一个或多个进程、虚拟机与主机共享一个内核的虚拟化方案，被称为 “操作系统级虚拟化” 或 “任务级虚拟化”。由于 Linux Containers（LXC）从 Linux 3.8 版本开始被纳入内核主线，操作系统级虚拟化又被称为 “容器”（container）。为了与虚拟机是一个完整的操作系统的虚拟化方案相区分，被隔离执行的进程（进程组）往往不称为 “虚拟机”，而称为 “容器”。由于没有多余的一层操作系统内核，容器比虚拟机更加轻量，启动更快，内存开销、调度开销也更小，更重要的是访问磁盘等 I/O 设备不需要经过虚拟化层，没有性能损失。

Linux 上的操作系统级虚拟化并不是从 LXC 开始有的，恰恰相反，LXC 是 “长江后浪推前浪” 的典型。Linux-Vserver、OpenVZ、Parallels Containers 都是在 Linux 内核里实现操作系统级虚拟化的解决方案。尽管小字辈们赢得了更多的眼球，作为一个长者，OpenVZ 还是比 LXC 多一些 “企业级” 的功能：

OpenVZ 架构

Docker 其实是为系统运维而生的，它大大降低了软件安装、部署的成本。软件的安装之所以是个麻烦事，是因为

OpenStack 云操作系统

OpenStack（或者任何靠谱的云操作系统）要对云上的各种资源进行虚拟化，它的管理组件称为 Nova。

古老的计算虚拟化技术，加上相对新生的存储、网络虚拟化技术，构成了云操作系统的基石。九层之台，起于垒土，当我们享受云端似乎取之不尽用之不竭的计算资源时，如果能剥开一层层的封装，洞悉计算的本质，也许我们会更加珍惜云端的计算资源，更加赞叹虚拟化技术大厦的宏伟与精致，也更加崇敬和膜拜那些引领人类走进云时代的计算机大师。