2.2 虚拟化技术介绍

Nova计算服务组件通过API服务器控制虚拟机管理程序。基于预算控制、资源限制、支持特性和所需技术要求等因素，我们需要选择一个最佳的虚拟化技术。根据目前OpenStack的发展情况，大部分Nova计算服务组件采用的是KVM和Xen虚拟化技术。

Nova计算服务组件具备一个抽象层，其允许在部署时选择一种虚拟化技术。现实情况是，每种虚拟化技术的支持和特性是不同的，测试完整度也不相同，并非全部支持相同的特性。以下从测试完整度和功能多样性两方面详细阐述每种虚拟化技术所支持的特性。

1.测试特性

1）虚拟化技术一测试范围

● 测试范围：

➢ 单元模块化测试。

➢ 功能性测试。

● 虚拟化技术一：QEMU/KVM。

2）虚拟化技术二测试范围

● 测试范围：

➢ 单元模块化测试。

➢ 外部组织进行功能性测试。

● 虚拟化技术二：

➢ Hyper-V.

➢ VMware.

➢ XenServer.

➢ 基于Libvirt的Xen。

3）虚拟化技术三测试范围

截至Icehouse版本，该组中的虚拟化技术已经过期，不再更新。这些都没有经过充分的测试，使用它们存在一定的风险。

● 测试范围：

➢ 单元模块化不完全测试。

➢ 未公开的功能性测试。

● 虚拟化技术三：

➢ Baremetal（裸金属）。

➢ Docker（容器技术）。

➢ 基于Libvirt的LXC。

2.虚拟化技术支持功能特性

以下基于虚拟化技术支持特性帮助用户选择合适的方案：

● 从OpenStack发展轨迹观察，KVM是最通用的虚拟化技术，在社区中可以找到许多错误的解决方案。KVM和QEMU支持OpenStack的所有特性。

● 由于Microsoft Hyper-V是免费的，因而得到很多支持。VMware ESXi由于部分免费，也得到一些支持，但是没有vCenter和企业级License，一些API的使用是受限的。

● Xen技术分类较多，包含以下几种。

➢ XenServer：开源，但是有Citrix的商业支持。

➢ Xen Cloud Platform（XCP）：开源版本，等同于XenServer。XenServer支持的特性，XCP全部支持。

➢ XenAPI：管理XenServer和XCP的API程序。

➢ XAPI：XenServer和XCP的主守护进程，与XenAPI直接通信。

➢ 基于Libvirt的Xen：Xen虚拟化技术使用Libvirt驱动。

通过XenAPI，Nova计算服务组件支持XenServer和XCP两种虚拟化技术。但是这并不意味着支持所有基于Xen的平台，如运行SUSE和RHEL的平台，它们都是基于Libvirt虚拟化层的Xen虚拟化技术。

● 对于Baremetal而言，技术已经过期，不再更新，Baremetal驱动也不再更新。新的特性会被更新到Ironic中，由Ironic代替Baremetal。

下面对目前主流的两种虚拟化技术KVM和Xen进行详细介绍。

2.2.1 KVM虚拟化技术

KVM（Kernel-based Virtual Machine）是基于x86硬件虚拟化扩展（Intel VT或AMD-V）的全虚拟化解决方案，它包含一个可加载的内核模块kvm.ko，提供核心的虚拟化基础架构，还有一个处理器特定模块kvm-intel.ko或kvm-amd.ko。

KVM允许在一台主机节点上运行多个未经改动的虚拟镜像，包括Windows和Linux。每台虚拟机都有独立的虚拟硬件，包括网卡、磁盘等。

KVM是一个开源项目，其核心组件包含在Linux更新主线中（从Linux内核2.6.20版本开始），用户空间组件包含在QEMU更新主线中（从QEMU 1.3版本开始）。

KVM是在CPU硬件支持基础之上的虚拟化技术，同Hyper-V、Xen一样依赖此项技术。没有CPU硬件虚拟化的支持，KVM是无法工作的。

