KVM虚拟化知识的一些笔记

一、KVM介绍

KVM：运行在内核空间，提供CPU 和内存的虚级化，以及客户机的 I/O 拦截。Guest 的 I/O 被 KVM 拦截后，交给 QEMU 处理。 
QEMU：修改过的为 KVM 虚机使用的 QEMU 代码，运行在用户空间，提供硬件 I/O 虚拟化，通过 ioctl /dev/kvm 设备和 KVM 交互。

KVM所实现的拦截虚拟机I/O请求的原理

现代CPU本身实现了对特殊指令的截获和重定向的支持。 
以x86平台为例，支持虚拟化技术的CPU带有特别优化过的指令集来控制虚拟化过程。通过这些指令集，VMM将客户机置于一种受限制的模式下运行，一旦客户机视图访问物理资源，硬件会暂停客户机的运行，将控制权交回给 VMM 处理。

VMM还可以利用硬件的虚拟化增强机制，将客户机在受限模式下对一些特定资源的访问，完全由硬件重定向到VMM指定的虚拟资源，整个过程不需要暂停客户机的运行和VMM的参与。 
（由于虚拟化硬件提供全新的架构，支持操作系统直接在上面运行，无需进行二进制转换，减少了相关的性能开销，极大简化了VMM的设计，使得VMM性能更加强大。）

QEMU-KVM

QEMU原本不是KVM的一部分，它自己就是一个纯软件实现的虚拟化系统，所以性能低下。但是，QEMU代码中包含整套虚拟机的实现，包括处理器虚拟化，内存虚拟化，以及KVM需要使用到的虚拟设备模拟（网卡、显卡、存储控制器和硬盘等）。虚机的配置和创建、虚机运行时依赖的虚拟设备、虚机运行时的用户环境和交互，以及一些虚机的特定技术比如动态迁移，都是QEMU自己实现的。

为了简化代码，KVM在QEMU的基础上做了修改。VM运行期间，QEMU会通过KVM模块提供的系统调用进入内核，由KVM负责将虚拟机置于处理的特殊模式运行。遇到虚机进行 I/O 操作，KVM 会从上次的系统调用出口处返回 QEMU，由 QEMU 来负责解析和模拟这些设备。

KVM

KVM本身不执行任何设备模拟，需要 QEMU 通过 /dev/kvm 接口设置一个 GUEST OS 的地址空间，向它提供模拟的I/O设备，并将它的视频显示映射回宿主机的显示屏。

以在 Intel 上运行为例，KVM 模块被加载的时候，它：

• 首先初始化内部的数据结构；
• 做好准备后，KVM 模块检测当前的 CPU，然后打开 CPU 控制及存取 CR4 的虚拟化模式开关，并通过执行 VMXON 指令将宿主操作系统置于虚拟化模式的根模式；
• 最后，KVM 模块创建特殊设备文件 /dev/kvm 并等待来自用户空间的指令。

虚机的创建和运行将是 QEMU 和 KVM 相互配合的过程。两者的通信接口主要是一系列针对特殊设备文件 dev/kvm 的 IOCTL 调用。其中最重要的是创建虚机。它可以理解成KVM 为了某个特定的虚机创建对应的内核数据结构，同时，KVM 返回一个文件句柄来代表所创建的虚机。 
针对该句柄的调用可以对虚机做相应地管理，比如创建多个 vCPU。KVM 为每一个 vCPU 生成对应的文件句柄，对其相应地 IOCTL 调用，就可以对vCPU进行管理。

虚机在 KVM 的支持下，被置于虚拟化模式的非根模式下，开始执行二进制指令。在非根模式下，所有敏感的二进制指令都被CPU捕捉到，CPU 在保存现场之后自动切换到根模式，由 KVM 决定如何处理。

