6. VMM的分类

1. 概述

最理想的虚拟化的两个目标如下:

1)客户机完全不知道自己运行在虚拟化环境中,还以为自己运行在原生环境里。

2)完全不需要VMM介入客户机的运行过程。

1.2.2 软件虚拟化和硬件虚拟化

1.软件虚拟化技术

软件虚拟化,顾名思义,就是通过软件模拟来实现VMM层,通过纯软件的环境来模拟执行客户机里的指令。

最纯粹的软件虚拟化实现当属QEMU。在没有启用硬件虚拟化辅助的时候,它通过软件的二进制翻译仿真出目标平台呈现给客户机,客户机的每一条目标平台指令都会被QEMU截取,并翻译成宿主机平台的指令,然后交给实际的物理平台执行。由于每一条都需要这么操作一下,其虚拟化性能是比较差的,同时其软件复杂度也大大增加。但好处是可以呈现各种平台给客户机,只要其二进制翻译支持。

2.硬件虚拟化技术

硬件虚拟化技术就是指计算机硬件本身提供能力让客户机指令独立执行,而不需要(严格来说是不完全需要)VMM截获重定向。

以x86架构为例,它提供一个略微受限制的硬件运行环境供客户机运行(non-root mode),在绝大多数情况下,客户机在此受限环境中运行与原生系统在非虚拟化环境中运行没有什么两样,不需要像软件虚拟化那样每条指令都先翻译再执行,而VMM运行在root mode,拥有完整的硬件访问控制权限。仅仅在少数必要的时候,某些客户机指令的运行才需要被VMM截获并做相应处理,之后客户机返回并继续在non-root mode中运行。可以想见,硬件虚拟化技术的性能接近于原生系统,并且,极大地简化了VMM的软件设计架构。

Intel从2005年就开始在其x86 CPU中加入硬件虚拟化的支持——Intel Virtualization Technology,简称Intel VT。到目前为止,在所有的Intel CPU中,都可以看到Intel VT的身影。并且,每一代新的CPU中,都会有新的关于硬件虚拟化支持、改进的feature加入。也因如此,Intel x86平台是对虚拟化支持最为成熟的平台,本书将以Intel x86平台为例介绍KVM的虚拟化。

2. 按虚拟平台分类

根据VMM提供的虚拟平台类型可将VMM分成两类:

第一类VMM虚拟的是现实存在的平台, 并且在客户机操作系统来看, 虚拟的平台现实的平台是一样的, 客户机操作系统察觉不到是运行在一个虚拟平台上. 这样的虚拟平台可以运行现有的操作系统, 无须对操作系统进行修改, 因此称为完全虚拟化(Full Virtualization).

第二类VMM虚拟的是现实中不存在的平台, 而是经过VMM重新定义的, 这种虚拟化平台需要对所运行的客户机操作系统进行或多或少的修改使之适应虚拟环境, 因此客户机OS知道其运行在虚拟平台上, 并且会去主动适应. 这种称为类虚拟化(Para Virtualization).

另外, 一个VMM既可以提供完全的虚拟化的虚拟平台, 又提供类虚拟化的虚拟平台.

2.1. 完全虚拟化

客户OS无须修改就可以运行. 所以客户OS会像操作正常的处理器、内存、I/O设备一样来操作虚拟处理器、虚拟内存和虚拟I/O设备。从实现角度看, 客户机的行为是通过指令反映出来的, 因此VMM需要能正确处理所有可能的命令!!!.

对于完全虚拟化来说, 所有可能的指令是指所虚拟的处理器其手册规范上定义的所有指令.

实现上, 以x86架构为例, 完全虚拟化经历了两个阶段: 软件辅助的完全虚拟化硬件辅助的完全虚拟化

2.1.1. 软件辅助的完全虚拟化

x86虚拟化技术早期, x86体系没有在硬件层次!!!上对虚拟化提供支持, 因此完全虚拟化只能通过软件实现.

一个典型做法是优先级压缩(Ring Compression)和二进制代码翻译(Binary Translation)相结合.

