除了 KVM，其它的虚拟化产品基本几乎都是类似的架构。

KVM 模块中，实现虚拟化功能的是 kvm.ko，还包括一个和处理器强相关的模块如 kvm-intel.ko 或 kvm-amd.ko，KVM 本身不能实现任何模拟功能，它仅仅是提供了一个/dev/kvm 接口，这个接口可被宿主机用来主要负责 vCPU 的创建、虚拟内存的地址空间分配、vCPU 寄存 器的读写以及 vCPU 的运行。所以 kvm.ko 只提供了 CPU 和内存的虚拟化，但是一个虚拟机除 了 CPU 和内存外，还需要网卡、硬盘等其它的 IO 设备，这时候就需要另外一个组件——

QEMU 了，KVM 核心模块和 QEMU 在一起才能构成一个完整的虚拟化技术。

 

其实 QEMU 原本不是 KVM 的一部分，它是一个通用的开源的使用纯软件来实现的虚拟 化的模拟器，Guest OS 以为自己在和硬件进行交互，其实真正交互的是 QEMU，然后在通过 QEMU 去和硬件交互，这就意味着所有的和硬件交互都需要经过 QEMU，所以使用 QEMU 进 行模拟的性能比较低。QMEU 本身可以模拟 CPU 和内存，在 KVM 中，只使用 QEMU 来模拟 IO 设备，KVM 的开发者将其进行了改造，形成了 QEMU-KVM。

在 QEMU-KVM 中，KVM 运行在内核空间，QEMU 运行在用户空间，Guest OS 下发指令 的时候，和 CPU 和内存相关的指令会通过 QEMU-KVM 中的/ioctl 调用 /dev/kvm，从而将这 部分指令的部分交给内核模块来做，从 QEMU 的角度来看，这样做也可以提高虚拟化加速。其 它的 IO 操作则由 QEMU-KVM 中的 QEMU 部分实现，KVM 加上 QEMU 后就是完整意义上的 虚拟化。

除了进行各种设备的虚拟化外，QEMU-KVM 还提供了原生的工具可以对虚拟机进行创建、 修改和删除等管理，然而，Libvirt 是目前使用最为广泛的对 KVM 虚拟机进行管理的工具和 API。

Libvirt 也是一个开源项目，它是一个非常强大的管理工具，被管理的虚拟化平台可以是 KVM，也可以是 Xen 或者 VMware 以及 Hyper-V 等等。Libvirt 是一台由 C 语言开发的 API， 其它的语言，比如 Java、Python、Perl 等，可以通过调用 Libvirt 的 API 去管理各个虚拟化平 台。Libvirt 被很多的应用用到，除了自己本身的 virsh 命令集外，Virt-manager、Virt- viewer、Virt-install 都可以通过 Libvirt 管理 KVM 虚拟机。

 

 

在讲 CPU 虚拟化前，我们先简单介绍一下 CPU 的分级保护域，在这种保护模式中，CPU 被分成 4 个环——Ring0、Ring1、Ring2 和 Ring3，Ring0 的权限最高，Ring1 次之，Ring2 再次之，Ring3 最低。Ring0 的权限可以直接操作硬件，一般只有操作系统和驱动会允许拥有此 权限。Ring3 的权限最低，所有的程序都可以拥有此权限。为了保护计算机，一些危险的指令只 能由操作系统执行，防止一些恶意软件随意地调用硬件资源，比如某个程序需要开启摄像头就必须向 Ring0 的驱动程序请求开启，否则会被拒绝此类操作。

在虚拟化环境下，还有一种特殊指令被称为敏感指令。敏感指令是指修改虚拟机的运行模式或宿主机状态的指令，也就是说是将 Guest OS 中原本需要在 Ring 0 模式下才能运行的特权指 令剥夺特权后，交给 VMM 所执行的指令。

虚拟化技术首先出现在 IBM 大型机上，大型机如何解决 CPU 共享问题的呢？首先我们先了 解一下大型机的 CPU 虚拟化方式。大型机 CPU 虚拟化采取的是“特权解除(Privilege deprivileging)”和“陷入模拟(Trap-and-Emulation)”方法，这种方法也被称为经典虚拟化方 式。它的基本原理是，将 Guest OS 运行在非特权级（即特权解除），而将 VMM 运行于最高特 权级（即完全控制系统资源）。