除了 CPU 的虚拟化，内存虚拟化也由 KVM 实现。内存虚拟化往往是一个虚机实现中最复杂的部分。 
CPU 中的内存管理单元 MMU 是通过页表的形式将程序运行的虚拟地址转换成实际物理地址。在虚拟机模式下，MMU 的页表则必须在一次查询的时候完成两次地址转换：客户机程序的虚拟地址 => 客户机的物理地址 => 真实物理地址。

KVM 支持的功能列表

KVM 所支持的功能有：

• 支持CPU 和 memory 超分（Overcommit）
• 支持半虚拟化I/O （virtio）
• 支持热插拔 （cpu，块设备、网络设备等）
• 支持对称多处理（Symmetric Multi-Processing，缩写为 SMP ）
• 支持实时迁移（Live Migration）
• 支持 PCI 设备直接分配和 单根I/O 虚拟化 （SR-IOV）
• 支持 内核同页合并 （KSM ）
• 支持 NUMA （Non-Uniform Memory Access，非一致存储访问结构 ）

KVM 工具集

• libvirt：操作和管理KVM虚机的虚拟化 API，使用 C 语言编写，可以由 Python,Ruby, Perl, PHP, Java 等语言调用。可以操作包括 KVM，vmware，XEN，Hyper-v, LXC 等 Hypervisor。
• Virsh：基于 libvirt 的 命令行工具 （CLI）
• Virt-Manager：基于 libvirt 的 GUI 工具
• virt-v2v：虚机格式迁移工具
• virt-* 工具：包括 Virt-install （创建KVM虚机的命令行工具）， Virt-viewer （连接到虚机屏幕的工具），Virt-clone（虚机克隆工具），virt-top 等
• sVirt：安全工具

Redhat的KVM

RedHat 有两款产品提供 KVM 虚拟化： 
1. Red Hat Enterprise Linux：适用于小的环境，提供数目较少的KVM虚机。 
2. Red Hat Enterprise Virtualization (RHEV)：提供企业规模的KVM虚拟化环境，包括更简单的管理、HA，性能优化和其它高级功能。

RedHat Linux KVM:

• KVM 由 libvirt API 和基于该 API的一组工具进行管理和控制。
• KVM 支持系统资源超分(overcommit)，包括内存和CPU的超分。RedHat Linux 最多支持物理 CPU 内核总数的10倍数目的虚拟CPU，但是不支持在一个虚机上分配超过物理CPU内核总数的虚拟CPU。
• 支持 KSM （Kenerl Same-page Merging 内核同页合并）

二、CPU和内存的虚拟化

CPU虚拟化

x86操作系统设计为直接运行在裸硬件设备上，因此它们自认为完全占有计算机硬件。 
x86架构提供四个特权级别给操作系统和应用程序来访问硬件：Ring 是指 CPU 的运行级别，Ring 0是最高级别，Ring 3最低。 
就Linux+x86而言，内核运行在最高级别Ring0上，因此它可以使用特权指令，控制中断、修改页表、访问设备等等。 
应用程序的代码运行在最低级别上Ring3上，不能做受控操作。如果要做，比如要访问磁盘，写文件，那就要通过执行系统调用，此时，CPU的运行级别会发生从Ring3到Ring0的切换，并跳转到系统调用对应的内核代码位置执行，这样内核就完成了设备访问，完成之后再从Ring0返回Ring3。这个过程也称作用户态和内核态的切换。

那么，虚拟化在这里就遇到了一个难题： 
因为宿主操作系统是工作在Ring0的，而客户操作系统不是工作在Ring0了，但是它不知道这一点，以前执行什么指令，现在还是执行什么指令，但是没有Ring0执行权限是会出错的。所以这时候虚拟机管理程序（VMM）需要避免这件事情发生。 
虚拟机通过 VMM 实现 Guest CPU 对硬件的访问，根据其原理不同有三种实现技术： 
1. 全虚拟化 
2. 半虚拟化 
3. 硬件辅助的虚拟化

基于二进制翻译的全虚拟化 （full virtualization with binary translation）

