1.引言

现代计算机具有足够强大的能力来利用虚拟化技术支持多个虚拟机（VM：virtualmachines），并且在每个虚拟机上各自运行单独的操作系统实例。这直接导致了虚拟机技术发展的又一个春天。在本文中，我们提出了Xen，一个高性能的用于资源管理的虚拟机监视器（VMM：VMmonitor）。Xen能够支持的应用比如：serverconsolidation，co-locatedhostingfacilities，distributedwebservices，securecomputingplatforms[12，16]和applicationmobility.

成功地对一台机器进行划分，使它能够支持多个操作系统的并发执行，这个过程具有很多的挑战。首先，虚拟机必须是彼此相隔离的：如果一个虚拟机的执行会影响另一个的性能，这是不可以被接受的。这一点在操作各个虚拟机的用户相互间并不信任的情况下显得特别重要。其次，它必须支持多种多样的不同操作系统以提供给各种异构（heterogeneity）的流行应用的支持（//这里的异构指的是应用开发依托的操作系统不同，因此在实现上也就有很大差异，使得应用并不能够跨平台移植，因为Xen不需要对应用程序进行修改，那么它就必须支持各种常用的操作系统；所谓流行的应用，就是那些大家常用的、必需的应用）。第三，由虚拟化技术引入的性能开销必须要小。

Xen操控（//host：操作和控制）的是常用的操作系统，但是需要对操作系统中的某些相关部分进行一些修改。在本文中描述和评估的Xen原型系统能够支持多个我们研发的XenoLinuxguestOS实例的并发执行；每个实例都给出了和非虚拟化情况下的Linux2.4中相同的应用二进制接口。目前，我们对WindowsXP到Xen的移植还没有完全完成，但是已经能够运行简单的用户空间进程。移植NetBSD的工作也在进行中。

Xen使得用户能够动态地实例化一个操作系统以执行他们需要的应用。在XenoServer项目[15，35]中，我们在ISP或者Internetexchange（//布置在这些场合中经济划算而且又具有战略意义的地方）的标准服务器硬件上配置了Xen.我们在启动一个新的虚拟机的时候需要执行许可控制（admissioncontrol），希望每个虚拟机能够以某种方式为它需要的资源付出代价。我们在其它文章中讨论过我们在这个方向上的思路和方法[21]；现在这篇文章则将焦点关注于虚拟机。

现在有一些方法用于构建能够在共享的机器上操控多个应用和服务器（//server：这里提到的server应该是大规模应用的意思，比如数据库服务器）的系统。也许最简单的方法就是部署一个或多个运行着标准操作系统（如Linux或者Windows）的主机，然后允许用户们安装文件和启动进程—应用间的保护是由传统的操作系统技术提供的（//这里提到的做法，就是类似并行机性质的，各个节点都是独立的主机，但是一个应用可以在多个节点上面并行执行）。实验显示：由于要针对各个脱节（//supposedlydisjoint：逻辑上脱节，指的是应用不具有连贯性/兼容性，所以针对每个应用都要单独配置一次，如果能想办法将前后有关联的应用放在一起执行，可以大大减少相关的开销，如配置开销，通信开销等等）的应用进行复杂的配置，这些配置过程导致的交互行为会使系统管理任务迅速成为时间消耗巨大的任务。

更重要的是，这样的系统不能够充分地支持性能隔离；某个进程的调度优先级，存储要求，网络通信量和磁盘访问等等特征都会影响到其它进程的性能。如果是在资源供应充足而且用户群体是限定（比如计算网格或者PlanetLab平台实验）的情况下，这个系统还是可以接受的。但是当资源是供不应求的时候，或者用户间不相协作（//uncooperative：不相协作，比如用户间的需求有冲突，那么一定会互相影响的）的时候就不行了。一个解决这个问题的方法是改进对操作系统性能隔离的支持。这已经在resourcecontainers，Linux/RK，QLinux和SILK中被或多或少地实现了。这些方法中存在着一个难点是难以确保所有的资源都能够正确地分配给有相应资源需求的进程。例如，缓冲区cache或者存储页面的替换算法导致的在应用间的复杂的交互行为（//比如存储页面替换的时候，某个进程的页面替换序列会干扰到其它进程的，要免除这个影响就需要有复杂的机制用于进程间的协调）。这就是存在于操作系统中的“QoS干扰问题（QoScrosstalk）”。在低层采用多路执行技术能够缓解这个问题带来的影响，这已经在Exokerne和Nemesis操作系统中得到证明。在这些操作系统中，任务间无意识的或者不受欢迎的交互行为被最小化了。