这个时候就出现了一个问题：如果虚拟机 Guest OS 发出特权操作指令怎么执行呢？因为所有虚拟机的系统都被解除了特权，于是“陷入模拟”就发挥作用了，它解除了 Guest OS 的特权后，Guest OS 的大部分指令仍可以在硬件上直接运行，只有当执行到特权指令时，才会陷入到 VMM 模拟执行（陷入－模拟）。由 VMM 代替虚拟机向真正的硬件 CPU 发出特权操作指 令。

CPU 虚拟化经典方法结合原始操作系统具有的定时器中断机制，就完美解决了 CPU 虚拟化 的问题。如虚拟机 1 发送特权指令 1 到虚拟机监视器 VMM，此时触发中断，虚拟机监视器 VMM 会对虚拟机 1 发送的特权指令 1 陷入到虚拟机监视器 VMM 中进行模拟，再转换成 CPU 的特权指令 1’，虚拟机监视器 VMM 根据调度机制调度到硬件 CPU 上执行，并返回结果给 VM1，如下左图。当虚拟机 1 和虚拟机 2 同时发送特权指令到虚拟机监视器 VMM 时，指令 都被陷入模拟，虚拟机监视器 VMM 调度机制进行统一调度。首先执行指令 1’，然后再执行指 令 2’如下右图 。于是采用定时器中断机制以及特权解除—陷入模拟这些方法成功实现了 CPU 的虚拟化功能。

--------------------------------------------------------------------------------------

 

 

 那为什么需要中断机制呢？CPU 在程序运行中系统外部、系统内部或者现行程序本身若出 现紧急事件，CPU 立即中止现行程序的运行，自动转入相应的处理程序（中断服务程序），待处 理完后，再返回原来的程序运行，这整个过程称为程序中断。例如你正在看视频时，QQ 突然有 信息弹出，在整个过程中就会触发中断机制。CPU 就会暂停视频播放进程，而专区执行 QQ 进 程。CPU 在处理完成 QQ 进程操作后，继续执行视频播放进程。当然，这个中断时间非常短 暂，用户是无感知的。

随着 x86 主机性能越来越强大，如何将虚拟化技术应用到 x86 架构成为实现 x86 服务器虚 拟化的主要问题。这个时候，人们自然而然想到曾经使用到大型机上的 CPU 虚拟化技术。那么 大型机 CPU 虚拟化所使用的经典虚拟化方法能否移植到 x86 服务器上呢？这个问题答案却是否 定的。这又是为什么呢？要回答这个问题，我们就需要了解 x86 架构的 CPU 和大型机 CPU 的 不同之处。

大型机（包括后来发展的小型机）是 PowerPC 架构，即精简指令集 RISC 计算机架构。 RISC 架构的 CPU 指令集中，虚拟机特有的敏感指令是完全包括在特权指令中的，如下右图所 示。在虚拟机操作系统解除特权后，特权指令和敏感指令都可被正常陷入-模拟并执行，因为特 权指令包含敏感指令，所以 RISC 架构的 CPU 采用特权解除和陷入模拟是没有问题的。但是 x86 架构的 CPU 指令集是不同于 RISC 架构的 CISC 架构，如下图所示。

     |       

 

 

 在上图中可以看到 CISC 架构的 CPU 指令集的特权指令和敏感指令并不完全重合，具体来 说，基于 x86 的 CISC 指令集有 19 条敏感指令不属于特权指令的范畴，这部分敏感指令运行在 CPU 的 Ring 1 用户态上。这会带来什么问题呢？显然，当虚拟机发出这 19 条敏感指令时，由 于指令不属于特权指令，因而这些敏感指令不能陷入-模拟被虚拟机监视器（VMM）捕获，因此 x86 无法使用“解除特权”“陷入-模拟”经典的虚拟化技术方式实现 X86 架构的虚拟化。这样的 问题被称为虚拟化漏洞问题。既然基于大型机的 CPU 虚拟化方案无法直接移植到 x86 平台上， 那么 x86 应该采用什么方式实现 CPU 虚拟化呢？

聪明的 IT 架构师想出了解决这个问题的方法，而且还是三种方法。它们分别是：全虚拟 化、半虚拟化以及硬件厂商提出的硬件辅助虚拟化。

 

---

 

    |    

                   半虚拟化示意图                                                                        全虚拟化示意图

CPU半虚拟化解决方案

虚拟化漏洞的问题来源于 19 条敏感指令，如果我们可以修改虚拟机操作系统 Guest OS 规 避虚拟化漏洞，则问题就容易解决了。

