关于KVM与XEN 虚拟机性能测试

关于KVM与XEN 虚拟机性能测试

KVM工作原理：

KVM是一个基于Linux内核的虚拟机，它属于完全虚拟化范畴，从Linux-2.6.20开始被包含在Linux内核中。KVM基于x86硬件虚拟化技术，它的运行要求Intel VT-x或AMD SVM 的支持。

一般认为，虚拟机监控的实现模型有两类：监控模型（Hypervisor）和宿主机模型（Host-based）。由于监控模型需要进行处理器调度，还需要实现各种驱动程序，以支撑运行其上的虚拟机，因此实现难度上一般要大于宿主机模型。KVM的实现采用宿主机模型（Host-based），由于KVM是集成在Linux内核中的，因此可以自然地使用Linux内核提供的内存管理、多处理器支持等功能，易于实现，而且还可以随着Linux内核的发展而发展。另外，目前KVM的所有I/O虚拟化工作是借助Qemu完成的，也显著地降低了实现的工作量。以上可以说是KVM的优势所在。

分析KVM中与Intel VT-x相关的实现，不考虑KVM中与AMD SVM相关的实现，因此有关术语的使用与Intel VT-x保持一致。

VT-x提供了一套称作VMX（Virtual Machine eXtension）的新的工作模式，工作在该模式下的处理器又具有两类操作模式：VMX root operation和VMX non-root operation。通常，虚拟机监控器运行在VMX root operation模式下，即所谓的特权级-1，客户操作系统运行在VMX non-root operation模式下。VMX non-root operation模式仍保留4个特权级，对操作系统来说，VMX non-root operation模式与传统的x86处理器兼容，最大的差别在于当虚拟机执行一些访问全局资源的指令时将导致虚拟机退出操作（VM exit），从而使虚拟机监控器获得控制权，以便对访问全局资源的指令进行模拟。以后，虚拟机监控器可以通过虚拟机进入操作（VM entry）使虚拟机重新获得控制权。

其次，VT-x为系统编程接口状态的切换提供硬件支持。VT-x为每个虚拟机维护至少一个VMCS（Virtual Machine Control Structure）结构，其中保存了虚拟机和虚拟机监控器的系统编程接口状态。当执行VM exit和VM entry操作时，VT-x自动根据VMCS中的内容完成虚拟机和虚拟机监控器间的系统编程接口状态切换。为系统编程接口状态的切换提供硬件支持是必要的，因为x86处理器的系统编程接口相比应用编程接口要复杂的多，且在不停的变

化，如较新的处理器可能增加一些MSR（Model Specific Register），这使得单独依靠软件来实现系统编程接口的保存和恢复工作变得十分复杂。另外，VT-x还提供了一组指令，使得虚拟机监控器通过一条指令就可以完成虚拟机间的切换。

VT-x解决了ring deprivileging方法的一系列问题，从硬件上堵住了所谓的x86平台的虚拟化漏洞。由于操作系统所在的VMX non-root operation模式仍具有4个特权级，使得ring aliasing问题不存在了。同时，由于SYSENTER和SYSEXIT指令所引起的

adverse impact on guest transitions问题也不存在了；由于VT-x在VM exit和VM entry时完成系统编程接口的切换，也就是说虚拟机和虚拟机监控器拥有各自的GDT，也就拥有了各自的地址空间，解决了address space compression问题。同时，虚拟机和虚拟机监控器拥有各自的GDTR/IDTR等寄存器，在虚拟机中访问这些寄存器无需陷入，解决了nonfaulting accessing to privileged state问题，再者，VMCS中保存了虚拟机的段描述符高速缓存，因此在虚拟机切换时不会出现access to hidden state问题；通过对VMCS进行设置，可以使处理器在VMX non-root operation模式时的EFLAGS.IF失效，即该标志位不再对中断屏蔽产生影响，因此操作系统对EFLAGS.IF的频繁操作不会导致频繁的VM exit，解决了interrupt virtualization的问题。

VT-x提供了完备的处理器虚拟化机制，利用VT-x可以在单个硬件平台上虚拟出任意数量的虚拟处理器VCPU。VT-x除了解决了处理器虚拟化的问题之外，还为内存虚拟化和I/O 虚拟化提供了支撑。在内存虚拟化方面，VT-x为影子页表的实现提供了支撑，并且在较新的处理器中还提供了EPT机制，进一步提高了内存虚拟化的效率。在I/O虚拟化方面，通过I/O位图机制可以方便地实现对Programmed I/O的虚拟化，除此之外，VT-x还提供了中断事件退出机制和中断事件注入机制，方便对设备中断进行虚拟化。

kvm是一个独特的管理程序，kvm开发者们发明了一个方法让Linux内核自身变成一个管理程序，通过将KVM作为一个内核模块实现，在虚拟环境下Linux内核集成管理程序将其作为一个可加载的模块可以简化管理和提升性能。这可能是开发者将KVM添加到内核的主要原因。

