虚拟化技术发展编年史

前言

我已经想不起来是从什么时候开始的，突然就对计算机历史产生了浓厚的兴趣。于是我想着，要不以后所有系列文章的开篇都先和大家聊聊历史吧。其实说来挺有意思，看过去到底是为了看未来，因为历史总是惊人的相似，几乎所有的问题都能够在历史长河中寻得答案。可惜的是，但凡历史，最是难写，笔者碍于能力有限，还望大家多指点一二。

什么是虚拟化？

在计算机科学中，虚拟化技术（Virtualization）是一种资源管理（优化）技术，将计算机的各种物理资源（e.g. CPU、内存以及磁盘空间、网络适配器等 I/O 设备）予以抽象、转换，然后呈现出来的一个可供分割并任意组合为一个或多个（虚拟）计算机的配置环境。虚拟化技术打破了计算机内部实体结构间不可切割的障碍，使用户能够以比原本更好的配置方式来应用这些计算机硬件资源。而这些资源的虚拟形式将不受现有架设方式，地域或物理配置所限制。虚拟化技术是一个广义的术语，根据不同的对象类型可以细分为：

虚拟化技术发展编年史

开篇

1959 年 6 月，牛津大学的计算机教授，克里斯·托弗（Christopher Strachey）在国际信息处理大会（International Conference on Information Processing）上发表了一篇名为《大型高速计算机中的时间共享》（Time Sharing in Large Fast Computer）的学术报告，他在文中首次提出了 “虚拟化” 的基本概念，还论述了什么是虚拟化技术。这篇文章被认为是最早的虚拟化技术论述，从此拉开了虚拟化发展的帷幕。

克里斯·托弗还同时提出了 Multi-Processing（多道程序）这一超前的概念。Multi-Processing 解决了应用程序因等待外部设备而导致处理器空转问题，同时也解决了用户如何调试（Debug）代码的问题。即便在现在看来，多道程序的理念仍是操作系统在 “并发” 领域中的隗宝。

Christopher Strachey

大型机和小型机的虚拟化

1960 年，为了应对物理学领域的计算需求，美国启动 Atlas 超级计算机（Super Computer）项目。同期的英国全国只有 16 台计算机，日不落帝国的诅咒在计算机领域也无法幸免。

1961 年，由麻省理工学院的 Fernando Corbato 教授带领团队开始研发 CTSS（Compatible Time Sharing System，兼容性分时系统）项目，并由 IBM 提供硬件设备和工程师进行支持。分时系统可以说是硬件虚拟化的根本，CTSS 为后来 IBM 的 TSS 打下了基础。

1962 年，第一台 Atlas 超级计算机 Atlas 1 诞生，Atlas 1 是第一台实现了虚拟内存（Virtual Memory）概念的计算机，并将其称为一级存储（one-level store）。Atlas 1 还是第一个实现了名为 Supervisor 的底层资源管理组件的计算机，Supervisor 可以通过特殊的指令或代码来管理物理主机的硬件资源。例如：中央处理器的时间分配。

没错，操作系统最早的称谓其实是 Supervisor，往后还被叫过一段时间的 Master Control Program（主控程序），但最终 Operating System 胜出了。此时你或许能够理解为什么虚拟机管理程序会被统称为 Hypervisor（Super、Hyper 是同意词，意为超级，但词义上 Hyper 比 Super 还要高级一些）。

1963 年使用打孔机的第一代 Atlas 超级计算机

1960 中期，IBM 在 Thomas J. Watson Research Center (NY) 进行 M44/44X 计算机研究项目。M44/44X 项目基于 IBM 7044（M44）实现了多个具有突破性的虚拟化概念，包括部分硬件共享（partial hardware sharing）、时间共享（time sharing）、内存分页（memory paging）以及实现了虚拟内存管理的 VMM。