2.1.1.1. 优先级压缩(Ring Compression)

优先级压缩的原理是: 由于VMM客户机运行在不同特权级上, 对应到x86上, 通常是VMM运行在Ring 0, 客户机OS内核运行在Ring 1, 客户机OS应用程序运行在Ring 3. 当客户机OS内核执行相关特权指令时, 由于在非特权的Ring 1, 因此通常触发异常, VMM截获特权指令并进行虚拟化.

Ring Compression能正确处理大部分特权指令, 但是由于x86指令体系设计之初没有考虑到虚拟化, 因此有些指令还是不能通过Ring Compression正常处理, 即在Ring 1做特权操作的时候却没有触发异常(比如修改EFLAGES的IF标志), 从而VMM不能截获并做相应处理.

2.1.1.2. 二进制代码翻译(Binary Translation)

二进制代码翻译方法因此被引入来处理这些虚拟化不友好的指令.

二进制代码翻译的思想很简单, 就是通过扫描并修改客户机的二进制代码, 将难以虚拟化的指令转化为支持虚拟化的指令.

VMM通常会对OS二进制代码进行扫描, 一旦发现需要处理的指令, 就将其翻译成支持虚拟化的指令块(Cache Block). 这些指令块可以与VMM合作访问受限的虚拟资源!!!, 或显式地触发异常!!! 让VMM进一步处理.

此外, 由于该技术可以修改客户机的二进制代码, 因此别广泛应用于性能优化!!!, 即将某些造成性能瓶颈的指令替换成更高效的指令来提高性能.

这种方式很难在架构上保证其完整性, 因此, x86在硬件上加入了对虚拟化的支持, 从而在硬件架构上实现了虚拟化.

2.1.2. 硬件辅助完全虚拟化

很多问题, 如果在本身的层次上难以解决, 那通过增加一个层次, 在其下面一个层次就会变得容易解决.

硬件辅助虚拟化就是这样一种方式, 既然OS是硬件上最后一层系统软件, 如果硬件本身加入足够的虚拟化功能, 就可以截获操作系统对敏感指令的执行对敏感资源的访问, 从而通过异常方式报告给VMM, 这就解决了虚拟化的问题.

Intel的VT-x技术就是这样. VT-x在处理器上新引入了一个新的执行模式用于运行虚拟机. 当虚拟机执行在这个特殊模式中时, 它仍然面对的是一套完整的处理器寄存器集合和执行环境, 只是对任何特权操作都会被处理器截获并报告给VMM. VMM本身运行在正常模式下, 在接收到处理器的报告后, 通过对目标指令的解码, 找到对应的虚拟化模块进行模拟, 并把最终的效果反映在特殊模式下的环境中.

硬件辅助虚拟化是一种完备的虚拟化方法, 因为内存和外设的访问本身也是由指令来承载, 对处理器指令级别的截获意味VMM可以模拟一个与真实主机完全一样的环境.

2.1.2.1. 发展以及现状

与半虚拟化相反的,全虚拟化(Full Virtualization)坚持第一个理想化目标:客户机的操作系统完全不需要改动。敏感指令在操作系统和硬件之间被VMM捕捉处理,客户操作系统无须修改,所有软件都能在虚拟机中运行。因此,全虚拟化需要模拟出完整的、和物理平台一模一样的平台给客户机,这在达到了第一个目标的同时也增加了虚拟化层(VMM)的复杂度。

性能上,2005年硬件虚拟化兴起之前,软件实现的全虚拟化完败于VMM和客户机操作系统协同运作的半虚拟化,这种情况一直延续到2006年。之后以Intel VT-x、VT-d为代表的硬件虚拟化技术的兴起,让由硬件虚拟化辅助的全虚拟化全面超过了半虚拟化。但是,以virtio为代表的半虚拟化技术也一直在演进发展,性能上只是略逊于全虚拟化,加之其较少的平台依赖性,依然受到广泛的欢迎。

2.2. 类虚拟化

两个虚拟化目标中, 纯软件的虚拟化可以做到第一个目标,但性能不是很好,而且软件设计的复杂度大大增加。

