1.3　KVM简介

1.3.1　KVM的历史

KVM全称是Kernel-based Virtual Machine，即基于内核的虚拟机，是采用硬件虚拟化技术的全虚拟化解决方案。

图1-6　类型1和类型2的Hypervisor

KVM最初是由Qumranet公司的Avi Kivity开发的，作为他们的VDI产品的后台虚拟化解决方案。为了简化开发，Avi Kivity并没有选择从底层开始新写一个Hypervisor，而是选择了基于Linux kernel，通过加载模块使Linux kernel本身变成一个Hypervisor。2006年10月，在先后完成了基本功能、动态迁移以及主要的性能优化之后，Qumranet正式对外宣布了KVM的诞生。同月，KVM模块的源代码被正式纳入Linux kernel，成为内核源代码的一部分。作为一个功能和成熟度都逊于Xen的项目，在这么快的时间内被内核社区接纳，主要原因在于：

1）在虚拟化方兴未艾的当时，内核社区急于将虚拟化的支持包含在内，但是Xen取代内核由自身管理系统资源的架构引起了内核开发人员的不满和抵触。

2）Xen诞生于硬件虚拟化技术出现之前，所以它在设计上采用了半虚拟化的方式，这让Xen采用硬件虚拟化技术有了更多的历史包袱，不如KVM新兵上阵一身轻。

2008年9月4日，Redhat公司以1.07亿美元收购了Qumranet公司，包括它的KVM开源项目和开发人员。自此，Redhat开始在其RHEL发行版中集成KVM，逐步取代Xen，并从RHEL7开始，正式不支持Xen。

1.3.2　KVM的功能概览

KVM从诞生开始就定位于基于硬件虚拟化支持的全虚拟化实现。它以内核模块的形式加载之后，就将Linux内核变成了一个Hypervisor，但硬件管理等还是通过Linux kernel来完成的，所以它是一个典型的Type 2 Hypervisor，如图1-7所示。

图1-7　KVM功能框架

一个KVM客户机对应于一个Linux进程，每个vCPU则是这个进程下的一个线程，还有单独的处理IO的线程，也在一个线程组内。所以，宿主机上各个客户机是由宿主机内核像调度普通进程一样调度的，即可以通过Linux的各种进程调度的手段来实现不同客户机的权限限定、优先级等功能。

客户机所看到的硬件设备是QEMU模拟出来的（不包括VT-d透传的设备，详见6.2节），当客户机对模拟设备进行操作时，由QEMU截获并转换为对实际的物理设备（可能设置都不实际物理地存在）的驱动操作来完成。

下面介绍一些KVM的功能特性。

1.内存管理

KVM依赖Linux内核进行内存管理。上面提到，一个KVM客户机就是一个普通的Linux进程，所以，客户机的“物理内存”就是宿主机内核管理的普通进程的虚拟内存。进而，Linux内存管理的机制，如大页、KSM（Kernel Same Page Merge，内核的同页合并）、NUMA（Non-Uniform Memory Arch，非一致性内存架构）、通过mmap的进程间共享内存，统统可以应用到客户机内存管理上。

早期时候，客户机自身内存访问落实到真实的宿主机的物理内存的机制叫影子页表（Shadow Page Table）。KVM Hypervisor为每个客户机准备一份影子页表，与客户机自身页表建立一一对应的关系。客户机自身页表描述的是GVA→GPA的映射关系；影子页表描述的是GPA→HPA的映射关系。当客户机操作自身页表的时候，KVM就相应地更新影子页表。比如，当客户机第一次访问某个物理页的时候，由于Linux给进程的内存通常都是拖延到最后要访问的一刻才实际分配的，所以，此时影子页表中这个页表项是空的，KVM Hypervisor会像处理通常的缺页异常那样，把这个物理页补上，再返回客户机执行的上下文中，由客户机继续完成它的缺页异常。

影子页表的机制是比较拗口，执行的代价也是比较大的。所以，后来，这种靠软件的GVA→GPA→HVA→HPA的转换被硬件逻辑取代了，大大提高了执行效率。这就是Intel的EPT或者AMD的NPT技术，两家的方法类似，都是通过一组可以被硬件识别的数据结构，不用KVM建立并维护额外的影子页表，由硬件自动算出GPA→HPA。现在的KVM默认都打开了EPT/NPT功能。

2.存储和客户机镜像的格式

严格来说，这是QEMU的功能特性。

KVM能够使用Linux支持的任何存储来存储虚拟机镜像，包括具有IDE、SCSI和SATA的本地磁盘，网络附加存储（NAS）（包括NFS和SAMBA/CIFS），或者支持iSCSI和光线通道的SAN。多路径I/O可用于改进存储吞吐量和提供冗余。

由于KVM是Linux内核的一部分，它可以利用所有领先存储供应商都支持的一种成熟且可靠的存储基础架构，它的存储堆栈在生产部署方面具有良好的记录。

KVM还支持全局文件系统（GFS2）等共享文件系统上的虚拟机镜像，以允许客户机镜像在多个宿主机之间共享或使用逻辑卷共享。磁盘镜像支持稀疏文件形式，支持通过仅在虚拟机需要时分配存储空间，而不是提前分配整个存储空间，这就提高了存储利用率。KVM的原生磁盘格式为QCOW2，它支持快照，允许多级快照、压缩和加密。

3.实时迁移

KVM支持实时迁移，这提供了在宿主机之间转移正在运行的客户机而不中断服务的能力。实时迁移对用户是透明的，客户机保持打开，网络连接保持活动，用户应用程序也持续运行，但客户机转移到了一个新的宿主机上。