修改虚拟机操作系统 Guest OS，让虚拟机系统 Guest OS 能够意识到自己是被虚拟化的， 虚拟机操作系统会通过“超级调用”（Hypercall）用 Hypervisor 层来替换虚拟化中的敏感指 令，从而实现虚拟化，而其它应用程序等非敏感或特权请求直接在 CPU 非特权级别上执行。半 虚拟化如上图二所示。半虚拟化所具有的优点是：半虚拟化中的 Guest OS 可以同时能支持多个 不同的操作系统.，虚拟化提供了与原始系统相近的性能。但缺点是：半虚拟化中的 Host OS 只 有针对开源的系统才能支持被修改，如 Linux，而对于未开源的诸如 Windows 系统，则无法实 现半虚拟化。此外，被修改过的虚拟机操作系统 Guest OS 可移植性较差。

幸运的是，目前主流的 x86 主机的 CPU 都支持硬件虚拟化技术，即 Intel 推出 VT-x 的 CPU，AMD 也推出了 AMD-V 的 CPU。Intel Virtualization Technology（VT-x）和 AMD 的 AMD-V，这两种技术都为 CPU 增加了新的执行模式 root 模式，可以让虚拟化监视器 VMM 运 行在 root 模式下，而 root 模式位于 CPU 指令级别 Ring 0 的下面。特权和敏感指令自动在 Hypervisor 上执行，从而无需全虚拟或半虚拟化技术。这种通过硬件辅助虚拟化解决虚拟化漏 洞，简化 VMM 软件，消除了半虚拟化和二进制翻译的方法，被称为 CPU 的硬件辅助虚拟化技术。但是需要在bios里把inter vt-x特性打开，不打开则不支持虚拟化特性。硬件辅助虚拟化技术如下图所示。

硬件辅助虚拟化

 

---

---

• 内存地址都是从物理地址 0 开始的

• 内存地址空间都是连续分配的 但引入虚拟化后显然就出现了问题：首先是要求内存地址空间都从物理地址 0 开始，显然物理地址为 0 的内存地址空间只有一个，无法同时满足所有虚拟机内存使用都要从 0 开始的要求；

其次，地址连续分配问题。即使可以为虚拟机分配连续的物理地址，但是内存使用效率不高，缺 乏灵活性。

解决内存共享问题的思路就在于引入内存虚拟化技术。内存虚拟化就是把物理机的真实物理 内存统一管理，包装成多份虚拟的内存给若干虚拟机使用。内存虚拟化技术的核心在于引入一层 新的地址空间——客户机物理地址空间，客户机（Guest）以为自己运行在真实的物理地址空间 中，实际上它是通过 VMM 访问真实的物理地址的，在 VMM 中保存客户机地址空间和物理机 地址空间之间的映射表，如下图所示。

 

 

 内存虚拟化的内存地址转换涉及到三种内存地址，即虚拟机内存地址（Virtual Memory Address，即 VA）、物理内存地址（Physical Memory Address，即 PA）和机器内存地址（Machine Memory Address，即 MA）。为了在物理主机上能够运行多个虚拟机，需要实现VA（虚拟内存）→PA（物理内存）→MA（机器内存）直接的地址转换。虚拟机 Guest OS 控 制虚拟地址到客户内存物理地址的映射 （VA→PA），但是虚拟机 Guest OS 不能直接访问实际 机器内存，因此  Hypervisor  需要负责映射客户物理内存到实际机器内存（PA→MA）。

注：这个地方可能有人要问 MA 和 PA 的区别，比如一台服务器一共有 16 根 16G 的内存 条，那么它的 PA 为 256G，而 MA 为 16 根分布在不同内存槽位的内存条。

 

---

内存全虚拟化

通过使用影子页表（Shadow Page Table）实现虚拟化。VMM为每个Guest都维护一个影子页表，影子页表维护虚拟地址（VA）到机器地址（MA）的映射关系。而Guest页表维护VA到客户机物理地址（GPA）的映射关系。当VMM捕获到Guest页表的修改后，VMM会查找负责GPA到MA映射的P2M页表或者哈希函数，找到与该GPA对应的MA，再将MA填充到真正在硬件上起作用的影子页表，从而形成VA到MA的映射关系。而Guest的页表则无需变动。如下图所示。

 

 

内存半虚拟化

通过使用页表写入法实现虚拟化。Guest OS在创建一个新的页表时，会向VMM注册该页表。之后在Guest运行的时候，VMM将不断地管理和维护这个表，使Guest上面的程序能直接访问到合适的地址。

内存硬件辅助虚拟化