KVM是Linux的一个模块，可以用modprobe加载KVM模块。只有在加载模块后，才能进一步通过其他工具创建虚拟机。但仅有KVM模块是远远不够的，因为用户无法直接控制内核模块去做事情，必须有一个用户空间的工具才行，这个用户空间的工具就是开源虚拟化软件QEMU。QEMU也是一个虚拟化软件，其特点是可虚拟不同的硬件，比如在x86的CPU上可虚拟一个安腾的CPU，并可利用它编译出可运行在安腾上的程序。KVM使用了QEMU的一部分，并稍加改造，就变成了可控制KVM的用户空间工具。仔细观察，发现官方提供的KVM下载有两大部分三个文件，分别是KVM模块、QEMU工具及二者的合集。也就是说，可以只升级KVM模块，也可以只升级QEMU工具。

一个普通的Linux进程有两种运行模式：内核模式和用户模式。但KVM拥有3种模式，分别是内核模式、用户模式和客户模式。在KVM模型中，每个虚拟主机都是由Linux调度程序管理的标准进程，该进程调用KVM用户模式，执行应用程序。对于应用程序而言，用户模式是默认模式，当需要一些来自内核的服务时便切换到内核模式，如在磁盘上写入数据时。客户模式进程运行在虚拟机内，拥有自己的内核和用户空间变量，在客户模式下可以使用正常的kill和ps命令，KVM虚拟机表现为一个正常的进程，可以像其他进程一样被杀掉。KVM利用硬件虚拟技术模拟处理器的形态，虚拟机的内存管理由内核直接处理。内核模式在需要的时候，向QEMU进程发送信号处理大部分的硬件仿真。KVM管理CPU和内存的访问调用，QEMU仿真硬件资源（如硬盘、网卡、声卡等）。当QEMU单独运行时，也可以同时模拟CPU和硬件。

KVM的API是通过/dev/kvm设备访问的，/dev/kvm是一个标准的字符设备，可以使用常用的open、close、ioctl接口操作，但是在KVM的实现中，没有提供read和write接口，所有对KVM的操作都是通过ioctl接口操作的。KVM提供给上层的API功能可分为3种类型。

（1）system指令：针对虚拟化系统的全局性参数进行设置和控制，包括全局性的参数设置和虚拟机创建等工作，主要指令如下表所示。

其中，KVM_CREATE_VM比较重要，用于创建虚拟机，并返回一个代表该虚拟机的文件描述符（fd）。新创建的虚拟机没有虚拟CPU，也没有内存等资源，需要对新创建虚拟机时返回的文件描述符使用ioctl指令进行下一步的配置，生成虚拟CPU和内存等资源。

（2）VM指令：针对虚拟机进行控制，大部分需要针对从KVM_CREATE_VM中返回的文件描述符（fd）进行操作，包括配置内存、配置虚拟CPU、运行虚拟主机等，主要指令如下表所示。

KVM_CREATE_VCPU和KVM_RUN是VM ioctl指令中两种重要的指令，通过KVM_CREATE_VCPU为虚拟机创建虚拟CPU，并获得对应的fd文件描述符后，可以对其调用KVM_RUN，以启动该虚拟机（或称为调度虚拟CPU）。

KVM_RUN结构体定义在include/linux/kvm.h中，可以通过该结构体了解KVM的内部运行状态。

（3）VCPU指令：针对具体的虚拟CPU进行参数设置，包括寄存器读/写、中断设置、内存设置、时钟管理、调试开关等。KVM虚拟机运行时也可以进行相关设置。主要指令如下。

● 寄存器控制方面的主要指令如下表所示。

● 中断和事件管理方面的主要指令如下表所示。

● 内存管理方面的主要指令如下表所示。

● 其他方面的主要指令包括CPUID设置、调试接口等。

对于KVM的操作都是从打开/dev/kvm设备文件开始的，打开后，会获得相应的文件描述符（fd），然后通过ioctl系统指令对该fd进行进一步的操作，如通过KVM_CREATE_VM指令可以创建一个虚拟机并返回虚拟机对应的文件描述符，接着根据该描述符来进一步控制虚拟机的行为，如通过KVM_CREATE_VCPU指令来为该虚拟机创建VCPU。下面通过图示介绍KVM的初始化过程。

1.加载模块

加载KVM和SVM或VMX。成功加载后，生成/dev/kvm文件供用户空间访问，如下图所示。

2.调用/dev/kvm

/dev/kvm既不可读也不可写。