客户操作系统运行在 Ring 1，它在执行特权指令时，会触发异常（CPU的机制，没权限的指令会触发异常），然后 VMM 捕获这个异常，在异常里面做翻译，模拟，最后返回到客户操作系统内，客户操作系统认为自己的特权指令工作正常，继续运行。因此性能很差。

简而言之，就是 异常 “捕获（trap）-翻译（handle）-模拟（emulate）”的过程。

半虚拟化 （Para-Virtulization）

半虚拟化就是：修改操作系统内核，替换掉不能虚拟化的指令，通过超级调用（hypercall）直接和Hypervisor通讯，由Hypervisor来执行关键内核操作，比如内存管理、中断和时间保持。

这种做法省去了全虚拟化中的捕获和模拟，大大提高了效率。所以像XEN这种半虚拟化技术，客户机操作系统都是有一个专门的定制内核版本，和x86、mips、arm这些内核版本等价。这样就不会有捕获异常、翻译、模拟的过程了，性能损耗非常低。这也是为什么XEN只支持虚拟化Linux，无法虚拟化Windows原因，Windows是闭源的操作系统。

硬件辅助的全虚拟化

Intel 引入了 Intel-VT （Virtualization Technology）技术。 这种 CPU，有 VMX root operation 和 VMX non-root operation 两种模式，两种模式都支持Ring 0 ~ Ring 3 这4个运行级别。这样，VMM 可以运行在 VMX root operation模式下，客户 OS 运行在VMX non-root operation模式下。

这两种操作模式可以互相转换：

• 运行在 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。

KVM CPU虚拟化

1. qemu-kvm 通过对 /dev/kvm 的 一系列 ICOTL 命令控制虚机
2. 一个 KVM 虚机即一个 Linux qemu-kvm 进程，与其他 Linux 进程一样被Linux 进程调度器调度。
3. KVM 虚机包括虚拟内存、虚拟CPU和虚机 I/O设备，其中，内存和 CPU 的虚拟化由 KVM 内核模块负责实现，I/O 设备的虚拟化由 QEMU 负责实现。
4. KVM 客户机系统的内存是 qemu-kvm 进程的地址空间的一部分。
5. KVM 虚机的 vCPU 作为 线程运行在 qemu-kvm 进程的上下文中。

客户机系统是如何运行的

一个普通的 Linux 内核有两种执行模式：内核模式（Kenerl）和用户模式 （User）。为了支持带有虚拟化功能的 CPU，KVM 向 Linux 内核增加了第三种模式即客户机模式（Guest）。

三种模式的分工为：

• Guest 模式：执行客户机系统非 I/O 代码，并在需要的时候驱动 CPU 退出该模式
• Kernel 模式：负责将 CPU 切换到 Guest mode 执行 Guest OS 代码，并在 CPU 退出Guest mode时回到Kenerl mode
• User 模式：代表客户机系统执行 I/O 操作

主机 Linux 将一个虚拟机视作一个 QEMU 进程，该进程包括下面几种线程：

• I/O 线程用于管理模拟设备
• vCPU 线程用于运行 Guest 代码
• 其它线程，比如处理 event loop，offloaded tasks 等的线程

KVM 内存虚拟化

客户操作系统实现虚拟地址到客户内存物理地址的映射 （VA -> PA）； 
而 VMM 实现客户物理内存到实际机器内存的映射（PA -> MA）。

VMM 内存虚拟化的实现方式：

• 软件方式：通过软件实现内存地址的翻译，比如 Shadow page table （影子页表）技术
• 硬件实现：基于 CPU 的辅助虚拟化功能，比如 AMD 的 NPT 和 Intel 的 EPT 技术

在 Intel 和 AMD 平台，其内存虚拟化的实现方式分别为：

• AMD 平台上的 NPT （Nested Page Tables） 技术
• Intel 平台上的 EPT （Extended Page Tables）技术