这种方法有许多优势，通过添加虚拟化功能到一个标准的Linux内核，虚拟环境能从所有正在Linux内核上运行的工作中受益，在这种模式下，每个虚拟机都是一个常规的Linux 进程，通过Linux调度程序进行调度，通常，一个标准的Linux进程都有两个执行模式：内核模式和用户模式。对于应用程序而言用户模式是默认模式，当它需要一些来自内核的服务时就进入内核模式，如往磁盘上写入时。KVM添加了第三个模式：客户模式。

客户模式进程是运行在虚拟机内的，它非常象正常模式（无虚拟实例），有它自己的内核和用户空间变量、在客户模式下可以使用正常的kill和ps命令，因为无虚拟实例，KVM 虚拟机表现为一个正常的进程，能象其他进程一样被杀掉，KVM利用硬件虚拟技术虚拟处理器的形态，虚拟机的内存管理由内核直接处理，目前的版本I/O在用户空间处理，主要通过QEMU完成。一个典型的KVM安装包括以下部件：

一个管理虚拟硬件的设备驱动，这个驱动通过一个字符设备/dev/kvm陈列它的功能一个模拟pc硬件的用户空间部件，目前，这在用户空间处理，它是一个稍微改动过的QEMU进程。

I/O模型直接衍生于QEMU，支持写时复制磁盘映像和其他QEMU特征。

接下来引用厂家的流程图，做充分说明

（https://www.360docs.net/doc/aa12652214.html,/picture/detail/e19975b2d1beca1505adea44697be23f0c52c289?fro m=dialog更多高清大图）：

qemu-kvm虚拟设备创建流程图

kvm创建的三个文件描述符

qemu-kvm主要数据结构

原生ksm合并内存页实现流程图

Linux_Kernel_Meory

qemu-kvm相关

qemu-kvm网络虚拟化

qemu-kvm网络数据流走向图

XEN 工作原理

针对Xen 的体系结构进行了简单的描述，我们知道Xen 主要由Xen Hypervisor，Domain0，DomainU 三部分组成。下面通过Domain 0 与Domain U 的通信以及这三部分的交互来探讨一下Xen 的工作原理。

之前我们已经提到过Domain U 分为PV 客户系统和HVM 客户系统两种，我们首先讨论一下PV 客户系统，也就是半虚拟化操作系统工作原理。

首先我们需要知道在Domain 0 中有两个驱动Network Backend Driver 和Block Backend Driver，它们分别用来处理来自Domain U 的网络和本地磁盘请求。由于Xen Hypervisor 不会支持网络和磁盘请求的，因此一个PV（半虚拟化）客户系统必须通过和Xen Hypervisor、Domain 0 通信，从而来实现网络和磁盘请求。由于Xen 文档中已经探讨过PV 客户系统如何将一个数据写到本地硬盘，下面我们就来讨论一下PV 客户系统如何将一个数据发送到网络中去。在这之前我们首先要了解到一点，那就是Domain U PV Guest 中也包括两个驱动“PV Network Driver”和“PV Block Driver”，它们分别也是用来处理发送网络和本地磁盘请求用的，这与Domain 0 中的两个驱动是相对应的。

当一个PV 客户系统的网络设备驱动程序接收到一个发送数据请求的时候，并且通过

Xen Hypervisor 发送数据到本地网络设备（网卡之类的设备）中，这个网络设备是和Domain 0 共享的。在Domain 0 和Domain U 之间存在一个事件通道（event channel），通过该通道二者进行异步的域间中断通信。Domain 0 会接收到一个来自Xen Hypervisor 的中断，触发PV Network Backend Driver 访问上述网络设备，读取来自PV 客户系统的数据，然后将这些数据发送出去。

下图中事件通道表示为连接Domain 0 与Domain U 的一个区域，这是系统工作流的一个简化。事实上事件通道运行在Xen Hypervisor 中，通过Xenstored（Xenstored 维护一个信息档案，包括内存和建立在Domain 0 与Domain U 之间的事件通道。Domain 0 通过改变这个档案来设置和其他虚拟机的设备通道）中的特定中断实现，提供Domain 0 与Domain U 之间的快速共享网络设备。

KVM与XEN在技术方面的比较：

作为开源的虚拟化技术，对比Xen和kvm可以看到，Xen以6个无与伦比的

优势领先：更好的可用资源、平台支持、可管理性、实施、动态迁移和性能基准。

可用资源：Xen的问世要比kvm早4年之久（两者分别是2003年和2007年）。随着Citrix、Novell、Oracle、Sun、Ret Hat和Virtual Iron等公司在市场领域的实施，就比较容易找到精通Xen的IT技术人员，更容易让这些技术人员接受Xen 相关的培训、更容易得到Xen的咨询帮助以及获得Xen证书。企业管理协会（EMA：Enterprise Management Associates）2008年这对虚拟化和管理趋势的研究报告表明，这些关键因素占到那些抱怨缺少必要虚拟化技术资源和技术企业的60%。