/dev/kvm拥有ioctl接口，如下图所示。

3.调用kvm ioctl()

调用KVM_GET_API_VERSION进行版本检查。

调用KVM_CREATE_VM创建一个虚拟主机，并返回一个kvm-vm文件描述符，如下图所示。

4.调用kvm和kvm-vm ioctl()

在kvm文件描述符上调用KVM_CHECK_EXTENSIONS（检查扩展支持情况）。

在kvm-vm文件描述符上调用KVM_SET_TSS_ADDR（在Intel架构中初始化TSS内存区域）设置TSS地址，如下图所示。

5.调用kvm和kvm-vm ioctl()

在kvm文件描述符上调用KVM_CHECK_EXTENSIONS（检查扩展支持情况）。

在kvm-vm文件描述符上设置KVM_SET_MEMORY_REGION（修改虚拟CPU的内存区域），如下图所示。

6.调用kvm和kvm-vm ioctl()

在kvm文件描述符上调用KVM_CHECK_EXTENSIONS（检查扩展支持情况）。

在kvm-vm文件描述符上调用KVM_CREATE_IRQCHIP（创建虚拟APIC并将虚拟CPU关联到APIC）设置irqchip，如下图所示。

7.创建虚拟CPU

在kvm文件描述符上调用KVM_CREATE_VCPU。

执行后，返回kvm-vcpu文件描述符，如下图所示。

KVM/QEMU的内存管理非常有趣，因为KVM/QEMU运行就像Linux系统中的一个程序运行，所以它分配内存是调用malloc()和mmap()函数进行的。当一个虚拟机申请1GB的物理内存时，KVM/QEMU会执行malloc（1<<30）操作，从宿主机上分配1GB的虚拟地址空间。所以它只调用malloc()函数，并没有进行实际的物理内存分配；而是当虚拟机第一次启动需要访问内存时，才会给虚拟机分配真正的物理内存。虚拟机操作系统启动运行，它可以识别通过malloc()函数分配的物理内存，接下来操作系统Kernel开始访问已识别的物理内存地址，这时KVM/QEMU进程会访问已识别的第一个内存页。

KVM/QEMU虚拟机的任何内存变动都会关联底层宿主机的变化，宿主机会确认该虚拟机变化在其整个内存分页表中是否有效、可用，不允许其访问任何不属于它的内存页。此内存运行访问机制有两种。

● 第一种是影子分页表技术。虚拟机所使用的内存分页表与实际的内存分页表是独立的，不是同一张分页表。当虚拟机修改自己的内存分页表时，宿主机会检测到有修改动作发生，然后进行确认，之后才会修改真正的分区表，使由虚拟机发起的修改操作生效。虚拟机不能直接访问真正的内存分页表，而是访问影子分页表。这是一种非常普通的虚拟化内存技术。

● 第二种是VMX/AMD-V扩展技术。VMX/AMD-V扩展技术允许底层宿主机始终监控，以此获得虚拟机修改真正内存分页表的信息。这种内存运行访问机制实际且有效，但是它对性能有一些影响，完成一次访问最高可能消耗25页内存，代价非常大。造成这种问题的原因是每次内存访问需要两次操作才能完成，包括虚拟机内存分页表访问和宿主机内存分页表访问。当然，宿主机运行和维护影子分页表也需要消耗大量资源。

AMD和Intel厂商为了解决这些性能损耗问题，开发了两种全新的技术EPT和NPT。这两种技术很相似，都使硬件重新识别架构，快速地将虚拟机内存变化直接传递给宿主机的物理内存，而不用再去访问宿主机内存分页表，减少一次操作，效率更高。

但由此带来的问题就是宿主机的内存分页表像进程隔离一样会被强制执行，当一个内存页在宿主机内标记为没有被分配时，实际上该内存页可能已经被虚拟机占有了，所以必须与EPT/NPT共同协商处理这个变化。

为了解决该问题，可以在软件层面通过调用mmu_notifiers()函数解决此问题，因为KVM/QEMU的内存本来就是正常的物理内存，Kernel可以像交换、替换和释放正常的物理内存一样处理这些内存页。

在虚拟机释放内存页给宿主机前，需要等待宿主机的通知。当KVM/QEMU虚拟主机在影子分页表或EPT/NPT中删除该内存页后，宿主机便可以自由地使用该内存页。

