微软公司最近推出的Hyper-V管理程序令虚拟化市场震动不小。笔者决定对几大虚拟化厂商的产品性能做一番评估，对他们的可用性、管理性和迁移能力等关键特性进行盘点。

　　微软公司和VMware接受了我们的邀请，但开源虚拟化厂商思杰系统公司和Linux管理程序厂商红帽公司由于正在进行产品修订而无法参与此次的评估。因此此次虚拟化产品的评估就演变为微软公司Hyper-V管理程序与VMware的市场龙头产品ESX之间的尖峰对决。

　　首先我们来关注管理程序的性能测试。接下来的部分主要涉及可用性、管理性和迁移能力。哪个管理程序运行速度更快取决于几个因素。举例来说，它取决于虚拟机客户端操作系统如何分配给可用的主机中央处理器和内存，也取决于对性能有限制作用的很多产品方面的局限性。

　　那就是说，VMware的ESX管理程序在这场虚拟化性能之争中取得了全面胜利——由于受到服务器处理器核心和内存容量，以及我们所测试的管理程序的限制，我们只同时运行了6个虚拟机。从虚拟机测试结果显示，ESX在我们进行的基础载荷、多重中央处理器虚拟机托管和磁盘输入/输出性能测试等多个方面都广受赞誉。

　　而微软的Hyper-V管理程序只在少数几个方面表现尚佳，那就是当我们用到微软推出的驱动程序特别设置时，Hyper-V管理程序正式支持的唯一Linux平台——NOVELL的SuSE Enterprise Linux有助于性能的提升。

　　虚拟机管理程序的设计是要将服务器的硬件资源应用到多重客户端操作系统。物理中央处理器（也被称为核心）可以作为虚拟化中央处理器使用到客户端操作系统。但是没必要拘泥于一个核心对一个虚拟化中央处理器的对应关系。实际的比率取决于管理程序。在我们的测试中，我们让管理程序来决定中央处理器资源如何作为虚拟化中央处理器使用。

　　操作系统能在管理程序的局限下利用服务器资源。举例来说，四核处理器对于操作系统来说可以作为一个中央处理器使用。在其他情况下，四个中央处理器也可以虚拟为8个虚拟中央处理器。在这种假定下相对闲置的虚拟机就不能连续使用高峰时段的中央处理器资源。对于虚拟机还有一些其他的局限性，比如与之相关联的磁盘尺寸，网络输入/输出，服务器内的CD/DVD使用的客户端等。

　　Hyper-V和ESX管理程序都存在的一个性能局限是：无论运行的客户端操作系统实例是什么类型和版本，或者物理核心实际可用的数量，能为任何一台虚拟机所用的虚拟中央处理器的数量只有4个。另外，如果你选择将SLES 10 32位版本作为客户端操作系统运行，你会发现微软只能让这些客户端使用单核虚拟中央处理器。

　　虚拟化管理程序厂商在虚拟中央处理器可用量上的局限性来自于两方面。首先，用大容量的中央处理器跟踪虚拟机客户端会涉及到大量的内存管理和中央处理器内部通讯的问题（包括处理器高速缓存，指令的传输途径和输入/输出状态控制），这是很难做到的事情。其二，虚拟机客户端托管的需求被认为是服务器整合的行为，而需要整合的服务器多数情况下都是单核中央处理器的硬件。

　　这些管理程序硬件资源分配的局限性为我们在测试平台上如何利用16核中央处理器惠普DL580G5进行测评奠定了基础。

　　正如我之前所强调的，微软公司可以正式支持的客户端实例是自己的操作系统和NOVELL的SLES 10操作系统（运行Service Packs 1和2版本）。这也是为什么我们只用Windows 2008和SLES 10.2操作系统进行虚拟机测试的原因。其他的操作系统（比如红帽的Linux、Debian Linux和NetBSD）也可以运行，但用户在使用这些操作系统时无法取得相应的调试或者技术支持。

　　在我们进行测试时，微软公司使用了他们的Hyper-V Linux Interface Connector（Hyper-V LinuxIC）工具包，这是一套对优化SLES客户端系统中央处理器，内存，磁盘和网络输入/输出有所帮助的驱动程序。我们确实看到使用了这个工具包后性能得到了改进，但是每个客户端只能使用一个虚拟中央处理器。对称多处理环境无法为Hyper-V LinuxIC工具包提供支持。

　　虚拟化的成本

　　业界对服务器虚拟化的关注日益加强。以前只能托管一个虚拟化实例的硬件系统如今可以打包多重操作系统实例。对于数据中心标准化操作系统的配置也有所帮助。

　　但是世界上没有免费的午餐。管理程序成为虚拟化服务器的基本操作系统。我们的第一个测试测算的是虚拟化成本，当同样的操作系统使用管理程序作为操作系统和硬件系统之间的缓冲器时，我们让操作系统在这种操作模式下的裸机上运行，通过对他们处理性能的比较来得出测评的结论。性能的差异也计入管理程序管理角色的理论值。