通过这些虚拟化技术，应用程序可以运行在这些虚拟的内存之中，实现了在同一台主机上模拟出多个 7044 系统（44X）。M44/44X 项目首次使用了 VM（Virtual Machine） 和 VMM（Virtual Machine Monitor）一词，被认为是世界上第一个支持虚拟机的系统。

1964 年：IBM 推出了著名的 System/360。你或许有所耳闻，System/360 的开发过程被视为了计算机发展史上最大的一次豪赌，为了研发 System/360，IBM 决定征召六万多名新员工，创建了五座新工厂。即便如此，当时的出货时间仍被不断顺延。

吉恩·阿姆达尔是系统主架构师，当时的项目经理佛瑞德·布鲁克斯（Frederick P. Brooks, Jr.）事后根据这项计划的开发经验，写出了同样著名的《人月神话：软件项目管理之道》（The Mythical Man-Month: Essays on Software Engineering）记述人类工程史上一项里程碑式的大型复杂软件系统开发经验。

最终，IBM System/360 取得了巨大的商业成功。System/360 不仅提供了新型的操作系统（让单一操作系统适用于整个系列的产品，这是 System/360 系列大型机成功的关键），还实现了基于全硬件虚拟化（Full Hardware Virtualization）的虚拟机解决方案，包括：页式虚拟内存（4k 分页虚拟存储系统），虚拟磁盘以及 TSS 分时系统。System/360 最多可提供 14 个虚拟机，每个虚拟机具有 256k 固定虚拟内存。

这里有必要着重介绍一下 TSS （Time Sharing System，分时共享系统），它能够让一台主机上连接多个带有显示器和键盘的终端，同时允许多个用户通过主机的终端，以交互方式使用计算机，共享主机中的资源。分时操作系统本质是一个多用户交互式操作系统。

其中，“分时” 的含义是将 CPU 占用切分为多个极短（e.g. 1/100sec）的时间片，每个时间片都执行着不同的任务。通过对这些时间片的轮询，就可以将一个 CPU “伪装”（虚拟化）成多个 vCPU，并且让每颗 vCPU 看起来都是并行运行的。最终达到多个用户分享使用同一台计算机，多个程序分时共享硬件和软件资源的效果。TSS 被认为是最原始的虚拟化技术。

可见，最初虚拟化技术的应用和发展源于大型机对分时系统的需求。这种通过硬件的方式来生成多个可以运行独立操作系统软件的虚拟机实例，解决了早期大型计算机只能单任务处理而不能分时多任务处理的问题。由于这种虚拟化技术是基于硬件设备来实现的，故被称为硬件虚拟化（Hardware virtualization）。

但需要注意的是，这一说法在后来被进一步细分为了狭义的硬件虚拟化技术，现今更加为人多熟知的硬件虚拟化是指：一种对计算机或操作系统的虚拟化，能够对用户隐藏真实的计算机硬件，表现出另一个抽象的计算平台。

System/360

The Mythical Man-Month: Essays on Software Engineering

伟大源自于伟大！

1974 年，Gerald J. Popek（杰拉尔德·J·波佩克）和 Robert P. Goldberg（罗伯特·P·戈德堡）在合作论文《可虚拟第三代架构的规范化条件》（Formal Requirements for Virtualizable Third Generation Architectures）中提出了一组称为虚拟化准则的充分条件，又称波佩克与戈德堡虚拟化需求（Popek and Goldberg virtualization requirements）即：虚拟化系统结构的三个基本条件。满足这些条件的控制程序才可以被称为虚拟机监控器（Virtual Machine Monitor，简称 VMM）：

1、资源控制（Resource Control）。控制程序必须能够管理所有的系统资源。

2、等价性（Equivalence）。在控制程序管理下运行的程序（包括操作系统），除时序和资源可用性之外的行为应该与没有控制程序时的完全一致，且预先编写的特权指令可以自由地执行。

3、效率性（Efficiency）。绝大多数的客户机指令应该由主机硬件直接执行而无需控制程序的参与。