关于内存的申请与回收，可以总结为以下几个步骤。

（1）内存申请。

①QEMU调用malloc()函数为虚拟机分配虚拟内存页，但是此时并没有申请真正的物理内存。

②虚拟机开始访问该虚拟内存页，并且认为该虚拟内存页是真正的物理内存页，但是由于该内存页没有被真正分配，所以开始向宿主机申请。

③宿主机内核发现有一个内存页错误，便会在已经被分配的malloc()'d区域调用do_page_fault()函数。如果一切顺利，没有打断，则宿主机开始响应虚拟机的操作。

④宿主机内核创建pte_t，使malloc()'d虚拟地址连接到真正的物理内存地址，生成rmap，并把它们放到LRU中。

⑤此时，mmu_notifier_change_pte()被调用，其允许KVM为该内存页创建NPT/EPT。

⑥宿主机从该错误的内存页中返回标识，虚拟机得到内存后执行操作恢复。

（2）内存回收。

①宿主机内核利用rmap结构寻找到需回收的内存页被映射到哪个VMA（vm_area_struct）。

②宿主机内核查找该VMA所关联的mm_struct，并遍历宿主机的内存分页表，查找到该内存页在物理硬件上的位置。

③宿主机内核替换出该内存页并清空pte_t。

④宿主机内核接着调用mmu_notifier invalidate_page()函数，在NPT/EPT中查找到该页并删除。

⑤现在，该页已经被释放，任何需要该页的访问都可以向宿主机申请（此时，可以转换到内存申请的第二步）。

2.2.2 Xen虚拟化技术

Xen是一种开源的、属于类型1（裸金属虚拟化，Baremetal Hypervisor）的虚拟化技术，它使多个同样操作系统或不同操作系统的虚拟机运行在同一个物理主机节点上成为可能并实现。Xen是唯一的属于类型1（裸金属虚拟化，Baremetal Hypervisor）并且开源的虚拟化技术，它被作为商业应用或开源应用的基础而加以使用，如服务器虚拟化、Infrastructure as a Service（IaaS）、桌面虚拟化、安全应用、嵌入式和硬件设备等。由于它性能稳定，因而被广泛用于云计算生产环境。

以下是Xen虚拟化技术的一些关键特性。

● 轻便小型的设计（核心代码有1MB左右）。它使用了微小内核设计，占用极少内存，加上有限的接口设计，使得它比其他虚拟化技术更健壮、更安全。

● 操作系统无关性。Domain0一般安装在Linux操作系统中，也可以使用其他操作系统代替，如NetBSD和OpenSolaris等。

● 驱动分离。Xen虚拟化技术允许主要的硬件设备驱动运行于虚拟机内部，当驱动出现crash（宕机）或者报错时，包含该驱动的虚拟机可以重启，该驱动也可以重启，这样不会影响其他的虚拟机。

● 半虚拟化技术。运行在半虚拟化技术上的虚拟机已经经过优化，它们可以运行得更加流畅，比运行在需要硬件扩展支持的全虚拟化管理程序（HVM）上的虚拟机更快。当然，Xen可以运行在不支持硬件扩展的硬件平台上。

Xen虚拟化技术架构包含3个关键点，掌握这3个关键点对于用户理解和做出正确的选择至关重要。

● 类型：Xen虚拟机技术支持半虚拟化（Para-Virtualization，PV）和全虚拟化（Hardware-assisted Virtualization，HVM）两种类型。

● Domain0：Xen虚拟化架构中包含一个特殊的域Domain0，其包括硬件设备驱动和控制虚拟机的Toolstack。

● Toolstacks：其涵盖各种不同的Toolstack。

1.Xen架构

Xen虚拟化管理程序直接运行在硬件之上，处理各种CPU、内存和中断请求。在包含虚拟化管理程序的操作系统启动过程中，BootLoader加载完成并退出后，加载的第一个程序就是Xen，在其上运行着虚拟机。运行的虚拟机叫作Domain（域）或客户机（Guest），其中有一个特殊的Domain叫作Domain0，其包含了所有硬件设备的驱动。Domain0还包含了控制栈（Toolstack），用于虚拟机创建、删除和配置等。下图是Xen虚拟化管理程序的架构。