通过扩展页表EPT（Extended Page Table）实现虚拟化。EPT通过使用硬件技术，使其能在原有的页表的基础上，增加一个EPT页表，用于记录GPA到MA的映射关系。VMM预先把EPT页表设置到CPU中。Guest修改Guest页表，无需VMM干预。地址转换时，CPU自动查找两张页表完成Guest虚拟地址到机器地址的转换，从而降低整个内存虚拟化所需的开销。如下图所示。

 

---

---

 

I/O 虚拟化

由于计算虚拟化的出现，物理服务器上会创建出许许多多的虚拟机，并且每台虚拟机都需要 访问物理主机的 IO 设备。但 I/O 设备的数量毕竟是有限的，为了满足多个虚拟机共同使用 I/O 设备的需求，就需要虚拟化监视器 VMM 参与。VMM 用于截获虚拟机对 I/O 设备的访问请求， 再通过软件去模拟真实的 I/O 设备，进而响应 I/O 请求。从而让多个虚拟机访问有限的 I/O 资 源。实现 I/O 虚拟化的方式主要有三种：全虚拟化、半虚拟化和硬件辅助虚拟化，其中硬件辅助虚拟化技术是目前 I/O 虚拟化的主流技术。

IO全虚拟化

全虚拟化的实现原理是，通过 VMM 为虚拟机模拟出一个与真实设备类似 的虚拟 I/O 设备，当虚拟机对 I/O 设备发起 I/O 请求时，VMM 截获虚拟机下发的 I/O 访问请 求，再由 VMM 将真实的访问请求发送到物理设备进行处理。这种虚拟化方式的优点在于：虚拟 机无论使用任何类型的操作系统，操作系统都不需要为 I/O 虚拟化做任何修改，就可以让多个虚 拟机直接使用物理服务器的 I/O 设备。但这种方式的缺陷也在于，VMM 需要实时截获每个虚拟 机下发的 I/O 请求，截获请求后模拟到真实的 I/O 设备中。实时监控和模拟的操作都是通过CPU 运行软件程序来实现的，因此会对服务器带来较严重的性能损耗。

Xen 架构示意图

 

前面我们说过，QEMU 是一个软件实现 IO 虚拟化的模拟工具，性能较差，例如，如果使用 QEMU 模拟一个 Windows 虚拟机的网卡，我们在系统上看到的该网卡的速率仅为 100M，有 时候一些应用对网卡速率有要求时，就不能再使用 QEMU 了，我们需要引入一个新的技术，它 就是 Virtio，是用了 Virtio，同样是网卡，在 Windows 虚拟化上，该网卡的速率可以提升到 10G。

我们先了解一下，如果没有 Virtio 时，虚拟机磁盘操作如何实现：

默认 I/O 操作流程

5 、QEMU 对该请求进行模拟，同时根据 I/O 操作请求的信息调用运行在内核态的设备驱动，去进行真正的 IO 操作；

6 、通过设备驱动去对物理硬件执行真正的 IO 操作；

7 、QEMU 将执行后的结果返回到共享页中，同时通知 KVM 模块已完成了此次的 I/O 操作；

8 、I/O 捕获程序从共享页中将返回的结果读取出来；

9 、I/O 捕获程序将操作结果返回给虚拟机；

10、虚拟机的将结果返回给发起操作的应用程序。

注：注意第 2、3、7 步，其实 KVM 除了捕获和通知，并没有对 I/O 操作做任何的修改，既 然什么都内有修改，那么我们都能不能把这一步去掉呢，所以就开发出了新的 virtio 技术。如果使用 Virtio 的时候，具体的操作流程如下：

Virtio 下 I/O 操作流程

4 、后端驱动直接调用真实的物理设备驱动进行具体的 I/O 操作；

5 、由真实的设备驱动完成此次操作；

6 、QEMU 将完成结果返回到环形缓冲区，并且由 KVM 模块通知前端驱动；

7 、前端驱动从环形缓冲区获取到此次 I/O 操作的结果；

8 、前端驱动将结果返回给具体发起该操作的应用程序。 通过对以上具体流程的介绍，我们可以得出使用 Virtio 的优点：

• 节省 QEMU 模拟时所需的硬件资源；

• 减少 I/O 请求的路径，提高了虚拟化设备的性能。

 

Virtio 也存在着一些缺点，有些比较老的或者不常用的设备，无法使用，只能使用 QEMU 方式进行模拟。

所以我们现在的虚拟化一般都叫QEMU-KVM，即QEMU实现IO虚拟化，KVM实现CPU和内存的虚拟化。

 

 

 

 

 

 

• 还没有人评论，欢迎说说您的想法！