该论文尽管基于简化的假设，但上述条件仍为评判一个计算机体系结构是否能够有效支持虚拟化提供了一个便利方法，也为设计可虚拟化计算机架构给出了指导原则。同时，Gerald J. Popek 和 Robert P. Goldberg 还在论文中介绍了两种 Hypervisor 类型，分别是类型 I 和 类型 II。

类型 I（原生或裸机 Hypervisor）：这些虚拟机管理程序直接运行在宿主机的硬件上来控制硬件和管理客户机操作系统。

实现案例：

ps：这里我特意将类型 I 和 II 的顺序调转，至于为什么，从实现案例可以看出类型 I 已然是时代的选择。再一个，老实说我确实为这个事实感到震惊，平台虚拟化的雏形竟然在 1974 年就已经确立了的这个事实。

1979 年，Unix 的第 7 个版本引入了 chroot 机制，意味着第一个 操作系统虚拟化（OS-level virtualization） 诞生了。chroot 是直到现在我们依然在使用的一个系统调用，这个系统调用会让一个进程把指定的目录作为根目录，它的所有文件系统操作都只能在这个指定目录中进行，本质是一种文件系统层的隔离。

ps：操作系统虚拟化这个说法你或许会感到陌生，但容器（Container）你应该非常熟悉了。

在上世纪 60~80 年代，因为虚拟化技术使得大型机和小型机获得了空前的成功。并且在相当长的一段时间里，虚拟化技术只在大型机和小型机上得到了应用，而在 x86 平台上的应用仍然进展缓慢。不过也可以理解，以当时 x86 平台的处理能力，应付一两个应用程序已然捉襟见肘，还怎么能够将资源分给更多的虚拟应用呢？而后随着 x86 的流行，大型机和小型机在新兴的服务器市场中也逐渐失去了竞争力。

x86 架构的虚拟化

直到上世纪 80~90 年代，Intel 公司（戈登·摩尔）提出了摩尔定律，Windows、Mac 等 PC（Personal Computer）电脑被广泛使用，Wintel 联盟势如破竹，还出现了神一般的 Linux 服务器操作系统。种种原因，到底是 x86 赢得了时代的青睐，成为了服务器的行业标准。或许在那时 Intel 就已经开始思考为何 “生态” 这件事情了。

而解决这些难题就是新时代赋予虚拟化技术的历史任务，整个 80~90 年代，虚拟化技术及公司如同雨后春笋般涌现。

1987 年：Insignia Solutions 公司演示了一个称为 SoftPC 的软件模拟器，这个模拟器允许用户在 Unix Workstations 上运行 DOS 应用。当时一个可以运行 Microsoft DOS 的 PC 需要 1,500 美金，而使用 SoftPC 模拟，就可以直接在大型工作站上运行 Microsoft DOS 了。

1989 年，Insignia Solutions 发布了 Mac 版的 SoftPC，使苹果用户不仅能运行 DOS，还能运行 Windows 操作系统。

1990 年，Keir Fraser 和 Ian Pratt 创建了 XenServer 的初始代码工程（项目）。

1997 年，苹果开发了 Virtual PC，后来又卖给了 Connectix 公司。

1998 年，著名的 x86 仿真模拟器 Bochs 发布。

2001 年，VMWare 发布 ESX 和 GSX，是 ESXi 的前身。同年，Fabrice Bellard 也发布了目前最流行的，采用了动态二进制翻译（Binary Translation）技术的开源虚拟化软件 QEMU（Quick EMUlator）的第一个版本。

基于二进制翻译的全虚拟化

此时，虚拟化技术的共同目标就是将 x86 架构转变为通用的共享硬件基础架构，使应用程序运行环境在隔离性、移动性和操作系统类型方面都有选择的空间。首先了解一下 x86 架构的特点。