在Xen架构中包含以下几个重点。

● Xen虚拟化管理程序是一个极小的软件程序，包含大概15万行代码。Xen虚拟化管理程序本身没有I/O功能虚拟化，如网络和存储等。

● 虚拟机是一个虚拟化的环境，每个虚拟机都运行着自己的操作系统和应用程序。Xen支持两种虚拟化模式：半虚拟化和全虚拟化。在同一个虚拟化管理程序上可以同时并行使用这两种虚拟化模式，也可以串行在全虚拟化模式上使用半虚拟化模式，以此保证半虚拟化和全虚拟化的连续性。虚拟机与硬件之间是完全隔离的，它们没有任何权限可以访问底层的硬件和I/O设备等，因此它们也被叫作DomainU（Unprivileged Domain）。

● Domain0是一个特殊的虚拟机，其具备特殊的、足够的权限直接访问底层的硬件设备，处理所有底层的I/O设备请求，并与其他虚拟机（DomainU）进行交互通信。Domain0对外部开放一个接口，使用户可以控制整个系统。没有Domain0，Xen虚拟化管理程序是无法使用的，它是整个系统启动后加载的第一个虚拟机。

● Toolstack包含在Domain0中，也叫作控制栈，其允许用户管理虚拟机，包括虚拟机创建、删除和配置等。

● 终端是Toolstack对外部开放的一个接口，用户可以通过命令行或/和图形化界面控制整个系统，OpenStack和CloudStack中的编排服务也被支持。

● Domain0要求一个支持Xen虚拟化管理程序的内核，半虚拟化的虚拟机（DomainU）要求一个支持半虚拟化的内核。比较新的Linux操作系统都支持Xen虚拟化管理程序，并且也包含支持虚拟化和Toolstack的软件包。

2.虚拟机类型

下图是Xen虚拟化管理程序支持虚拟化模式的变化。

1）半虚拟化（PV）

半虚拟化是由Xen虚拟化管理程序引入的一个轻量级、高效的虚拟化模式，之后被其他虚拟化平台所采用。半虚拟化不要求物理主机节点CPU具备扩展特性，但是其需要支持半虚拟化的内核和驱动，因此，虚拟机能够感知到虚拟化管理程序；同时，因为没有硬件仿真，所以运行非常高效。支持半虚拟化的内核包括Linux、FreeBSD、NetBSD和OpenSolaris。Linux内核从2.6.24版本开始，使用Linux pvops framework的内核都支持半虚拟化，这也就意味着除了比较老的版本外，几乎所有的Linux内核都支持半虚拟化。下图是半虚拟化模式在Xen虚拟化管理程序中的性能表现。

2）全虚拟化（HVM）

全虚拟化需要物理主机节点CPU扩展特性的支持，为此，Intel和AMD厂商提供了Intel VT和AMD-V技术。Xen虚拟化管理程序使用QEMU仿真硬件设备，包括BIOS、IDE磁盘控制器、VGA图形适配器、USB控制器和网络适配器等。硬件的扩展特性提高了仿真性能。同时，全虚拟化模式下的虚拟机不再需要特殊内核的支持，这也就意味着Windows操作系统在基于Xen全虚拟化的平台上也是被支持的。一般情况下，半虚拟化的虚拟机比全虚拟化的虚拟机性能表现更好，因为全虚拟化的虚拟机需要硬件仿真，会消耗一部分性能。

在某些情况下，可以使用半虚拟化驱动加速全虚拟化虚拟机的I/O性能。在Windows虚拟机中，需要安装合适的半虚拟化驱动。具体信息可以参照以下链接。

● Xen半虚拟化驱动列表：http://xenproject.org/downloads/windows-pv-drivers.html。

● 第三方GPL半虚拟化驱动列表：http://wiki.xensource.com/wiki/Xen_Windows_GplPv。

● Windows半虚拟化驱动列表：http://wiki.xensource.com/wiki/Category：Windows_PV_Drivers。

在Xen虚拟化支持的操作系统中，在选择全虚拟化模式运行操作系统时，其已安装的半虚拟化或全虚拟化驱动可以自动被使用。下图展示了全虚拟化模式和含有半虚拟化驱动的全虚拟化模式之间的区别。