　　在我们的测试中，当我们将本地操作系统实例向单个虚拟中央处理器分配的虚拟实例迁移时，测试的范围从运行Windows 2008操作系统的ESX的2.5％到运行SLEX的Hyper-V的超过12％。每个管理程序的基础性能成本都有所不同，但VMware在本轮测试中取得了理论上的胜利。之所以说是理论上的是因为这只是运行一个客户端虚拟机平台的个别案例。

　　当中央处理器的数量供单个虚拟机客户端使用，虚拟化成本的变化范围更加广泛。当我们允许单个操作系统实例SMP访问4个虚拟中央处理器时，支持SLES实例的VMware ESX记录在案的最低成本低于4％。与之相反的是，当Hyper-V支持SLES实例时，运行所需的最高成本超过15％。

　　综上所述，Hyper-V管理程序在本轮测试中败下阵来，但在支持Windows虚拟机上相差无几，而在支持SLES上差距明显。这可能是因为Hyper-V LinuxIC工具包无法应用于对称多处理环境，所以LinuxIC工具包对性能提升的帮助作用没有派上用场。

　　用商业应用软件负载测试虚拟机

　　第二轮的性能测试是当虚拟机添加到系统中时，对虚拟机应用软件重复性能进行比较。我们会对支持客户端操作系统的一台，三台到六台虚拟机性能进行跟踪。当每个虚拟机被分配给自己的虚拟中央处理器，然后又递进为4个虚拟中央处理器时，我们对性能进行测试。这种负载测试从理论上来说性能的差异会有所扩大。

　　本轮我们选择的测试工具为在分布式环境中模拟分布式处理SPECjbb2005基准，这也是目前业界应用最为广泛的基准之一。SPECjbb2005测试使用的是在单个主机或者虚拟机实例中运行的Java应用软件组件。第一个组件模拟的是通过第二个组件处理的客户机程序线程，第二个组件是一种存储和反馈在处理一套Java对象（模拟数据库引擎）中的商业逻辑引擎，对反复进行的处理循环数据进行记录。SPECjbb2005根据中央处理器的数量和主机上可用的内存选择测试的参数。测试输出的数据是每秒的基础性操作或每个测试轮的波谱值。

　　我们完成了每个管理程序的多种运行测试，即每个虚拟机使用自己的虚拟中央处理器运行测试和每个虚拟机运行四个虚拟中央处理器的测试。

　　我们用一台、三台和六台虚拟机对这两种环境进行了测试。首先我们是用Windows 2008 Server作为主机操作系统进行测试，然后用SLES10.2作为主机操作系统进行测试。

　　在第一轮测试中我们采用的是每个虚拟中央处理器运行一个虚拟机客户端操作系统和每个操作系统实例访问有限内存（2GB）的比例关系。这种资源的分配在服务器整合的过程中具有代表性。过时的单核中央处理器硬件在物理机向虚拟机迁移的过程中被重新整合。

　　Windows 2008和SLES 10.2虚拟性能和物理性能速度几乎一样快，三种客户端操作系统的运行速度也比较接近。VMware在此次测试中略占优势。运行三种虚拟机的Hyper-V管理程序比运行Windows 2008操作系统的VMWare虚拟机要低1，400bops，比运行SLES虚拟机的ESX管理程序要低1，800bops。在这六台虚拟机上，这两种管理程序与直接在服务器上运行的本地操作系统相比性能上都表现不俗。

　　事实上，整合实例没必要通过同步运行SPECjbb2005测试来满负荷进行。多数操作系统和应用软件实例的连续中央处理器使用率远远低于SPECjbb2005基准的测试负荷，现实情况下的中央处理器使用要随意的多。我们强调虚拟机和管理程序在满负荷运行下的表现是为了更清楚的说明每个管理程序在繁杂的负载下是如何相互影响的。

　　在第二轮的反复性虚拟机测试中，我们允许每个虚拟机都能访问4个虚拟中央处理器，这也是本次测试中每个管理程序所能访问的处理器的最大数量。每个虚拟机能使用的内存容量仍然限定为2GB，因为这是整合和测试操作系统时所能达到的常规限度。本轮测试环节更容易的说明了虚拟机是如何被应用到虚拟数据库应用程序，大容量交易系统和其他对中央处理器可用性要求较高的应用软件中。

　　前文我们已经介绍过我们是用单个虚拟机客户端作为基线，然后增加为三个虚拟机直到最后六个虚拟机的总数。在首轮测试中，我们强调的是虚拟化测试的成本，VMware在运行Windows 2008客户端操作系统时以微弱优势领先，在运行SLE210.2虚拟机时则领先了1100bops。这是因为对称多处理环境无法支持微软公司的LinuxIC工具包，导致运行SLES的Hyper-V管理程序的性能在本轮测试中失去LinuxIC工具包的助力而败下阵来。