CPU 为了保证程序代码执行的安全性，多用户的独立性以及保证操作系统的稳定性，提出了 CPU 执行状态的概念。它有效的限制了不同程序之间的数据访问能力，避免了非法的内存数据操作，同时也避免了应用程序错误操作计算机的物理设备。一般的，CPU 都会划分为用户态和内核态，而 x86 CPU 更是细分为了 Ring 0~3 四种执行状态。

显然，只有操作系统能够无限制的访问内存、磁盘、鼠键等外围硬件设备的数据，因为操作系统就是作为计算机硬件资源管理器而存在的，操作系统就是为了让多个普通应用程序可以更简单、安全的运行在同一台计算机上而存在的 “特殊的应用程序”。

也很显然，所有的应用程序都应该运行在用户态中。当应用程序需要访问外围硬件设备时，CPU 会通过特别的接口去调用核心态的代码，以这种旁路的方式来应用程序对硬件设备的调用。如果用户态的应用程序直接调用硬件设备的话，就会被操作系统捕捉到并触发异常，弹出警告窗口。

可见，x86 架构与大型机不同，当时的 x86 体系结构缺乏必要的针对虚拟化的硬件支持，难以直接满足波佩克与戈德堡的虚拟化需求，所以 x86 架构天然不是一个可虚拟化的架构。x86 架构的 CPU 中有 17 条指令成为了虚拟化最大的障碍，错误执行这些指令会导致操作系统显示警告、终止应用程序甚至完全崩溃。

当时 VMware 提出了解决这个问题的思路：在虚拟机生成这些特殊的指令时将它们 “困住”，然后将它们转换成可虚拟化的安全指令，同时保证其他所有的指令不受到干扰地执行。这样就产生了一种与主机硬件匹配并保持软件完全兼容性的高性能虚拟机。

这就是 全虚拟化（Full virtualization） 技术诞生的背景 —— 必须使用纯软件实现的方式构造 VMM。VMware 首创了这项技术，一举稳坐虚拟化龙头老大。

全虚拟化是指虚拟机模拟了完整的底层硬件，包括处理器、物理内存、时钟、外设等，使得为原始硬件设计的操作系统或其它系统软件完全不做任何修改就可以在虚拟机中运行。

客户机操作系统（Guest OS）与真实硬件之间的交互可以看成是通过一个预先规定的硬件接口进行的。全虚拟化 VMM 以完整模拟硬件的方式提供全部接口（同时还必须模拟特权指令的执行过程）。

但并非所有的状态都需要恢复，例如主机 CR3 寄存器中存放的是 VMM 设置的页表物理地址，而不是 Guest OS 设置的值。pCPU 直接运行 Guest OS 的机器指令时，由于 Guest OS 运行在低特权级别（Ring 1），如果 Guest OS 直接访问 Host OS 的特权状态（如写 GDT 寄存器），就会因为权限不足导致 pCPU 产生异常，然后将运行权主动交还给 VMM。

此外，外部中断的到来也会影响 VMM 的运行。VMM 可能需要先将该虚拟机的当前状态写回到状态数据结构中，分析虚拟机被挂起的原因，然后代表 Guest OS 执行相应的特权操作。最简单的情况，如 Guest OS 对 CR3 寄存器的修改，只需要更新虚拟机的状态数据结构即可。

一般而言，大部分情况下，VMM 需要经过复杂的流程才能完成原本简单的操作。最后 VMM 将运行权还给 Guest OS，Guest OS 从上次被中断的地方继续执行，或处理 VMM “塞”入的虚拟中断和异常。这种经典的虚拟机运行方式被称为 Trap-And-Emulate（捕获-模拟），虚拟机对于 Guest OS 完全透明，Guest OS 不需要任何修改，但是 VMM 的设计会比较复杂，系统整体性能受到明显的损害。