EPT 和 NPT采用类似的原理，都是作为 CPU 中新的一层，用来将客户机的物理地址翻译为主机的物理地址。

KSM （Kernel Same-page Merging）

Linux将内核相似的内存页合并成一个内存页。这个特性被KVM用来减少多个相似的虚拟机的内存占用，提高内存的使用效率。对于虚拟机使用相同镜像和操作系统时，效果更加明显。

• 优点：可以节约大量的内存，从而可以实现更多的内存超分，运行更多的虚机。
• 缺点：增加内核开销（用时间换空间）。（所以为了提高效率，可以将这个特性关闭。）

KVM Huge Page Backed Memory

Intel 的 x86 CPU 通常使用 4KB 内存页，但是经过配置，也能够使用巨页(huge page): 4MB on x86_32, 2MB on x86_64, 2MB on x86_32 PAE mode.

使用Huge Page，KVM的虚拟机的页表将使用更少的内存，并且将提高CPU的效率。

三、I/O全虚拟化和准虚拟化（KVM I/O Qemu Full Virtualization and Para-Virtualization）

在 QEMU/KVM 中，客户机可以使用的设备大致可分为三类： 
1. 模拟设备： 完全由 QEMU 纯软件模拟的设备。 
2. Virtio 设备：实现 VIRTIO API 的半虚拟化设备。 
3. PCI 设备: 直接分配 （PCI device assignment）。

全虚拟化I/O设备

在 I/O 虚拟化方面，默认是使用 QEMU 纯软件的方式来模拟 I/O 设备，包括键盘、鼠标、显示器，硬盘 和 网卡 等。

过程： 
1. 客户机的设备驱动程序发起 I/O 操作请求 
2. KVM 模块中的 I/O 操作捕获代码（Trap）拦截这次 I/O 请求 
3. 经过处理后将本次 I/O 请求的信息放到 I/O 共享页 （I/O sharing page），并通知用户空间的 QEMU 程序。 
4. QEMU 程序获得 I/O 操作的具体信息之后，交由硬件模拟代码来模拟出本次 I/O 操作。 
5. 模拟I/O完成后，QEMU 将结果放回 I/O 共享页，并通知 KMV 模块中的 I/O 操作捕获代码。 
6. KVM 模块的捕获代码读取 I/O 共享页中的操作结果，并把结果放回客户机。

注意：当客户机通过DMA （Direct Memory Access）访问大块I/O时，QEMU模拟程序不会把结果放进共享页中，而是通过内存映射的方式将结果直接写到客户机的内存中，然后通知KVM模块告诉客户机DMA操作已经完成。

这种方式的优点是可以模拟出各种各样的硬件设备； 
其缺点是每次 I/O 操作的路径比较长，需要多次上下文切换，也需要多次数据复制，所以性能较差。

准虚拟化（Para-Virtualization） I/O驱动 - virtio

virtio是Linux上的设备驱动标准框架。

KVM/Qemu的virtio的实现： 
在Guest OS内核中安装前端驱动（front-end），而在Qemu中实现后端驱动（back-end）. 前后端驱动通过vring通信，这就绕过了KVM内核模块，提高了I/O性能。

纯软件模拟的设备和 virtio 设备的区别：virtio 省去了纯模拟模式下的异常捕获环节，Guest OS 可以和 QEMU 的 I/O 模块直接通信。

Host 数据发到 Guest： 
1. KVM 通过中断的方式通知 QEMU 去获取数据，放到 virtio queue 中。 
2. KVM 再通知 Guest 去 virtio queue 中取数据。

virtio在Linux中的实现：

• 前端驱动：客户机中安装的驱动程序模块
• 后端驱动：在 QEMU 中实现，调用主机上的物理设备，或者完全由软件实现。
• virtio 层：虚拟队列接口，从概念上连接前端驱动和后端驱动。驱动可以根据需要使用不同数目的队列。比如 virtio-net 使用两个队列，virtio-block只使用一个队列。该队列是虚拟的，实际上是使用 virtio-ring 来实现的。
• virtio-ring：实现虚拟队列的环形缓冲。