我们使用了同样的基本方法来构建Xen.Xen就是以整个操作系统的粒度复用物理资源，它能够提供在操作系统间的性能隔离。相对于进程级的资源复用，Xen要允许一定范围内的guestOS“和平”共存，而并非去指定一个特殊的应用二进制接口（//如果限定了应用二进制接口，就意味着只能支持某个特定的操作系统）。为了获得这种灵活性就必须付出一些代价—无论是在初始化过程（比如，boot和resume与fork和exec的比较）中，还是在资源消费上，运行一个完整的操作系统与运行一个进程相比分量都要重得多。

为了达到我们的能够支持多至100个被操控的操作系统实例的目标，我们认为这些代价是值得付出的。付出这些代价后获得的系统允许单个用户在资源受控的形式下，直接运行那些不需要修改的二进制代码或者二进制代码集合（例如，后端为PostgreSQL的Apache服务器）。更进一步的，因为用户能够动态地精确创建他们的软件所需要的执行环境，所以这个系统也就提供了在非常高的层次上的灵活性。另外，在各种服务和应用间的配置交互也是可以避免的（例如，每个Windows实例都有它们自己的寄存器文件）。

本文的余下部分是这样组织的：第2部分解释了我们的虚拟化方法和Xen的工作概况。第3部分描述了我们的设计和实现的关键特征。第4部分给出了使用业界标准的测试程序评估运行在Xen上的XenoLinux与单独的Linux，VMwareWorkstation和用户模式Linux（UML）的性能比较结果。最后的第5部分讨论了未来的工作并作了总结。

2.XEN：方法和概述

在传统的VMM中，虚拟硬件的功能是与底层机器上的真实硬件完全相同的。这种“完全虚拟化”（fullvirtualization）的方法最显而易见的好处在于操作系统可以不经任何修改就直接在虚拟硬件上运行，但是它也有很多缺点。特别是针对那些当前被广泛应用的IA32（或者称作x86）架构，这种方法带来的缺陷更是不容忽视。

x86架构的设计从来就不支持完全的虚拟化。如果要正确实现x86架构虚拟化，VMM就必须能够对某几条特定的“超级指令（supervisorinstruction）”进行操作。但是，如果在没有足够特权的情况下执行这些超级指令会导致“沉默的失败（//failsilently：如果特权级不够，那么会直接导致执行失败，不会产生其它响应）”，而并非产生一个便于我们使用的陷阱（trap）。

另外，将x86架构中的MMU进行有效的虚拟化也是一件很困难的事情。这些问题是可以被解决的，但是在解决的同时必须要付出操作复杂度增加和系统性能降低的代价。VMwareESXServer[10]需要动态地重写那些被VMM操控的机器码部分，在其中有可能需要VMM干涉的地方插入陷阱操作（//在什么地方插入陷阱操作，是在程序运行起来后才知道的，所以需要动态地重写相关代码）。因为务必要对所有那些不能够引起陷阱的特权指令进行捕捉和操作，所以这种转换（//动态重写代码）要被应用于整个guestOS的内核（导致了相关的转换，执行和缓存等开销）。ESXServer实现中采用的技术是建立系统结构（systemstructure）（比如页表）的影子版本，通过为每一次“更新”操作设立陷阱来解决虚拟页表和物理页表的一致性问题（//具体细节还是要看ESXServer的说明）。但是在处理“更新密集”型的操作（如创建新的应用进程）的时候，该方法会带来高昂的开销。