而全虚拟化 VMM 就必须要完整地模拟该接口执行的全过程。如果硬件（主要是 CPU）不提供虚拟化的特殊支持的话，那么这个模拟过程将会十分复杂：一般而言，VMM 必须运行在最高优先级来完全控制宿主机操作系统（Host OS），而 Guest OS 需要降级运行，从而不能执行特权操作。

当 Guest OS 执行前面的特权汇编指令时，Host OS 产生异常（General Protection Exception），执行控制权重新从 Guest OS 转到 VMM 手中。VMM 事先分配一个变量作为影子 CR3 寄存器给 Guest OS，将 pgtable（页表）代表的 Guest OS 物理地址（Guest Physical Address）填入影子 CR3 寄存器，然后 VMM 还需要 pgtable 翻译成主机物理地址（Host Physical Address）并填入物理 CR3 寄存器，最后返回到 Guest OS中。随后 VMM 还将处理复杂的 Guest OS 缺页异常（Page Fault）。

简单来说就是全虚拟化需要在 VMM 中模拟出一颗包含了控制单元、运算单元、存储单元、IS（指令集）的 CPU；此外，还需要模拟一张进行虚拟存储地址和物理存储地址转换的页表；此外，还需要在 VMM 模拟磁盘设备控制器、网络适配器等等各种 I/O 外设接口。

如此依赖，Guest OS 就不知道自己其实是个虚拟机了呀，它收到了欺骗。可以想象得到，全虚拟化这种处理器密集型的虚拟化技术实现是异常困难且低效的。比较著名的全虚拟化 VMM 有 Microsoft Virtual PC、VMware Workstation、Sun Virtual Box、Parallels Desktop for Mac 和 QEMU。

QEMU 在今年（2019）对外宣称可以模拟所有设备，天啊，这简直是个奇迹般的伟大软件。但基于这样的前提，全虚拟化 VMM 必须要克服许多难以解决的问题。例如：

显然，基于 Trap-And-Emulate 处理方式的全虚拟化虽能够以纯软件的方式完成虚拟化并解决了许多问题，但同时也带来了极大的设计复杂性和性能下降。而对于这两个问题，半虚拟化（Partial virtualization） 想到了一个好办法：改造 Guest OS，将 Guest OS 原来所有需要被 VMM 截获、模拟的指令和操作全部改造成与 VMM 协同工作的指令（hypercall）和操作。VMM 不再隐瞒了，因为你（Guest OS）已经知道自己就是个虚拟机了。其核心思想是：动态或静态地改变 Guest OS 对特权状态访问的操作，尽量减少产生不必要的硬件异常，同时简化 VMM 的设计。

半虚拟化

半虚拟化是一种通过修改 Guest OS 部分访问特权状态的代码以便直接与 VMM 交互的技术。在半虚拟化虚拟机中，部分硬件接口以软件的形式提供给 Guest OS，这可以通过 Hypercall（VMM 提供给 Guest OS 的直接调用，与系统调用类似）的方式来提供。

例如，Guest OS 把切换页表的代码修改为调用 Hypercall 来直接完成修改影子 CR3 寄存器和翻译地址的工作。由于不需要产生额外的异常和模拟部分硬件执行流程，半虚拟化可以大幅度提高性能，比较著名的 VMM 有 Denali、Xen。

相较于全虚拟化，半虚拟化 VMM 只需要模拟部分底层硬件，因此 Guest OS 不做修改是无法在虚拟机中运行的，甚至运行在虚拟机中的其它程序也需要进行修改，如此代价，换来的就是接近于物理机的虚拟机性能。

有意思的是，半虚拟化其实也很尴尬，对于 Linux 而言自然是改了就改了，但 Windows 你要怎么改？人家可是闭源的。写到这里，不禁会想起自己写过的代码，拆东墙补西墙可不值得提倡，要从根源上解决问题。而这个根源自然就是 —— CPU。