除了实时迁移，KVM支持将客户机的当前状态（快照，snapshot）保存到磁盘，以允许存储并在以后恢复它。

4.设备驱动程序

KVM支持混合虚拟化，其中半虚拟化的驱动程序安装在客户机操作系统中，允许虚拟机使用优化的I/O接口而不使用模拟的设备，从而为网络和块设备提供高性能的I/O。

KVM使用的半虚拟化的驱动程序是IBM和Redhat联合Linux社区开发的VirtIO标准；它是一个与Hypervisor独立的、构建设备驱动程序的接口，允许多种Hypervisor使用一组相同的设备驱动程序，能够实现更好的对客户机的互操作性。

同时，KVM也支持Intel的VT-d技术，通过将宿主机的PCI总线上的设备透传（pass-through）给客户机，让客户机可以直接使用原生的驱动程序高效地使用这些设备。这种使用是几乎不需要Hypervisor的介入的。

5.性能和可伸缩性

KVM也继承了Linux的性能和可伸缩性。KVM在CPU、内存、网络、磁盘等虚拟化性能上表现出色，大多都在原生系统的95%以上。KVM的伸缩性也非常好，支持拥有多达288个vCPU和4TB RAM的客户机，对于宿主机上可以同时运行的客户机数量，软件上无上限。

这意味着，任何要求非常苛刻的应用程序工作负载都可以运行在KVM虚拟机上。

1.3.3　KVM的现状

至本书写作时，KVM已经10周岁了。10年之间，得益于与Linux天然一体以及Redhat的倾力打造，KVM已经成为Openstack用户选择的最主流的Hypervisor（因为KVM是Openstack的默认Hypervisor）。来自Openstack的调查显示，KVM占到87%以上的部署份额，并且（笔者认为）还会继续增大。可以说，KVM已经主宰了公有云部署的Hypervisor市场；而在私有云部署方面，尤其大公司内部私有云部署，还是VMware的地盘，目前受到HyperV的竞争。

功能上，虚拟化发展到今天，各个Hypervisor的主要功能都趋同。KVM作为后起之秀，并且在公有云上广泛部署，其功能的完备性是毋庸置疑的。并且由于其开源性，反而较少一些出于商业目的的限制，比如一篇文章（ftp//public.dhe.ibm.com/linux/pdfs/Clabby_Analytics_-_VMware_v_KVM.pdf）中比较VMware EXS与KVM，就是一个例子。

性能上，作为同样开源的Hypervisor，KVM和Xen都很优秀，都能达到原生系统95%以上的效率（CPU、内存、网络、磁盘等benchmark衡量），KVM甚至还略微好过Xen一点点。与微软的Hyper-V相比，KVM似乎略逊于最新的Windows 2016上的HyperV，而好于Windows 2012 R2上的HyperV，但这是微软的一家之言，笔者没有重新测试验证。其他与诸如VMware EXS等的性能比较，网上也可以找到很多，读者可以自行搜索。总的来说，即使各有优劣，虚拟化技术发展到今天已经成熟，KVM也是如此。

1.3.4　KVM的展望

经过10年的发展，KVM已经成熟。那么，接下来KVM会怎样进一步发展呢？

1）大规模部署尚有挑战。KVM是Openstack和oVirt选择的默认Hypervisor，因而实际的广泛部署常常是大规模的（large scale，scalability）。这种大规模，一方面指高并发、高密度，即一台宿主机上支持尽可能多的客户机；另一方面，也指大规模的单个客户机，即单个客户机配备尽可能多的vCPU和内存等资源，典型的，这类需求来自高性能计算（HPC）领域。随着硬件尤其是CPU硬件技术的不停发展（物理的processor越来越多），这种虚拟化的大规模方面的需求也在不停地增大，并且这不是简单数量的增加，这种增加会伴随着新的挑战等着KVM开发者去解决，比如热迁移的宕机时间（downtime）就是其中一例。

2）实时性（Realtime）。近几年一个新的趋势就是NFV（Network Functions Virtualization，网络功能的虚拟化），它指将原先物理的网络设备搬到一个个虚拟的客户机上，以便更好地实现软件定义网络的愿景。网络设备对实时性的要求是非常高的；而不巧，NFV的开源平台OPNFV选择了Openstack，尽管Openstack向下支持各种Hypervisor，但如前文所说，KVM是其默认以及主要部署的选择，所以NFV实时性的要求责无旁贷地落到了KVM头上，NFV-KVM项目应运而生，它作为OPNFV的子项目主要解决KVM在实时性方面受到的挑战。

3）安全是永恒的主题/话题。就像网络病毒永远不停地演变推陈出新一样，新时代的IT架构的主体，云/虚拟化，也会一直受到各类恶意攻击的骚扰，从而陷入道高一尺魔高一丈的循环。Hypervisor的开发者、应用者会一直从如何更好地隔离客户机、更少的Hypervisor干预等方面入手，增加虚拟化的安全性。KVM作为Type 2的Hypervisor，天然地与Host OS有关联，安全性方面的话题更引人注目。同时，硬件厂商如Intel，也会从硬件层面不停地推出新的安全方面的功能（feature），KVM从软件方面也要跟上脚步，使能（enable）之。

4）性能调优。如同一句广告词说的：“进无止境”。一方面，新的功能代码的不停引入总会给性能调优开辟新的空间；另一方面，老的功能的实现也许还有更好的方法。还有，新的硬件功能的出现，也是性能调优永恒的动力源泉。