Xen and the Art of Virtualizati-系统所翻译
关键词: Xen
Part 1 — Xen and the Art of Virtualization — Xen和虚拟化技术
1. INTRODUCTION — 引言
现代计算机具有足够强大的能力来利用虚拟化技术支持多个虚拟机(VM: virtual machines),并且在每个虚拟机上各自运行单独的操作系统实例。这直接导致了虚拟机技术发展的又一个春天。在本文中,我们提出了Xen,一个高性能的用于资源管理的虚拟机监视器(VMM: VM monitor)。Xen能够支持的应用比如:server consolidation[42,8],co-located hosting facilities[14],distributed web services[43],secure computing platforms[12,16]和application mobility[26,37]。
成功地对一台机器进行划分,使它能够支持多个操作系统的并发执行,这个过程具有很多的挑战。首先,虚拟机必须是彼此相隔离的:如果一个虚拟机的执行会影响另一个的性能,这是不可以被接受的。这一点在操作各个虚拟机的用户相互间并不信任的情况下显得特别重要。其次,它必须支持多种多样的不同操作系统以提供给各种异构(heterogeneity)的流行应用的支持(//这里的异构指的是应用开发依托的操作系统不同,因此在实现上也就有很大差异,使得应用并不能够跨平台移植,因为Xen不需要对应用程序进行修改,那么它就必须支持各种常用的操作系统;所谓流行的应用,就是那些大家常用的、必需的应用)。第三,由虚拟化技术引入的性能开销必须要小。
Xen操控(//host:操作和控制)的是常用的操作系统,但是需要对操作系统中的某些相关部分进行一些修改。在本文中描述和评估的Xen原型系统能够支持多个我们研发的XenoLinux guest OS(//guest OS:术语,不知道翻译成什么合适?)实例的并发执行;每个实例都给出了和非虚拟化情况下的Linux 2.4中相同的应用二进制接口。目前,我们对Windows XP到Xen的移植还没有完全完成,但是已经能够运行简单的用户空间进程。移植NetBSD的工作也在进行中(//此文成文于2003年,参考网站上的其它文档,目前已经有了更新的进展)。
Xen使得用户能够动态地实例化一个操作系统以执行他们需要的应用。在XenoServer项目[15,35]中,我们在ISP或者Internet exchange的标准服务器硬件上配置了Xen。我们在启动一个新的虚拟机的时候需要执行许可控制(admission control),希望每个虚拟机能够以某种方式为它需要的资源付出代价(//We perform admission control when starting new virtual machines and expect each VM to pay in some fashion for the resources it requires.这句没太明白,从引文[21]中也没看出什么眉目 L)。我们在其它文章中讨论过我们在这个方向上的思路和方法[21];现在这篇文章则将焦点关注于虚拟机。
现在有一些方法用于构建能够在共享的机器上操控多个应用和服务器(//server:这里提到的server应该是大规模应用的意思,比如数据库服务器)的系统。也许最简单的方法就是部署一个或多个运行着标准操作系统(如Linux或者Windows)的主机,然后允许用户们安装文件和启动进程 — 应用间的保护是由传统的操作系统技术提供的(//这里提到的做法,就是类似并行机性质的,各个节点都是独立的主机,但是一个应用可以在多个节点上面并行执行)。实验显示:由于要针对各个脱节(//supposedly disjoint:逻辑上脱节,指的是应用不具有连贯性/兼容性,所以针对每个应用都要单独配置一次,如果能想办法将前后有关联的应用放在一起执行,可以大大减少相关的开销,如配置开销,通信开销等等)的应用进行复杂的配置,这些配置过程导致的交互行为会使系统管理任务迅速成为时间消耗巨大的任务。
更重要的是,这样的系统不能够充分地支持性能隔离;某个进程的调度优先级,存储要求,网络通信量和磁盘访问等等特征都会影响到其它进程的性能。如果是在资源供应充足而且用户群体是限定(比如计算网格或者PlanetLab平台实验[33])的情况下,这个系统还是可以接受的。但是当资源是供不应求的时候,或者用户间不相协作(//uncooperative:不相协作,比如用户间的需求有冲突,那么一定会互相影响的)的时候就不行了。
一个解决这个问题的方法是改进对操作系统性能隔离的支持。这已经在resource containers[3],Linux/RK[32],QLinux[40]和SILK[4]中被或多或少地实现了。这些方法中存在着一个难点是难以确保所有的资源都能够正确地分配给有相应资源需求的进程。例如,缓冲区cache或者存储页面的替换算法导致的在应用间的复杂的交互行为(//比如存储页面替换的时候,某个进程的页面替换序列会干扰到其它进程的,要免除这个影响就需要有复杂的机制用于进程间的协调)。这就是存在于操作系统中的“QoS干扰问题(QoS crosstalk)”[41]。在低层采用多路执行技术能够缓解这个问题带来的影响,这已经在Exokernel[23]和Nemesis[27]操作系统中得到证明。在这些操作系统中,任务间无意识的或者不受欢迎的交互行为被最小化了。
我们使用了同样的基本方法来构建Xen。Xen就是以整个操作系统的粒度复用物理资源,它能够提供在操作系统间的性能隔离。相对于进程级的资源复用,Xen要允许一定范围内的guest OS“和平”共存,而并非去指定一个特殊的应用二进制接口(//如果限定了应用二进制接口,就意味着只能支持某个特定的操作系统)。为了获得这种灵活性就必须付出一些代价 — 无论是在初始化过程(比如,boot和resume与fork和exec的比较)中,还是在资源消费上,运行一个完整的操作系统与运行一个进程相比分量都要重得多。
为了达到我们的能够支持多至100个被操控的操作系统实例的目标,我们认为这些代价是值得付出的。付出这些代价后获得的系统允许单个用户在资源受控的形式下,直接运行那些不需要修改的二进制代码或者二进制代码集合(例如,后端为PostgreSQL的Apache服务器)。更进一步的,因为用户能够动态地精确创建他们的软件所需要的执行环境,所以这个系统也就提供了在非常高的层次上的灵活性。另外,在各种服务和应用间的配置交互也是可以避免的(例如,每个Windows实例都有它们自己的寄存器文件)。
本文的余下部分是这样组织的:第2部分解释了我们的虚拟化方法和Xen的工作概况。第3部分描述了我们的设计和实现的关键特征。第4部分给出了使用业界标准的测试程序评估运行在Xen上的XenoLinux与单独的Linux,VMware Workstation和用户模式Linux(UML)的性能比较结果。第5部分回顾了相关工作,最后的第6部分讨论了未来的工作并作了总结。
Part 2 — Xen and the Art of Virtualization — Xen和虚拟化技术
2. XEN: APPROACH & OVERVIEW — XEN:方法和概述
在传统的VMM中,虚拟硬件的功能是与底层机器上的真实硬件完全相同的[38]。这种“完全虚拟化”(full virtualization)的方法最显而易见的好处在于操作系统可以不经任何修改就直接在虚拟硬件上运行,但是它也有很多缺点。特别是针对那些当前被广泛应用的IA32(或者称作x86)架构,这种方法带来的缺陷更是不容忽视。
x86架构的设计从来就不支持完全的虚拟化。如果要正确实现x86架构虚拟化,VMM就必须能够对某几条特定的“超级指令(supervisor instruction)”进行操作。但是,如果在没有足够特权的情况下执行这些超级指令会导致“沉默的失败(//fail silently:如果特权级不够,那么会直接导致执行失败,不会产生其它响应)”,而并非产生一个便于我们使用的陷阱(trap)[36]。另外,将x86架构中的MMU进行有效的虚拟化也是一件很困难的事情。这些问题是可以被解决的,但是在解决的同时必须要付出操作复杂度增加和系统性能降低的代价。VMware ESX Server[10]需要动态地重写那些被VMM操控的机器码部分,在其中有可能需要VMM干涉的地方插入陷阱操作(//在什么地方插入陷阱操作,是在程序运行起来后才知道的,所以需要动态地重写相关代码)。因为务必要对所有那些不能够引起陷阱的特权指令进行捕捉和操作,所以这种转换(//动态重写代码)要被应用于整个guest OS的内核(导致了相关的转换,执行和缓存等开销)。ESX Server实现中采用的技术是建立系统结构(system structure)(比如页表)的影子版本,通过为每一次“更新”操作设立陷阱来解决虚拟页表和物理页表的一致性问题(//具体细节还是要看ESX Server的说明)。但是在处理“更新密集”型的操作(如创建新的应用进程)的时候,该方法会带来高昂的开销。
除了x86架构非常复杂的原因,还有一些其它方面的争论反对“完全虚拟化”。其中值得一提的是,被操控的操作系统在一些情况下需要接触到真实的资源。例如,提供真实时间和虚拟时间以允许guest OS能够更好地支持“时间敏感”型的任务,还可以正确地操作TCP超时和RTT估算;给出真实的机器地址以允许guest OS能够利用超级页(superpage)[30]或者页染色(page coloring)[24]等方法改进性能。
我们提出的虚拟机抽象能够避免完全虚拟化带来的种种缺陷。这种虚拟机抽象和底层硬件相似却并不完全相同,因此被称之为“准虚拟化”(//paravirtualization:或者翻译为半虚拟化?后面译文沿用准虚拟化)方法[43]。这种方法虽然需要对guest OS进行一些改动,但是它能够改善性能。还有特别重要的一点需要说明:准虚拟化方法不会对应用二进制接口(ABI)进行修改,因此用户也就不用修改那些在guest OS上执行的应用程序。
我们进行的关于准虚拟化方法的讨论要遵循以下一些规则:
1. 最基本的是要支持那些不经改动的应用二进制文件的执行,即用户不用对应用程序做针对Xen的转换。因此我们必须虚拟化现有的标准ABI所需的全部体系结构特征。
2. 很重要的一点是要支持完整的多应用操作系统。这就需要将在单个guest OS实例中的复杂的服务器配置虚拟化(//例如,如果guest OS上配置了ftp服务,那么虚拟硬件就要打开相应端口)。
3. 准虚拟化务必要有很高的性能。另外针对那些不协作(//uncooperative:这里的不协作是指硬件架构不支持共享,所以才需要资源隔离)的机器架构,如x86架构,准虚拟化还需要能够提供很强的资源隔离能力。
4. 在协作(cooperative)的机器架构上,准虚拟化方法要能够完全地隐藏资源虚拟化带来的影响,减少guest OS在正确性和性能上面临的风险(//Even on cooperative machine architectures, completely hiding the effects of resource virtualization from guest OSes risks both correctness and performance.翻译得不好)。
请注意,我们在这里提出的准虚拟化的x86抽象的方法是与最近在Denali项目[44]中提出的方法有很大差异的。Denali是为了支持数以千计的运行着网络服务的虚拟机而设计的。这些网络服务中绝大部分是小规模的,不流行(//应用的不流行也就说明了运行该应用的环境比较少,所以只要针对这些相应的特定环境作专门的虚拟化即可)的应用。与之相反的是,Xen的设计最终要支持近100个运行着业界标准应用和服务的虚拟机。由于设计目标的极大差异,我们不妨将Denali的设计选择和我们自己的设计规则做一个有益的讨论。
首先,Denali不需要关注现有的ABI,因此他们的VM接口忽略掉了相关的架构特征。例如,Denali并不完全支持x86的分段机制,但是这一点却是在NetBSD,Linux和Windows XP等操作系统的ABI中都有提出并且被广泛使用。例如,线程库中经常会使用分段机制来寻址线程局部数据。
其次,Denali的实现没有解决在单个guest OS中支持多个应用(application multiplexing)的问题,也没有解决多地址空间的问题。应用被显式地链接到Ilwaco guest OS实例上,这么做在某种意义上类似于之前在Exokernel中的libOS[23]。因此每个虚拟机只能操控一个单用户单应用的没有保护措施的所谓的“操作系统”。在Xen中,与之相反,每个虚拟机上能够操控一个真正的操作系统。这个操作系统上能够安全地执行数以千计个不经改动的用户级进程。虽然Denali号称开发了一个虚拟MMU原型能够对其在该领域有所帮助[44],但是我们没有看到公开的技术细节和评估报告。
再次,在Denali体系结构中,是由VMM执行全部的内存与磁盘间的页面调度的。这可能是与虚拟层缺乏存储管理支持有关。由VMM完成页面调度是与我们的性能隔离目标相违背的:那些“有恶意”的虚拟机可能会故意产生抖动行为,导致其它虚拟机的CPU时间和磁盘带宽被不公平地剥夺(//VMM监控很多VM,各个VM上再跑操作系统,所以如果很多事情都放在VMM中做必然会影响到各个VM;所以要把一些事情放在上面的操作系统做来达到隔离性)。在Xen中,我们希望每个guest OS在其自己分配到的内存空间和磁盘区域内执行它自己的页面调度(此前已经有self-paging的方法被提出[20])。
最后,Denali为机器的全部资源虚拟了“名字空间”。这样的话,如果一个VM不能够“叫出”另一个VM下辖的资源的名字,那么该VM就不能够访问这些资源(例如,Denali中的VM并不知道硬件地址,它们只看得到Denali创建的虚拟地址)。与此相对,我们认为hypervisor中的安全访问控制已经足以确保安全性;此外,就像之前讨论过的,当前在guest OS是否应该能够直接看到物理资源这一点上存在着很热烈的关于正确性和性能的争论。
在后续的章节里,我们将描述Xen提出的虚拟机抽象,然后将讨论如何将一个guest OS作必要的改动以适应Xen。在这篇文章里我们定义了一些术语要提醒大家注意。例如,术语guest OS是指Xen能够操控的操作系统之一;术语domain是指一个运行中的虚拟机,在其上有一个guest OS在执行。program和process之间的区别和传统系统中的区别类似。我们称Xen本身为hypervisor,因为它运行的特权级要比它所操控的guest OS中的supervisor code运行的特权级更高。
2.1 The Virtual Machine Interface — 虚拟机接口
表1中给出了一个准虚拟化的x86接口的概述,主要包括了系统中的三个大的方面:存储管理,CPU和设备I/O。在下面,我们将依次介绍各个机器子系统的情况,并讨论在我们的准虚拟化架构中是如何体现的。虽然在我们的实现中,有相当一部分,如存储管理,是专门针对x86的,但是实际上还有很多方面(比如我们虚拟的CPU和I/O设备)都是可以很容易地应用于其它机器架构上的。更进一步地说,在与RISC架构在实现上有差异的很多地方,x86往往表现出的是该方面最坏情况时的情形(//这句话有意思,x86架构并不先进)。例如,对硬件页表进行有效的虚拟化就比虚拟化一个软件管理的TLB困难很多。
存储
管理
分段
不能够使用具有完全特权级的段描述符,不能够与线性地址空间的最顶部交迭(//因为最顶部是Xen)。
Scatter-gather DMA方式是与block DMA方式相对应的一种DMA方式。
在DMA传输数据的过程中,要求源物理地址和目标物理地址必须是连续的。但是在某些计算机体系中,如IA架构,连续的存储器地址在物理上不一定是连续的,所以DMA传输要分成多次完成。
如果在传输完一块物理上连续的数据后引起一次中断,然后再由主机进行下一块物理上连续的数据传输,那么这种方式就为block DMA方式。
Scatter-gather DMA方式则不同,它使用一个链表描述物理上不连续的存储空间,然后把链表首地址告诉DMA master。DMA master在传输完一块物理连续的数据后,不用发起中断,而是根据链表来传输下一块物理上连续的数据,直到传输完毕后再发起一次中断。
很显然,scatter-gather DMA方式比block DMA方式效率高。
Part 5 — Xen and the Art of Virtualization — Xen和虚拟化技术
5. RELATED WORK — 相关工作
虚拟化技术被应用在商业化和研究型操作系统上已经有近30年了。IBM VM/370[19,38]最先使用了虚拟化技术以提供对先前存留的代码的支持。VMware[10]和Connectix[8]采用了将常用的PC硬件进行虚拟化的方法,允许多个操作系统在同一台主机上运行。所有这些例子都对底层硬件(至少是底层硬件的一个子集)进行了完全虚拟化的实现,而并非是准虚拟化的方法提供给guest OS一个修改后的接口。正如我们的评估结果中给出的:完全虚拟化虽然能够更容易地支持商业市售的操作系统,但是却大大降低了性能。
VMM方法还被Disco用于将常用的操作系统高效地运行在ccNUMA机器上[7,18]。其间要对被操控的操作系统做少量的改动,以使其能够虚拟化地运行在MIPS体系结构上。另外,出于性能的考虑,还要做一些其它修改。
现在,我们知道有两个其它的系统也采用了准虚拟化的方法:IBM不久前提出的Linux的准虚拟化版本允许大量的Linux实例同时运行,将用于他们的zSeries大型机上。Denali[44]在之前已经讨论过,它是一个暂时隔离的内核(//contemporary isolation kernel:没看相关文献,不知道怎么表述好),试图提供能够操控大量虚拟操作系统实例的系统能力(//咋又出来虚拟操作系统这么个概念呢?还有前面的Linux的准虚拟化版本?是不是说这些操作系统能够运行在(准)虚拟环境中?)。
除了Denali,我们还知道有两种其它的方法使用了低层虚拟化技术建立分布式系统的底层架构。vMatrix[1]是基于VMware的,它的目标是建立一个用于在不同机器间移动代码的平台。由于vMatrix是在VMware之上开发的,因此它更关注的是虚拟化技术在分布式环境中存在的高层问题。另外,在IBM提出的“托管管理(Managed Hosting)”服务中,虚拟Linux的实例可以在IBM大型机上被租用(//大型机上跑多个Linux实例,你可以租一个用,搭建你自己的系统,和其他租户共享大型机的资源)。
PlanetLab项目[33]构建了一个分布式的底层架构,它的设计目的是作为实验床用于研究和开发地理空间分布的网络服务。平台的对象是研究者,试图将单个的物理主机划分为条(sliver),提供同时的对用户的低层访问(//The platform is targeted at researchers and attempts to divide individual physical hosts into slivers, providing simultaneous low-level access to users.翻译的不好)。项目当前使用的是VServers[17]和SILK[4]来管理操作系统内部的共享。
我们再和操作系统外延研究和主动网络通信研究中的一些思路作比较。当代码在Xen上面运行的时候没有必要检查其“安全性”,也没有必要去检查代码运行是否能够保证终止,因为在这些情况中唯一的受害人是那些可疑的客户。于是Xen提供了更通用的方案:这个方案不需要由一个可信的编译器为被操控的代码做数字签名(比如SPIN[5]),不需要这些代码被一个安全证明伴随(比如PCC[31]),不需要由一种特殊的语言写成(比如SafetyNet[22]或者其它基于Java的系统),也不需要依赖于特殊的中间件(比如移动代理(mobile-agent)系统)。当然,这些其它的技术能够继续在运行在Xen上的guest OS中使用,而且可能会对那些时限更短暂的任务负载有着特别的用途,因为这类任务没有机会被成批处理以减少启动一个新的domain的代价(//为什么要启动新的domain?)。(//这段的意思,我的感觉是在操作系统外延研究和主动网络通信研究为了保证代码安全,采用了多种多样的方法;但是在Xen中,这些方法都是不必要的,因为Xen的安全性确认策略比较简单,前文有提及;但是这些方法在Xen中也还是有它们的作用,比如对于时限短暂的任务,它等不及成批地被确认,那么它就需要用其它方法保证安全性。)
关于语言级虚拟机(//比如Java虚拟机)方法中也存在着类似的问题:一个管理资源(//resource-managed:突然晕了,这个应该怎么翻?看着好别扭)的JVM[9]肯定能够操控不可信的应用,前提是这些应用必须被编译为Java字节码并且遵循特别的系统安全模型(//不可信的代码,即使出了问题,但是由于其遵循系统安全模型,所以也不会造成危害)。这样的话,Xen就能够容易地支持语言级虚拟机,就像支持其它运行在guest OS上的应用一样。(//这段的意思,和前面类似,仍旧是表明Xen并不提供过多的安全性检查;如果要跑语言虚拟机之类的应用,语言的安全性要由虚拟机应用本身保证,而不关系到Xen。)
Part 6 — Xen and the Art of Virtualization — Xen和虚拟化技术
6. DISCUSSION AND CONCLUSION — 讨论和结论
我们在上文介绍了Xen hypervisor。它能够将计算机的资源划分给各个运行着guest OS的domain。我们的准虚拟化设计特别强调了性能和资源管理。我们还描述和评估了XeonLinux,XeonLinux是将Linux 2.4内核向Xen上做的完全移植。
6.1 Future Work — 将来的工作
我们认为Xen和XenoLinux完全能够被用于更广阔的空间,所以我们准备在不久的将来把我们的软件做成一个公开版本。当前已经有一个Beta版本正在被评估(//貌似就是那个Clarkson University做的工作);一旦评估阶段结束,我们就会在项目主页上发布1.0版。
在完成初始版本后,我们计划对Xen做一些的扩展和改进。为了增加虚拟块设备的效率,我们准备实现一个由块内容索引的共享的通用缓冲Cache(universal buffer cache)。这将为我们的设计增加受控的数据共享,同时却不牺牲隔离性。为虚拟块设备增加写复制(copy-on-write)语义,使它们能够在domain之间被安全地共享,即使是不同的文件系统也不会有问题(//写复制,保证一致性,减少内容复制开销;不过跨文件系统应该还是不很容易吧?)。
为了提供更好的physical(//物理?还是像之前提到的是“实际分得的”?应该是后者)内存性能,我们计划实现一个最后机会页缓存(LPC:last-chance page cache)。这是一个全系统范围内的空闲页链表,只有在机器内存未被分光的情况下,链表才有非零的长度。当guest OS虚拟存储系统选择舍弃一个干净(clean:数据中没有dirty data,都是与磁盘中相同的)的页时会使用到LPC;这个干净的页会被加入到空闲链表的结尾,而并非被完全抛弃。如果在该页重新被Xen分配之前发生了和该页相关的错误,那么对错误的处理是不需要磁盘访问的(// A fault occurring for that page before it has been reallocated by Xen can therefore satisfied without a disk access. 这句翻译得对不对有待商榷;我的理解是,以往的方法如果操作系统释放了内存资源的话,那么它如果再想使用刚才释放页上的资源就必须重新从磁盘上调入;而现在的last-chance,就给了操作系统一个机会,如果出现了和刚释放掉的页内容相关的错误,那么操作系统可以直接从这个LPC中调相关页,而不用访问磁盘)。
Xen的一个重要角色是作为XenoServer的基础。XenoServer的设计目标超越了单机的范畴,它要搭建的是支持一个互联网规模计算架构所必需的控制系统。对于我们的设计来说,关键在于资源的使用要被精确地计算并且由工作的发起者想办法满足资源需求 — 如果资源必须要及时兑现,我们就使用一个拥塞定价策略(congestion pricing strategy//没看相关文献)[28]来处理那些超过资源提供能力的要求,使用透支的方法满足超出的需求。这就必须要有精确、及时的I/O调度,它要能够更有弹性地处理那些不友好(//恶意透支?)的工作负载。我们还计划创建虚拟块设备租借等形式,将会计学中的一些理论(//上述的租借,透支之类的概念都是属于会计学的范畴)借鉴进我们的块存储架构中。
为了能够为XenoServer的管理和经营提供更好的支持,我们正在加入对日志审核和日志鉴证更彻底的支持。我们还在开发其它的VFR规则,希望这些规则能够使我们检测和防止更大范围的对社会有危害的网络行为。最终,我们正在继续我们在XenoXP上的工作,最重要的工作就是编写网络和块设备驱动实例,工作的目标是完全支持企业级的服务器应用(如IIS)。
6.2 Conclusion — 结论
Xen提供了一个优秀的平台,在这个平台上能够配置广泛的多样化的以网络为中心的服务,比如动态web内容的局部镜像,媒体流的编码转换和分发,多用户游戏和虚拟现实服务器,还有为瞬时连接设备提供短暂网络连接的“智能代理”[2]服务。
Xen直接解决的是在部署服务时遇到的最大障碍,即当前不能够在低实例化开销的前提下,对瞬时服务器操控较短的时间(//瞬时服务器:时有时无,有时候需要有时候不需要;而即使是每次需要,也只是操作很短的时间,马上就又不需要了;所以这样的话,频频切换,就需要很大的实例化开销,因为每次启动瞬时服务,就要实例化一次;但是Xen中,反正我可以跑多个系统,那就专门留一个或几个系统给你跑瞬时服务,同时还不耽误我其它服务的性能)。通过允许100个操作系统运行在单台服务器上,我们减少了两个数量级的相关开销。更进一步的,我们可以把对每个操作系统进行设定和配置的过程转变为软件行为,这样就能够更容易地操控更细粒度的时间片。
正如我们在第4部分给出的实验结果,在Xen上运行XenoLinux的性能几乎与本地Linux系统的性能相同。之所以会有这样的结果,主要得益于对两个部件之间接口(//就是VMM吧?操作系统和底层硬件两个部分之间的接口)的细致设计,这使得我们几乎感觉不到在使用资源管理工具时带来的开销。我们的下一步工作是移植BSD和Windows XP的内核到Xen上来验证Xen提供的接口的普适性。
Acknowledgments — 致谢
本项工作得到了ESPRC Grant GR/S01894/01和微软公司的支持。我们要感谢Evangelos Kotsovinos, Anil Madhavapeddy, Russ Ross and James Scott做出的贡献。