既然全虚拟化性能低的主要原因是花费了太多的精力去捕获 CPU 异常并模拟 CPU 行为，那么如果 CPU 本身就为 VMM 提供了便利，那岂不是从根本上解决了这个问题？这就是 硬件辅助虚拟化（Hardware-assisted virtualization） 。

基于硬件辅助的全虚拟化

Intel-VT（Intel Virtualization Technology）和 AMD-V 是目前 x86 平台上可用的两种硬件辅助虚拟化技术。VT-x 为 IA 32 处理器增加了两种操作模式：VMX root operation 和 VMX non-root operation。VMM 自己运行在 VMX root operation 模式，VMX non-root operation 模式则由 Guest OS 使用。两种操作模式都支持 Ring 0~3 这 4 个特权级，因此 VMM 和 Guest OS 都可以自由选择它们所期望的运行级别。

这两种操作模式可以互相转换。运行在 VMX root operation 模式下的 VMM 通过显式调用 VMLAUNCH 或 VMRESUME 指令切换到 VMX non-root operation 模式，硬件自动加载 Guest OS 的上下文，于是 Guest OS 获得运行，这种转换称为 VM entry。

Guest OS 运行过程中遇到需要 VMM 处理的事件，例如外部中断或缺页异常，或者主动调用 VMCALL 指令调用 VMM 的服务的时候（与系统调用类似），硬件自动挂起 Guest OS，切换到 VMX root operation 模式，恢复 VMM 的运行，这种转换称为 VM exit。

VMX root operation 模式下软件的行为与在没有 VT-x 技术的处理器上的行为基本一致；而 VMX non-root operation 模式则有很大不同，最主要的区别是此时运行某些指令或遇到某些事件时，发生 VM exit。

又因为 VMM 和 Guest OS 共享底层的处理器资源，所以硬件需要一个物理内存区域来自动保存或恢复彼此执行的上下文。这个区域称为虚拟机控制块（VMCS），包括客户机状态区（Guest State Area），主机状态区（Host State Area）和执行控制区。

VM entry 时，硬件自动从客户机状态区加载 Guest OS 的上下文。并不需要保存 VMM 的上下文，原因与中断处理程序类似，因为 VMM 如果开始运行，就不会受到 Guest OS的干扰，只有 VMM 将工作彻底处理完毕才可能自行切换到 Guest OS。

而 VMM 的下次运行必然是处理一个新的事件，因此每次 VMM entry 时， VMM 都从一个通用事件处理函数开始执行；VM exit 时，硬件自动将 Guest OS 的上下文保存在客户机状态区，从主机状态区中加载 VMM 的通用事件处理函数的地址，VMM 开始执行。而执行控制区存放的则是可以操控 VM entry 和 exit 的标志位，例如标记哪些事件可以导致 VM exit，VM entry 时准备自动给 Guest OS “塞” 入哪种中断等等。

客户机状态区和主机状态区都应该包含部分物理寄存器的信息，例如控制寄存器 CR0，CR3，CR4；ESP 和 EIP（如果处理器支持 64 位扩展，则为 RSP，RIP）；CS，SS，DS，ES，FS，GS 等段寄存器及其描述项；TR，GDTR，IDTR 寄存器；IA32_SYSENTER_CS，IA32_SYSENTER_ESP，IA32_SYSENTER_EIP 和 IA32_PERF_GLOBAL_CTRL 等 MSR 寄存器。

客户机状态区并不包括通用寄存器的内容，VMM 自行决定是否在 VM exit 的时候保存它们，从而提高了系统性能。客户机状态区还包括非物理寄存器的内容，比如一个 32 位的 Active State 值表明 Guest OS 执行时处理器所处的活跃状态，如果正常执行指令就是处于 Active 状态，如果触发了三重故障（Triple Fault）或其它严重错误就处于 Shutdown 状态，等等。

执行控制区用于存放可以操控 VM entry 和 VM exit 的标志位，包括：

VMCS 还包括一组位图以提供更好的适应性：