那么如果放弃第一个目标呢?让客户机意识到自己是运行在虚拟化环境里,并做相应修改以配合VMM,这就是半虚拟化(Para-Virtualization)。

  • 一方面,可以提升性能和简化VMM软件复杂度;
  • 另一方面,也不需要太依赖硬件虚拟化的支持,从而使得其软件设计(至少是VMM这一侧)可以跨平台且是优雅的。

通过在源代码级别修改指令回避虚拟化漏洞的方式来使VMM能够对物理资源实现虚拟化.

x86的难以虚拟化的指令, 完全虚拟化通过Binary Translation在二进制代码级别上避免虚拟化漏洞. 类虚拟化采用另一种思路, 即修改操作系统的内核(即API级), 使得操作系统内核完全避免这些难以虚拟化的指令. 操作系统通常会用到处理器提供的所有功能, 例如特权级别、地址空间和控制寄存器等.

类虚拟化首先解决的问题就是如何插入VMM. 典型做法是修改操作系统的处理器相关代码, 让操作系统主动让出特权级别, 而运行在次一级特权级. 这样, 当操作系统试图执行特权指令时, 保护异常被触发, 从而提供截获点给VMM来模拟.

既然内核代码需要被修改, 类虚拟化可以进一步用来优化I/O. 即, 类虚拟化不是去模拟真实设备, 因为太多寄存器模拟会影响性能. 相反, 类虚拟化可以定义出高度优化的I/O协议. 这种I/O协议完全基于事务, 可以达到近物理机的速度.

“本质上,准虚拟化弱化了对虚拟机特殊指令的被动截获要求,将其转化成客户机操作系统的主动通知。但是,准虚拟化需要修改客户机操作系统的源代码来实现主动通知。”典型的半虚拟化技术就是virtio,使用virtio需要在宿主机/VMM和客户机里都相应地装上驱动。

3. 按VMM实现结构分类

3.1. Hypervisor模型

在Hypervisor模型中, VMM首先可被看作是一个完备的操作系统!!!, 不过和传统OS不同, VMM为虚拟化而设计的, 因此还具备虚拟化功能.

从架构看,

  • 首先, 所有物理资源如处理器、内存和I/O设备都归VMM所有, 因此, VMM管理物理资源;

  • 其次, VMM需要向上提供虚拟机用于运行客户操作系统, 因此, VMM负责虚拟环境的创建和管理.

图3-9展示了Hypervisor的架构, 其中

  • 处理器管理代码(Processor, P)负责物理处理器的管理和虚拟化!!!,
  • 内存管理代码(Memory, M)负责物理内存的管理和虚拟化!!!,
  • 设备模型(Device Model, DM)负责I/O设备的虚拟化,
  • 设备驱动(Device Driver, DR)负责I/O设备的驱动, 即物理设备的管理.

VMM直接管理所有物理资源, 包括处理器、内存和I/O设备, 所以设备驱动也是VMM的一部分. 此外, 处理器管理代码内存管理代码设备模型也是VMM的一部分.

Hypervisor模型的VMM:

6. VMM的分类

3.1.1. Hypervisor模型的优点

由于VMM同时具备物理资源的管理功能虚拟化功能, 所以, 物理资源虚拟化效率更高.

安全层面, 虚拟机的安全只依赖VMM的安全. 宿主模型中同时依赖VMM和宿主机OS的安全.

3.1.2. Hypervisor模型的缺点

Hypervisor模型拥有虚拟化高效率同时也有缺点.

由于VMM完全拥有物理资源, 因此, VMM需要进行物理资源的管理, 包括设备的驱动. 设备驱动工作量很大, 所以基于Hypervisor模型的VMM通常根据市场定位, 选择一些I/O设备来支持, 而不是所有.

此外, 很多功能必须在VMM中重新实现, 例如调度和电源管理等, 无法像宿主模型那样借助宿主机OS.