vhost-net (kernel level virtio server)

virtio 在宿主机中的后端处理程序（backend）一般是由用户空间的QEMU提供的，然而如果对于网络 I/O 请求的后端处理能够在在内核空间来完成，则效率会更高，会提高网络吞吐量和减少网络延迟。 
在比较新的内核中有一个叫做“vhost-net”的驱动模块，它是作为一个内核级别的后端处理程序，将virtio-net的后端处理任务放到内核空间中执行，减少内核空间到用户空间的切换，从而提高效率。（根据 KVM 官网的这篇文章，vhost-net 能提供更低的延迟（latency）（比 e1000 虚拟网卡低 10%），和更高的吞吐量（throughput）（8倍于普通 virtio，大概 7~8 Gigabits/sec )。）

Redhat的多队列virtio（multi-queue）

多队列的virtio-net提供了一个随着vCPU数目的增加而增强网络性能的方法：使virtio可以同时使用多个virt-queue.

四、PCI/PCIe Pass-Through 和 SR-IOV

In computing, an input–output memory management unit (IOMMU) is a memory management unit (MMU) that connects a direct-memory-access–capable (DMA-capable) I/O bus to the main memory. Like a traditional MMU, which translates CPU-visible virtual addresses to physical addresses, the IOMMU maps device-visible virtual addresses (also called device addresses or I/O addresses in this context) to physical addresses. Some units also provide memory protection from faulty or malicious devices.

IOMMU (Input-Output memory management unit) 是一个内存管理模块（MMU），它连接具有DMA能力的I/O总线（DMA-capable I/O bus）到主存。 
传统的MMU将CPU认识的虚拟地址转换为物理地址；而IOMMU将设备认识的（device-visible）虚拟地址（也称为设备地址或此上下文中的I/O地址）映射到物理地址。 
一些单元也能提供内存保护功能。

主要的 PCI 设备类型：

• 网卡 - Network cards (wired or wireless)
• SCSI adapters
• 各种总线控制器 - Bus controllers: USB, PCMCIA, I2C, FireWire, IDE
• 显卡 - Graphics and video cards
• 声卡 - Sound cards

PCI/PCIe Pass-Through 原理

PCI/PCIe Pass-Through将宿主机的物理PCI设备直接分配给客户机使用。

通过硬件支持的VT-d技术将设备分给客户机后，在客户机看来，设备是物理上连接在PCI或者PCI-E总线上的，客户机对该设备的I/O交互操作和实际的物理设备操作完全一样，不需要或者很少需要 KVM 的参与。 
运行在 VT-d 平台上的 QEMU/KVM，可以分配网卡、磁盘控制器、USB控制器、VGA 显卡等设备供客户机直接使用。

Red Hat Enterprise Linux 6.0 及以上版本支持热插拔的 PCI 设备直接分配到虚拟机。

SR-IOV设备原理

VT-d 的性能非常好，但是它的物理设备只能分配给一个客户机使用。为了实现多个虚机共享一个物理设备，并且达到直接分配的目的，PCI-SIG 组织发布了 SR-IOV （Single Root I/O Virtualization and sharing） 规范，它定义了一个标准化的机制用以原生地支持实现多个客户机共享一个设备。不过，目前 SR-IOV （单根 I/O 虚拟化）最广泛地应用还是网卡上。

SR-IOV 使得一个单一的功能单元（比如，一个以太网端口）能看起来像多个独立的物理设备。一个带有SR-IOV功能的物理设备能被配置为多个功能单元。 
SR-IOV使用两种功能（function）： 
物理功能（Physical Functions，PF）：这是完整的带有 SR-IOV 能力的PCIe 设备。PF 能像普通 PCI 设备那样被发现、管理和配置。 
虚拟功能（Virtual Functions，VF）：简单的 PCIe 功能，它只能处理I/O。每个 VF 都是从 PF 中分离出来的。每个物理硬件都有一个 VF 数目的限制。一个 PF，能被虚拟成多个 VF 用于分配给多个虚拟机。