每次发生 VM exi t时，硬件自动在 VMCS 中存入丰富的信息，方便 VMM 甄别事件的种类和原因。VM entry 时，VMM 可以方便地为 Guest OS 注入事件（中断和异常），因为 VMCS 中存有 Guest OS 的中断描述表（IDT）的地址，因此硬件能够自动地调用 Guest OS 的处理程序。

传统的全虚拟化实现在有了硬件的辅助之后，由于 CPU 引入了新的操作模式，VMM 和 Guest OS 的执行由硬件自动隔离开来，任何关键的事件都可以将系统控制权自动转移到 VMM，因此 VMM 能够完全控制系统的全部资源。Guest OS 也可以运行在它所期望的最高特权级别，因此特权级压缩和特权级别名的问题迎刃而解，而且 Guest OS 中的系统调用也不会触发 VM exit。

硬件使用物理地址访问虚拟机控制块（VMCS），而 VMCS 保存了 VMM 和 Guest OS 各自的 IDTR 和 CR3 寄存器，因此 VMM 可以拥有独立的地址空间，Guest OS 能够完全控制自己的地址空间，地址空间压缩的问题也不存在了。中断和异常虚拟化的问题也得到了很好的解决。VMM 只用简单地设置需要转发的虚拟中断或异常，在 VM entry 时，硬件自动调用 Guest OS 的中断和异常处理程序，大大简化 VMM 的设计。

同时，Guest OS 对中断的屏蔽及解除可以不触发 VM exit，从而提高了性能。而且 VMM 还可以设置当 Guest OS 解除中断屏蔽时触发 VM exit，因此能够及时地转发积累的虚拟中断和异常。另外，纯软件实现的 VMM 目前缺少对 64 位客户操作系统的支持，而 CPU 的虚拟化技术除支持广泛的传统操作系统类型之外，还支持 64 位客户操作系统。硬件辅助虚拟技术提高了虚拟机的性能以及兼容性。

需要注意的是，上文中我们提到了全虚拟化、半虚拟化和硬件辅助的全虚拟化，但这种分类实际上并不绝对，一个优秀的 VMM 往往融合了多项技术。例如 VMware Workstation 是一个著名的全虚拟化的 VMM，但是它使用了一种被称为动态二进制翻译（Binary Translation）的技术把对特权状态的访问转换成对影子状态的操作，从而避免了低效的 Trap-And-Emulate 的处理方式，这与半虚拟化相似，只不过半虚拟化是静态地修改程序代码。

看得出硬件辅助虚拟化技术必然是未来的方向，Intel-VT 的处理器级虚拟化技术还需要进行以下优化：

2004 年，微软发布 Virtual Server 2005 计划，象征着虚拟化技术正式进入主流市场。

2005 年，OpenVZ 发布，这是 Linux 操作系统的容器化技术实现，同时也是 LXC 的核心实现。

2006 年，Intel 和 AMD 等厂商相继将对虚拟化技术的支持加入到 x86 体系结构的中央处理器中（AMD-V，Intel VT-x），使原来纯软件实现的各项功能可以用借助硬件的力量实现提速。

同年，红帽将 Xen 作为 RHEL 的默认特性。同年，Amazon Web Services（AWS）开始以 Web 服务的形式向企业提供 IT 基础设施服务，现在通常称为云计算。

2007 年 1 月，Sun 公司发布了开源虚拟化软件 VirtualBox。同年 Xen 被 Citrix（思杰）收购。

2008 年 9 月 4 日，Red Hat 收购以色列公司 Qumranet，并着手使用 KVM 替换在 Red Hat 中的使用的 Xen。

2009 年 9 月，红帽发布 RHEL 5.4，在原先的 Xen 虚拟化机制之上，将 KVM 添加了进来。同年，阿里云写下第一行代码。