平台支持：Xen在新版本中支持更多的主机和客体工作环境，包括泛虚拟化技术、硬件辅助支持以及修改过或未修改过的客体操作系统；对UNIX、Linux和Microsoft Windows的特定支持；包括芯片组，如x86、IA64和AMD、Fujitsu、IBM、Sun等公司的ARM，以及x86/64 CPU商家和Intel嵌入式的支持等。

可管理性：EMA在2009年度针对虚拟系统管理的研究结果表明：对于83%的企业来讲，在选择虚拟化技术过程中，管理是一项非常关键或者重要的因素。在对比Xen和kvm时，就可以看到Xen具有一个更加宽泛的第三方配给、备份、存储管理、P2V、容量规划、性能监控、进程自动化、安全和其它管理规则的社区，比如Citrix、IBM、CA、Novell或者Platespin、Enomaly、Microsoft以及HP等。

实施：无论kvm是“第一类”还是“第二类”，这都是语义上的概念。Xen的运行和管理都是在较低级别的（Ring 0）。甚至对于新虚拟机创建，客体机器并不需要像KVM那样共享内存块、CPU指令或者任何底层的Linux操作系统（虽然偶尔也会越权）。

KVM不支持动态迁移：过去在证明VMware ESX比Microsoft Hyper-V优越的最重要的一个观点也同样适用于Xen和kvm的比较，但是这是一个很大的问题。与KVM不同，Xen支持非中断的动态迁移，可以允许动态工作负载平衡和例行维护而几乎没有任何宕机时间。kvm的固有属性决定了其肯定有宕机时间。

性能：大多数Xen和kvm性能基准的对比都表明Xen具有更好的处理性能（接近于本地处理），只有在磁盘I/O方面略逊于kvm。进一步来讲，独立测试表明随着工作负载的增加kvm的性能逐渐下降。通常情况下，在试图支持四个以上的客体虚拟机时就会崩溃。Xen支持一个客体虚拟机的数量呈线性增长，可以支持30个以上工作负载同时运行。

更加深入广泛的Xen与kvm对比也将会表明Xen在虚拟网络支持、虚拟存储

支持、安全增强、高可用性、容错处理、电源管理、HPC或者实时支持、虚拟CPU 可扩展性、跨平台兼容性。虚拟机可移植性、虚拟应用设备市场以及已经建立起来的云服务社区等诸多方面都要比kvm优越。因此kvm只是在技术上比较与众不同，并且拥有几个不错的应用场景。但是作为企业级的服务器虚拟化技术，和Xen比起来，kvm尚有较大差距。

然后在实战中，由于xen和kvm，都是开源免费的虚拟化软件；

如果是xen或kvm虚拟windows，其中的子系统要支付许可费用。

如果是xen或kvm虚拟linux，那么虚拟化软件本身和其中的子系统无需产生任何费用。

从性能上来讲，虚拟windows，如果都能得到厂商的支持，那么，性能优化可以不用担心。这两款软件全都能达到主系统至少80%以上的性能（磁盘，CPU，网络，内存），如果是虚拟linux，建议首先使用xen，支持linux的半虚拟化，可以直接使用主系统的cpu和磁盘及网络资源，达到较少的虚拟化调度操作，可以达到非常高的性能，但xen操作复杂，维护成本较高。其次我们推荐kvm来虚拟linux，linux本身支持kvm的virtio技术，可以达到少量的虚拟化调度操作，得到较高的系统性能。

这就kvm和xen而言，如果虚拟windows，建议使用XEN，我们可以从厂商那里拿到针对windows优化过的磁盘和网络的驱动程序，可以达到较高的性能（几乎与hyper-v性能持平）。网络管理员、程序运维人员、或者使用基于Linux虚拟化用户经常遇到不同的项目或者程序。所以就需要查看虚拟化管理程序的定量比较结果，根据应用来选择最适合的虚拟机。已在本项测试实验中，我们比较了两个虚拟机管理程序:XEN与KVM。自从2003年公开发行版后，XEN一直是性能比较的主题,主要是因为它接近于实体机的性能和它所使用的半虚拟化技术。KVM 是一个在2007年初首次发布亮相的虚拟化产品。它支持CPU虚拟化，并充分利用现有的linux系统提供了一个集成的内核基础设施的虚拟化管理程序(而不是类似于XEN的独立虚拟机管理程序)，KVM自Linux 2.6.20之后集成在Linux的各个主要发行版本中。由于虚拟化产品的增多，随之产生了为比较两个虚拟机之间性能的测试软件。在本文中，我们使用了一款叫做benchvm的开源测试软件，帮助我们做一些压力测试与测试用例。这款软件能帮助我们验证一些测试结果。