　　在测试中，三个虚拟机每个都用到了四个虚拟中央处理器，也就是说有12个虚拟中央处理器在参与测试。由于在我们的测试平台上（即在测试中使用管理程序虚拟化的平台）服务器里有16个物理中央处理器，有4个中央处理器处于闲置状态。Hyper-V管理程序在实例测试中以平均超过6，500bops领先于VMware ESX。我们的测试结论认为Hyper-V能够发现那些额外可用的硬件资源并加以利用，而ESX没有做到这一点。

　　在我们做最后一轮测试时我们进行了超额认购。超额认购是一种超出实际可用量进行物理中央处理器分配的方法，这种方法能允许虚拟机于其他的虚拟机客户端共享他们所分配的虚拟中央处理器。同时它也是一种虚拟机运行闲置中央处理器资源的有用的过程，因为它能让你部署更多的虚拟机。

　　磁盘输入/输出能力的虚拟化测试

　　我们使用英特尔的IOMeter对托管的虚拟机磁盘输入/输出能力进行了跟踪测试。IOMeter通过对测试路径中读写子系统的工作线程测试了磁盘子系统。测试结论是根据IOmeter在一轮测试循环结束时记录的每秒输入/输出数据总结而来。

　　输入/输出数字高的虚拟机则为胜出。

　　在虚拟化的世界里，虚拟机客户端实例必须同时满足内部磁盘和存储区域网络资源的需求。当硬件通过虚拟化作为客户端操作系统使用时，位于硬件和客户端虚拟机之间的管理程序层就要使用自己的磁盘驱动程序来管理磁盘活动。增加虚拟化客户端来区分客户端虚拟机操作系统和应用软件实例中的硬件资源。尽管本地操作系统驱动程序表现良好，但管理程序管理许多客户端系统所需通讯的能力已经成为一项非常复杂工程，随着应用软件性能提升的放缓，延迟和功效的作用也日益凸显。

　　我们对每个虚拟机实例运行IOmeter来测算管理程序如何对磁盘进行数据的输入输出。我们使用世界上通用的比例即数据写入占到70%，读取占到30%。在我们的配比中倾向于数据写入的原因在于他们不会受到操作系统的太大影响，而数据读取的测算容易出现偏差。

　　在用IOmeter进行测试时，我们采用本地操作系统的输入/输出性能作为操作系统磁盘输入/输出速度的基线。然后我们在6个虚拟机客户端操作系统的管理程序环境中执行同样的测试过程。我们想知道管理程序与他们使用自己的操作系统作为本地实例相比，是否能为虚拟机客户端提供更多的磁盘信道可用性。

　　在每个虚拟机访问单个虚拟中央处理器的SLES虚拟机时，我们再次看到Hyper-V虚拟机客户端实例受益于微软的Linux IC，性能有了显著的改进，因为SLES Linux虚拟机在Hyper-V管理程序上比VMware ESX运行的更快。测试还显示如果SLES不使用LinuxIC套装，数据读写速度就会有所放缓，与VMware ESX的性能表现基本相同。当我们不使用LinuxIC套装来测试Hyper-V管理程序时，SLES虚拟机平均的输入/输出速度为每秒8378万次，大约比使用SLES的VMware磁盘输入/输出速度要快5%。不过Hyper-V管理程序在运行自己的Windows 2008 Server作为客户端操作系统时的磁盘输入/输出速度并非同样出色。

　　当我们在对称多处理环境（即4个虚拟中央处理器分配给6个虚拟机）中测试磁盘输入/输出活动时，我们有意超额使用了服务器的数量来看看管理程序在每个客户端操作系统中一定的磁盘需求下，是否能够维持他们的磁盘信道活动。由于管理程序也是他们自己的操作系统，因此它必须非常谨慎的重新分配磁盘的数据读取时间，在客户端之间执行清晰而有效的切换。

　　在这些测试中，这两款管理程序的输入/输出速度都比裸机上运行的本地操作系统的输入/输出性能表现要好。但VMware ESX是本轮的赢家。当虚拟机将Windows 2008作为主机操作系统运行时，所记录在案的每秒输入/输出速度为1733.63百万次，Hyper-V的每秒输入/输出速度为874.29百万次，本地操作系统性能为每秒输入/输出速度为712.97百万次。由于对称多处理环境无法支持LinuxIC工具包，因此Hyper-V在LinuxIC工具包上的优势不复存在了。

　　综述

　　虽然微软公司的威力在某些核心领域中已经开始凸显——比如针对虚拟机性能的单个中央处理器资源的整合，但VMware在虚拟化市场上的领导者地位让它在我们性能测试的多个方面都尽显王者之风。由于他们之间存在着激烈的竞争，因此这两家厂商都在不遗余力的刷新着性能记录。思杰、Sun和将开源软件的触角伸向商业领域的红帽公司也都紧随其后。虚拟机性能之争将是我们密切关注的领域，让我们一起拭目以待吧。