2010年11月，红帽发布 RHEL 6.0，这个版本将默认安装的 Xen 虚拟化机制彻底去除，仅提供 KVM 虚拟化机制。

当年，Xen 虽然作为一项广泛应用于 Linux 发行版中的虚拟化技术，但却迟迟没有集成到 Linux 内核中，红帽也许是出于对这种脱离内核的维护方式感到不爽，加之当时思杰和微软表现的很非常亲密，导致红帽萌生了放弃 Xen 的想法，并在正式采用 KVM 的一年后，就宣布彻底放弃 Xen。硬件辅助虚拟化的到来，Xen 引以为傲的半虚拟化技术也随之在主流 Linux 发行厂商中衰落了。

2010 年 10 月 21 日，NASA 发布了可以 IaaS（基础设施即服务）云操作系统 OpenStack，第一个版本便是众所周知 Austin（奥斯丁）。OpenStack 挽手自主可控的口号，推动了云计算在国内的全面爆发。

2011 年初，IBM 找上老搭档红帽，表示 KVM 这个东西值得加大力度去做。于是到了 5 月，IBM 和红帽，联合惠普和英特尔一起，成立了开放虚拟化联盟（Open Virtualization Alliance），加速 KVM 投入市场的速度，由此避免 VMware 一家独大的情况出现。联盟成立之时，红帽的发言人表示：“大家都希望除 VMware 之外还有一种开源选择。未来的云基础设施一定会基于开源。我们想要营造一个小厂商们可以轻松加入的生态环境。”

ps：现在回头再看，企业之所以能够长盛不衰，长远的洞察力至关重要。

操作系统虚拟化（容器）

2013 年 3 月 15 日，在加利福尼亚州圣克拉拉召开的 Python 开发者大会上，DotCloud 的创始人兼首席执行官 Solomon Hvkes 在一场仅五分钟的微型演讲中，首次提出了 Docker 这一概念，并于会后将其源码开源并托管到 Github。最初的 Docker 就是使用了 LXC 再封装了其他的一些功能。可以看出，Docker 的成功，与其说是技术的创新，还不如说是一次组合式的创新。

2014 年 6 月，Docker 发布了第一个正式版本 v1.0。同年，Redhat 和 AWS 就宣布了为 Docker 提供官方支持。

在传统操作系统中，所有用户的进程本质上是在同一个操作系统的实例中运行，因此内核或应用程序的缺陷可能影响到其它进程。操作系统虚拟化（OS-level virtualization） 是一种在服务器操作系统中使用的、没有 VMM 层的轻量级虚拟化技术，内核通过创建多个虚拟的操作系统实例（内核和库）来隔离不同的进程（容器），不同实例中的进程完全不了解对方的存在。

操作系统虚拟化看似与上述提到过的几种硬件虚拟化方式一样，都是产生多个操作系统，但操作系统虚拟化与硬件虚拟化之间还是有很多不同之处，其中最核心的区别就是：操作系统虚拟化是操作系统的虚拟化，而硬件虚拟化是计算机的虚拟化。前者隔离操作系统资源，而后者隔离计算机硬件资源。

ps：容器技术之所以火热，是因为容器隔离性封装的特性，为运维能力引入了 “可编程性”，开发人员借助容器得以 Software Define Operation。

2015 年 7 月 21 日：Kubernetes v1.0 发布！进入云原生时代。

最后

对于篇幅较长的文章，我都习惯使用三句话来进行总结：

参考文档

https://www.ibm.com/developerworks/cn/linux/l-cn-vt/index.html

作者：范桂飓，九州云（99Cloud）OpenStack 研发工程师，曾先后服务于 Windows Azure、Redhat OpenStack 与 Prophetech HyperMotion。云物互联公号主，现专注于探索云计算、边缘计算、SDN 与物联网的深度结合应用场景。

声明：本文首发于作者的 CSDN 博客，已获作者授权，

原文： https://blog.csdn.net/Jmilk/article/details/99675664。