3.2. 宿主模型

  • 物理资源宿主机OS管理. 宿主机OS不是为虚拟化设计的, 因此本身不具备虚拟化功能, 有些实现中还包括用户态进程, 如负责I/O虚拟化的用户态设备模型.

  • VMM通过调用宿主机OS的服务来获得资源, 实现处理器、内存和I/O设备的虚拟化。VMM创建虚拟机后, 通常将虚拟机作为宿主机OS一个进程参与调度.

图3-10显示宿主模型架构.

  • 宿主机OS拥有所有物理资源, 包括I/O设备, 所以设备驱动位于宿主机操作系统中.
  • VMM(图中虚拟机管理内核模块)则包含处理器虚拟化模块内存虚拟化模块.

图中设备模型实际也是VMM一部分, 具体实现中, 可将设备模型放在用户态, 也可放在内核态.

宿主模型的VMM:

6. VMM的分类

3.2.1. 宿主模型的优点

宿主模型的优缺点和Hypervisor模型恰好相反.

宿主模型最大优点是能充分利用现有OS的设备驱动程序, VMM无须为各类I/O设备重新实现驱动程序, 可以专注于物理资源的虚拟化.

此外, 宿主模型也可利用宿主机OS的其它功能, 例如调度和电源管理等, 这都不需要VMM重新实现.

3.2.2. 宿主模型的缺点

缺点.

  • VMM调用宿主机OS的服务获取资源进行虚拟化, 系统服务设计之初没考虑虚拟化支持, 效率和功能有影响.
  • 安全, 虚拟机的安全同时依赖VMM和宿主机OS的安全.

3.3. 混合模型

VMM仍然在最底层, 拥有所有物理资源.

与Hypervisor不同的是, VMM会主动让出大部分I/O设备的控制权, 将他们交给一个运行在特权虚拟机中的特权操作系统来控制.

相应, VMM虚拟化的职责也被分担. 处理器和内存的虚拟化仍然是VMM完成, 而I/O虚拟化VMM和特权操作系统共同合作完成.

图3-11显示混合模型.

  • I/O设备特权操作系统控制, 因此, 设备驱动模块位于特权操作系统中.
  • 其它物理资源的管理和虚拟化由VMM完成, 因此, 处理器管理代码内存管理代码在VMM中.

混合模型的VMM:

6. VMM的分类

I/O设备的虚拟化VMM特权操作系统共同完成, 因此, 设备模型模块位于特权操作系统中, 并且通过相应的通信机制与VMM合作.

3.3.1. 混合模型的优点

混合模型集中了上面两种模型的优点.

VMM既可利用现有OS的I/O设备驱动. VMM直接控制处理器、内存等物理资源, 虚拟化效率比较高。

安全性上, 对特权OS的权限控制得当, 虚拟机安全性只依赖VMM.

3.3.2. 混合模型的缺点

缺点.

特权OS运行在虚拟机上, 当需要特权OS提供服务时, VMM需要切换, 产生上下文切换开销. 切换频繁时, 上下文切换开销会造成性能的明显下降.

出于性能考虑, 很多功能还是必须在VMM中实现, 无法借助特权OS, 如调度程序和电源管理等.

4. 按软件框架分类

从软件框架的角度上,根据虚拟化层直接位于硬件之上还是在一个宿主操作系统之上,将虚拟化划分为Type1和Type2,如图1-6所示。

6. VMM的分类

4.1. Type1: 没有宿主机OS, Hypervisor直接运行在硬件上

Type1(类型1)Hypervisor也叫nativebare-metal Hypervisor。这类虚拟化层直接运行在硬件之上,没有所谓的宿主机操作系统。它们直接控制硬件资源以及客户机。典型地如Xen和VMware ESX。

4.2. Type2: Hypervisor运行在宿主机操作系统中

Type2(类型2)Hypervisor运行在一个宿主机操作系统之上,如VMware Workstation;或系统里,如KVM。这类Hypervisor通常就是宿主机操作系统的一个应用程序,像其他应用程序一样受宿主机操作系统的管理。比如VMware Workstation就是运行在Windows或者Linux操作系统上的一个程序而已。客户机是在宿主机操作系统上的一个抽象,通常抽象为进程