本文测试环境都建立在Ubuntu Linux 8.04 AMD64位机器上。Linux内核本版号:2.6.24,XEN虚拟机版本3.2.1.kvm62是直接从Ubuntu安装包里面安装的。硬件机器配置如下：Dell OptiPlex 745 ，英特尔酷睿双核CPU 6600,4G内存，

250GB硬盘，双千兆网卡。我们的测试主要关注以下三方面：整体性能、性能隔离度、可扩展性。最后讨论的测试过程并给出了每一个方面的定量测试结果。

1、整体性能测试

为了测试整体性能，我们运行了CPU密集测试、磁盘读测试、磁盘写测试。通过一个实体的Linux作为基准，来比较XEN与KVM性能。

对于CPU密集测试，XEN的性能接近于Linux，而KVM性能要稍逊于XEN。在内核编译方面XEN只有Linux一半的性能，而KVM仍然稍逊于XEN，但是磁盘读写方面却要好于XEN，我们认为这可能是KVM的磁盘缓存的原因。Phoronix

测试套件很适合内核编译、磁盘读写性能测试。

2、性能隔离度

性能隔离度是衡量虚拟机受到其他极度消耗资源虚拟机的影响。我们使用了隔离度基准测试套件，并在四台机器上部署了SPECweb2009[5]，并在其中两台VM上部署了压力测试程序来增加机器的压力，使它们保持一定压力。测量这四台VM上的SPECweb2009的响应速率。使用没有压力的机器的测量数据作为基准数据。

在表2中我们给出了性能隔离度的测试结果。部署了压力测试的VM与正常VM表现出差异性。在表中数值则表示系统的响应速率。DNR表示的意思是“没有返回”（did not return）。一般造成DNR是服务器没有相应或者网络不通。在我们测试环境中可以排除网络不通的因素，所以认为是服务器没有回应的原因。

在下表中XEN表现出了比较好的CPU、磁盘、内存性能隔离度。尤其是磁盘方面表现出了优异的性能。但是在接收网络数据方面XEN隔离度表现一般，性能容易受到其他虚拟机的影响。在数据发送方面隔离度好些。

KVM在所有测试项中都表现出了优异的隔离性。尤其是在数据发送方面更是优秀，但是在数据接收与磁盘测试方面表现稍差。

3、可增容性

一个虚拟化系统的可增容性好坏，是根据虚拟机的数量多少来决定的。并且这些虚拟机没有任何性能损失。在这项测试中我们首先在一台VM中编译apache 的源代码，然后逐渐增加同样任务的VM。在图1中，较少的编译时间并且较多的VM意味着可增容性好。

对于XEN,我们增加虚拟机数量的时候，编译apache的时间VM的数量相比较是呈线性增长的。这表示可增容性能优秀。XEN能够平均分配资源。当我们把虚拟机数量提高到27个的时候仍然有返回响应。这表示XEN的可增容性相当好。

对于KVM，当我们增加虚拟机数量到9的时候。有一台VM系统宕机。当我们增加到13的时候，有4台系统宕机.当我们增加到18的时候，有7台系统宕

机。当增加到21台的时候整个系统宕机，所以从21之后就没有返回数据了。这说明KVM没有很好的增容性。

4、结束语

我们提供了一个关于XEN与KVM整体性能定量的比较结果。两者最大的区别在于可增容性。KVM下面的VM数量增加到9的时候，有许多问题暴露。但是KVM 的隔离性测试要好于XEN。总体性能比较的结果稍微复杂。可以在在实际应用中根据具体的应用的侧重点选择相对应的虚拟机管理系统

综上所述，

在有授权的情况下，虚拟linux，建议使用xen，如考虑到需要降低管理维护和学习成本，建议使用KVM。

在没有授权的情况下，虚拟windows，建议使用kvm。

在没有授权的情况下，虚拟LINUX，建议使用xen。

POC简述：

因为思杰完成对XenSource的收购，所以从服务器虚拟化，到网络虚拟化，再到交付到客

户桌面的桌面虚拟化，思杰完成了一整套产品的生态循环，原厂工程师对项目全程提供7*24的技术支持，而CENTOS免费使用，却没有技术支持。两者的更新，都是随着各自厂家的发布，按照惯例，都是半年发布一次。

这里采用的XENSERVER和CENTOS配置相同CPU，内存，存储，然后分别给其虚拟机分配2vCPU，1.5G内存，15G硬盘空间，并创建两个虚拟机。

1、首先在LINUX上创建一个50G的硬盘空间，命令为WIN7。

2、然后点击创建

3、一路NEXT，与其他虚拟机安装无异。

4、安装完成

5、通过SPICE协议登陆建立好的虚拟桌面