除了x86架构非常复杂的原因，还有一些其它方面的争论反对“完全虚拟化”。其中值得一提的是，被操控的操作系统在一些情况下需要接触到真实的资源。例如，提供真实时间和虚拟时间以允许guestOS能够更好地支持“时间敏感”型的任务，还可以正确地操作TCP超时和RTT估算；给出真实的机器地址以允许guestOS能够利用超级页（superpage）或者页染色（pagecoloring）等方法改进性能。

我们提出的虚拟机抽象能够避免完全虚拟化带来的种种缺陷。这种虚拟机抽象和底层硬件相似却并不完全相同，因此被称之为“准虚拟化”（//paravirtualization：或者翻译为半虚拟化？后面译文沿用准虚拟化）方法。这种方法虽然需要对guestOS进行一些改动，但是它能够改善性能。还有特别重要的一点需要说明：准虚拟化方法不会对应用二进制接口（ABI）进行修改，因此用户也就不用修改那些在guestOS上执行的应用程序。

我们进行的关于准虚拟化方法的讨论要遵循以下一些规则：

1.最基本的是要支持那些不经改动的应用二进制文件的执行，即用户不用对应用程序做针对Xen的转换。因此我们必须虚拟化现有的标准ABI所需的全部体系结构特征。

2.很重要的一点是要支持完整的多应用操作系统。这就需要将在单个guestOS实例中的复杂的服务器配置虚拟化（//例如，如果guestOS上配置了ftp服务，那么虚拟硬件就要打开相应端口）。

3.准虚拟化务必要有很高的性能。另外针对那些不协作（//uncooperative：这里的不协作是指硬件架构不支持共享，所以才需要资源隔离）的机器架构，如x86架构，准虚拟化还需要能够提供很强的资源隔离能力。

4.在协作（cooperative）的机器架构上，准虚拟化方法要能够完全地隐藏资源虚拟化带来的影响，减少guestOS在正确性和性能上面临的风险。

请注意，我们在这里提出的准虚拟化的x86抽象的方法是与最近在Denali项目中提出的方法有很大差异的。Denali是为了支持数以千计的运行着网络服务的虚拟机而设计的。这些网络服务中绝大部分是小规模的，不流行（//应用的不流行也就说明了运行该应用的环境比较少，所以只要针对这些相应的特定环境作专门的虚拟化即可）的应用。与之相反的是，Xen的设计最终要支持近100个运行着业界标准应用和服务的虚拟机。由于设计目标的极大差异，我们不妨将Denali的设计选择和我们自己的设计规则做一个有益的讨论。

首先，Denali不需要关注现有的ABI，因此他们的VM接口忽略掉了相关的架构特征。例如，Denali并不完全支持x86的分段机制，但是这一点却是在NetBSD，Linux和WindowsXP等操作系统的ABI中都有提出并且被广泛使用。例如，线程库中经常会使用分段机制来寻址线程局部数据。

其次，Denali的实现没有解决在单个guestOS中支持多个应用（applicationmultiplexing）的问题，也没有解决多地址空间的问题。应用被显式地链接到IlwacoguestOS实例上，这么做在某种意义上类似于之前在Exokernel中的libOS[23].因此每个虚拟机只能操控一个单用户单应用的没有保护措施的所谓的“操作系统”。在Xen中，与之相反，每个虚拟机上能够操控一个真正的操作系统。这个操作系统上能够安全地执行数以千计个不经改动的用户级进程。虽然Denali号称开发了一个虚拟MMU原型能够对其在该领域有所帮助，但是我们没有看到公开的技术细节和评估报告。