3）全虚拟化模式+半虚拟化驱动（PVHVM）

全虚拟化模式下的虚拟机可以使用指定的半虚拟化驱动，以此达到增强系统性能的目的。这些驱动是为全虚拟化环境而优化的半虚拟化驱动，绕过磁盘和网络的模拟仿真，从而在全虚拟化模式下获得更好的性能。这也就意味着在使用一些虚拟机操作系统时会获得更好的性能，如Windows等。

基于Xen虚拟化管理程序的半虚拟化虚拟机可以自动使用半虚拟化驱动，全虚拟化模式下使用的半虚拟化驱动仅适用于全虚拟化模式下的虚拟机。下图展示了3种类型的全虚拟化模式之间的区别。

4）半虚拟化+硬件扩展特性（PVH）

Xen虚拟化管理程序4.4版本中包含一种虚拟化模式，叫作基于DomainU的PVH；4.5版本又开发了一种基于Domain0（Linux和BSD）的PVH虚拟化模式，其实质是半虚拟化的虚拟机可以使用半虚拟化驱动以提高I/O性能，也可以使用硬件扩展特性提高系统性能，不需要硬件仿真。PVH在4.4和4.5版本中作为试验进行发布和测试使用，性能表现非常好，并且在4.6版本中进行了优化。从本质上讲，PVH对两种虚拟化模式进行了合并，简化了Xen虚拟化管理程序的架构。

简而言之，PVH在Linux和BSD中使用了极少的代码和接口，从而减少了TCB和攻击的可能性，降低了风险。一旦对其进行相应的优化，它将具备更好的性能和更低的延迟，特别是在64位的操作系统上表现更优。

PVH要求虚拟机操作系统对其提供支持，在配置文件中设置pvh=1即可启用PVH支持。下图展示了全虚拟化、半虚拟化和PVH之间的区别。

3.Toolstacks、APIs和终端

Xen虚拟化管理程序包含许多不同的Toolstacks，每个Toolstack对外开放接口，利用该开放接口可以运行各种不同的工具，管理整个系统。下面介绍一些商业化产品所使用的Toolstack，以及托管服务商使用API的案例。

Xen虚拟化管理程序与默认的Toolstacks、Libvirt和XAPI相互作用、协同运行。Xen虚拟化管理程序与XAPI配合使用的虚拟化产品是XCP，但是其已经逐渐被开源产品XenServer所取代。基于Xen虚拟化管理程序的各种虚拟化模式都具备各自的优势，并且针对不同的案例进行了优化，因此对虚拟化方案的选择也是见仁见智。下图中的Default：XL和XAPI/XE由Xen虚拟化管理程序提供。

下面针对图形中各种不同的Toolstacks进行解释。

● Default：XL：XL是一个使用Libxenlight建立的轻量级CLI Toolstack，其随着Xen的更新而发展，在Xen 4.1版本中，XL是默认使用的Toolstack。由于Xend已经过时，即将从Xen中删除，所以XL被设计为与XM CLI向后兼容，它提供了一个简单的、针对Xen的命令行接口，用于虚拟机的创建和管理等。

● XAPI/XE：Xen虚拟化管理程序管理API（XAPI）是XenServer虚拟化产品默认使用的Toolstack，有时在CloudStack中也会使用。目前，逐渐被废弃的XCP虚拟化平台正尝试提供一个基于XAPI的社区开发平台，以开源的形式进行，并在正式发行版中提供该技术。

● Libvirt/virsh：Libvirt是一个虚拟化API，用于管理各种虚拟化技术，如Xen、KVM等。Libvirt拥有一个Libxenlight端口，用于与xm进行接口通信。

● Default/Xend：Xend是一个诞生时间比较早的Toolstack，一直作为Xen虚拟化管理程序的一部分进行更新、发布和使用。但是自Xen 4.1版本发布后，Xend开始过时，不再推荐使用；在Xen 4.5版本以后，其已经被删除。现在推荐使用上述三种Toolstacks。XL被设计成一个与XM CLI兼容的命令行Toolstack，可以将请求发送给Xend，所以使用XL不失为一种很好的升级方法。

下表是以上介绍的Toolstack与其CLI命令行的对应关系。