Hypervisor 能将一个或者多个 VF 分配给一个虚机。在某一时刻，一个 VF 只能被分配给一个虚机。一个虚机可以拥有多个 VF。在虚机的操作系统看来，一个 VF 网卡看起来和一个普通网卡没有区别。SR-IOV 驱动是在内核中实现的。

SR-IOV的条件：

• 需要 CPU 支持 Intel VT-x 和 VT-D （或者 AMD 的 SVM 和 IOMMU）
• 需要有支持 SR-IOV 规范的设备：目前这种设备较多，比如Intel的很多中高端网卡等。
• 需要 QEMU/KVM 的支持。

RedHat Linux 6.0 官方只完整测试了下面的几款 SR-IOV 网卡：

• Intel® 82576NS Gigabit Ethernet Controller ( igb 驱动)
• Intel® 82576EB Gigabit Ethernet Controller ( igb 驱动)
• Intel® 82599ES 10 Gigabit Ethernet Controller ( ixgbe 驱动)
• Intel® 82599EB 10 Gigabit Ethernet Controller ( ixgbe 驱动)

不足之处： 
- 对设备有依赖，目前只有部分设备支持 SR-IOV。RedHat Linux 只是测试了 Intel 的几款高端网卡。 
- 使用SR-IOV时不方便动态迁移客户机。这是因为这时候虚机直接使用主机上的物理设备，因此虚机的迁移（migiration）和保存（save）目前都不支持。

I/O 虚拟化方案的选择：

• I/O设备尽量使用准虚拟化（virtio 和 vhost_net）
• 如果需要实时迁移，不能使用 SR-IOV
• 对更高I/O要求又不需要实时迁移的，可以使用 SR-IOV
• 每种方案都有优势和不足，在特定环境下其性能有可能反而下降，因此在生产环境中使用各种虚拟化方式前需要经过完整测试

五、虚机迁移

动态迁移

如果源宿主机和目的宿主机共享存储系统，则只需要通过网络发送客户机的 vCPU 执行状态、内存中的内容、虚机设备的状态到目的主机上。否则，还需要将客户机的磁盘存储发到目的主机上。共享存储系统指的是源和目的虚机的镜像文件目录是在一个共享的存储上的。

在基于共享存储系统时，KVM 动态迁移的具体过程为：

1. 迁移开始时，客户机依然在宿主机上运行，与此同时，客户机的内存页被传输到目的主机上。
2. QEMU/KVM 会监控并记录下迁移过程中所有已被传输的内存页的任何修改，并在所有内存页都传输完成后即开始传输在前面过程中内存页的更改内容。
3. QEMU/KVM 会估计迁移过程中的传输速度，当剩余的内存数据量能够在一个可以设定的时间周期（默认 30 毫秒）内传输完成时，QEMU/KVM 会关闭源宿主机上的客户机，再将剩余的数据量传输到目的主机上，最后传输过来的内存内容在目的宿主机上恢复客户机的运行状态。
4. 至此，KVM 的动态迁移操作就完成了。迁移后的客户机尽可能与迁移前一直，除非目的主机上缺少一些配置，比如网桥等。

注意，当客户机中内存使用率非常大而且修改频繁时，内存中数据不断被修改的速度大于KVM能够传输的内存速度时，动态迁移的过程是完成不了的，这时候只能静态迁移。

参考文献

http://www.cnblogs.com/sammyliu/p/4543110.html 
http://www.cnblogs.com/sammyliu/p/4543597.html 
http://www.cnblogs.com/sammyliu/p/4543657.html 
http://www.cnblogs.com/sammyliu/p/4548194.html 
http://www.cnblogs.com/sammyliu/p/4572287.html

http://blog.csdn.net/nirendao/article/details/53470068