再次，在Denali体系结构中，是由VMM执行全部的内存与磁盘间的页面调度的。这可能是与虚拟层缺乏存储管理支持有关。由VMM完成页面调度是与我们的性能隔离目标相违背的：那些“有恶意”的虚拟机可能会故意产生抖动行为，导致其它虚拟机的CPU时间和磁盘带宽被不公平地剥夺（//VMM监控很多VM，各个VM上再跑操作系统，所以如果很多事情都放在VMM中做必然会影响到各个VM；所以要把一些事情放在上面的操作系统做来达到隔离性）。在Xen中，我们希望每个guestOS在其自己分配到的内存空间和磁盘区域内执行它自己的页面调度（此前已经有self-paging的方法被提出）。

最后，Denali为机器的全部资源虚拟了“名字空间”。这样的话，如果一个VM不能够“叫出”另一个VM下辖的资源的名字，那么该VM就不能够访问这些资源（例如，Denali中的VM并不知道硬件地址，它们只看得到Denali创建的虚拟地址）。与此相对，我们认为hypervisor中的安全访问控制已经足以确保安全性；此外，就像之前讨论过的，当前在guestOS是否应该能够直接看到物理资源这一点上存在着很热烈的关于正确性和性能的争论。

在后续的章节里，我们将描述Xen提出的虚拟机抽象，然后将讨论如何将一个guestOS作必要的改动以适应Xen.在这篇文章里我们定义了一些术语要提醒大家注意。例如，术语guestOS是指Xen能够操控的操作系统之一；术语domain是指一个运行中的虚拟机，在其上有一个guestOS在执行。program和process之间的区别和传统系统中的区别类似。我们称Xen本身为hypervisor，因为它运行的特权级要比它所操控的guestOS中的supervisorcode运行的特权级更高。

2.1虚拟机接口

一个准虚拟化的x86接口主要包括了系统中的三个大的方面：存储管理，CPU和设备I/O.在下面，我们将依次介绍各个机器子系统的情况，并讨论在我们的准虚拟化架构中是如何体现的。虽然在我们的实现中，有相当一部分，如存储管理，是专门针对x86的，但是实际上还有很多方面（比如我们虚拟的CPU和I/O设备）都是可以很容易地应用于其它机器架构上的。更进一步地说，在与RISC架构在实现上有差异的很多地方，x86往往表现出的是该方面最坏情况时的情形。例如，对硬件页表进行有效的虚拟化就比虚拟化一个软件管理的TLB困难很多。

存储

管理分段不能够使用具有完全特权级的段描述符，不能够与线性地址空间的最顶部交迭（//因为最顶部是Xen）。

分页guest

OS直接对硬件页表做读访问，但是更新（//就是写）是分批进行的而且要经过hypervisor确认。一个domain可以被分配在不连续的页面上。

CPU保护guestOS必须运行在低于Xen的特权级上。

异常guestOS必须将异常句柄的描述符表在Xen中记录。除了页面错误外，其它句柄和真实的x86架构相同。

系统调用guestOS为系统调用提供一个“快速”的句柄。允许应用直接调用它所在的guestOS，而不必间接地通过Xen完成每次调用。

中断硬件中断被一个轻量级的事件系统替换。

时间每个guestOS具有一个定时器接口，可以得到“真实的”和“虚拟的”时间。

设备I/O网络，磁盘，……虚拟设备访问起来很简单。数据传递使用的是异步I/O环。由一个事件机制替换硬件中断来发布通告。

2.1.1存储管理

虚拟化存储毫无疑问是准虚拟化一个体系结构中最困难的部分，它包括hypervisor所需的机制和移植各个guest

OS所需的改动。如果在架构中提供了由软件管理的TLB的话，那么这个任务会变得轻松些，它们可以以比较简单的方式被有效地虚拟化[13].带标记的TLB是另外一个在大部分RISC架构（这些RISC架构主要用于构建服务器，比如Alpha，MIPS和SPARC）中支持的有用特征。其中，每个TLB项都有和地址空间标识符相关的标记，这使得hypervisor和各个guestOS能够有效地在被隔离开的地址空间内共存。这时在执行转移（//transferringexecution：在进程执行间切换的时候，执行的指令序列从一个进程转移到另一个进程，称为执行转移）的时候，是不需要刷新（flush）整个TLB（//只对具有和自己的地址空间标识符相吻合的TLB项进行操作）。

不幸的是，x86架构并没有由软件管理的TLB；取而代之的是在发生TLB失效的时候，处理器会自动通过遍历硬件页表结构来处理。因此为了获得最好的可能达到的性能，当前地址空间内所有的有效页传输）都要在硬件可访问的页表中给出（//最好情况理应如此，但实际如何做得到呢？）。此外，因为TLB是没有标记的，所以地址空间的切换需要整个TLB的刷新。在这些限制下，我们作出了两个决定：（i）由guestOS负责分配和管理硬件页表，这么做最小化了Xen对页表操作的影响，确保了安全性和隔离性；（ii）Xen处于每个地址空间的最顶部的64MB空间内，因此避免了在进入和离开hypervisor时进行TLB刷新操作（//这个要看源代码才能最后搞清楚）。

每当guestOS需要一个新的页表，例如创建了一个新进程，它就在自己保留的内存空间内分配和初始化一个页面，并且将其在Xen中记录。此时操作系统必须放弃对页表存储空间直接写的权限：所有后续的更新操作都必须由Xen进行确认。这就在很多方面限制了更新操作，包括只允许操作系统它自己所属的页进行映射操作，不允许对页表进行可写的映射操作。guestOS可以成批地进行更新操作以减少每次更新都要进入hypervisor带来的代价（//因为每次更新都要hypervisor确认）。每个地址空间顶部的64MB区域是保留给Xen的，是不能够被guestOS访问或者重新进行映射的。因为任何通常的x86架构中的ABI都不会使用到这个区域中的地址，所以这个约束不会破坏到应用程序的兼容性。

分段机制也是以类似的方式，通过对硬件段描述符表的更新确认来进行虚拟化（//这样做就达到虚拟化的目的了么？哦，应该是Xen在确认后接着由Xen执行，嗯）。对于x86架构上段描述符的限制只有：（i）它们的特权级别必须比Xen要低；（ii）它们不能够对地址空间中Xen的保留部分进行访问。

2.1.2CPU

虚拟化CPU对guestOS提出了几个要求。因为hypervisor插在操作系统的下层违背了惯常的关于操作系统在整个系统中特权最高的假设。为了保护hypervisor不会受到操作系统不正确行为的影响（即domain不受另一个domain的影响），guestOS就必须被改造为能够运行在较低的特权级上。

很多处理器体系结构只是提供了两个特权级。在这些情况下，guestOS和应用程序共享较低的特权级。同时，guestOS运行在单独的地址空间中以保护自己不会受到应用程序执行的影响。guestOS通过hypervisor设定虚拟的特权级和改变当前的地址空间来间接地和应用之间进行控制传递。另外，如果处理器的TLB支持地址空间标记，那么也就可以避免TLB刷新带来的高昂代价。

在x86架构上有效地实现特权级的虚拟化是可能的，因为x86架构在硬件上支持四个不同的特权级。x86架构的特权级往往用圈（ring）来表示，从ring0（最高特权）到ring3（最低特权）。操作系统的代码运行在ring0这个特权级上，因为再没有其它的ring能够执行那些特权指令。ring3通常用于执行应用代码。就我们所知，自OS/2起到现在的各个知名的x86架构上的操作系统都还没有利用ring1和ring2这两个特权级的。那么，任何遵循这个通常的安排的操作系统（//没有利用ring1和ring2）就都可以移植到Xen上来。

这个移植过程只需要做一些改动使操作系统改为运行在ring1特权级上。这就防止了guestOS会直接执行特权指令，也保证了操作系统与运行在ring3上的应用程序之间相隔离的安全性。

特权指令需要被Xen确认和执行以达到准虚拟化的目的，这主要应用于诸如安置新的页表，或者在处理器idle时放弃之（而不是去hlt它）等操作。因为只有Xen有足够高的特权级来执行这些指令，所以任何guestOS试图直接运行特权指令都会失败，后果要么是“沉默”要么是产生错误。

异常，包括内存错误和软件陷阱，都可以在x86架构的基础上直接进行虚拟化。有一个表，内容为对每类异常进行描述的句柄。表中所列的异常都是在Xen中有记录的，以用作确认。表中给出的句柄都是与真正的x86硬件中相同的；之所以这一点是可能做到的，主要是因为在我们的准虚拟化架构中，异常堆栈框架是没有被修改的。唯一的一个改动是在页面错误句柄上。因为该句柄的操作需要从特权处理器寄存器（CR2）中读出出错的地址；但是这是不可能的（//因为特权级别不够了），我们就将它（//页面错误句柄？CR2的值？）写入扩展的堆栈框架中（后来发现，在移植XP的时候，将这个值写入一个预先商定的共享存储位置上要比修改堆栈框架简单一些）。当系统在ring0以外执行时有异常发生，Xen的句柄就会在guestOS堆栈中创建一个异常堆栈框架的拷贝，并且会将控制交给相应的已经记录过的异常句柄。

典型的，只有两类异常会经常发生而影响到系统的性能：系统调用（一般都是通过软件异常实现）和页面错误。我们让每个guestOS都记录一个“快速的”异常操作句柄来改进系统调用的性能。这个异常操作句柄可以直接由处理器使用，而不必非要间接地经过ring0；这个句柄在放置进硬件异常列表中之前就是经过确认的（//所以不必经过Xen）。不幸的是，我们不可能使用同样的技术来处理页面错误句柄，因为只有那些运行在ring0的代码才能够从寄存器CR2中读出错误的地址；因此，页面错误必须要经过Xen才能提交，Xen保存该寄存器的值供来自ring1的访问使用。

当Xen发现异常产生时，它会对异常句柄进行确认以确保安全性。这只需要检查句柄的代码段中是否含有指明要在ring0中执行的操作。既然没有guestOS能够创建这样一个段，那么只需要将专门的段选择符和少量的保留在Xen中的静态值作比较即可。除了这点以外，任何其它的句柄问题都会在异常传播（exceptionpropagation）（//一个异常导致了另一个异常的产生）的过程中被修正。例如，如果句柄缺少相应代码段或者句柄没有分配到内存页，那么在Xen为将控制返回给句柄而执行iret指令的时候就会有一个相应的错误产生。Xen通过检查出错的程序计数器值来检测这些“双错误（//doublefaults：之前已经出错了，现在到了iret已经是第二个错误了；第二个错误是由第一个错误传播而来）”：如果地址是处于异常虚拟化的代码中（//说明异常处理没有完成，iret没成功），那么guestOS就要被终止。

对于直接的系统调用句柄来说，这种“懒惰（//第一个错误发生的时候，没有被检查到；直到Xen执行了iret之后才报错）”的检查也是安全的：当CPU试图直接跳至guestOS句柄的时候，会发生访问错误（//之前的过程都一样，只是直接的系统调用是不经过Xen的）。在这种情况下，产生错误的地址将处于Xen之外（因为Xen不会去执行guestOS系统调用），因此错误就以上文讲过的一般方式进行虚拟化即可。如果由于错误的传播导致了进一步的“双错误”，那么guestOS会像上文谈及的一样被终止。

2.1.3设备I/O

在完全虚拟化环境下需要仿真现有的硬件设备，而Xen不同于此。Xen给出了一套清楚、简单的设备抽象。这就使得我们能够设计一个接口以有效地满足我们对保护性和隔离性的需求。为了做到这一点，I/O和各个domain之间的数据传递都是要经过Xen的，可以使用的方法有共享内存，异步缓冲区描述符环等。这些方法能够在Xen有效地执行确认检查（例如，检查缓冲区是否包括在了domain的存储空间内）的同时，为在系统中的竖直方向上传递缓冲区畔⑻峁┝艘桓龈咝阅艿耐ㄐ呕

落在实处虚拟化技术应用 虚拟化能够解决软件安装的困境？

评论 (0) All