4.相关工作
虚拟化技术被应用在商业化和研究型操作系统上已经有近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]在之前已经讨论过，它是一个暂时隔离的内核，试图提供能够操控大量虚拟操作系统实例的系统能力。
除了Denali，我们还知道有两种其它的方法使用了低层虚拟化技术建立分布式系统的底层架构。vMatrix[1]是基于VMware的，它的目标是建立一个用于在不同机器间移动代码的平台。由于vMatrix是在VMware之上开发的，因此它更关注的是虚拟化技术在分布式环境中存在的高层问题。另外，在IBM提出的“托管管理（Managed Hosting）”服务中，虚拟Linux的实例可以在IBM大型机上被租用（//大型机上跑多个Linux实例，你可以租一个用，搭建你自己的系统，和其他租户共享大型机的资源）。
PlanetLab项目[33]构建了一个分布式的底层架构，它的设计目的是作为实验床用于研究和开发地理空间分布的网络服务。平台的对象是研究者，试图将单个的物理主机划分为条（sliver），提供同时的对用户的低层访问。项目当前使用的是VServers[17]和SILK[4]来管理操作系统内部的共享。
我们再和操作系统外延研究和主动网络通信研究中的一些思路作比较。当代码在Xen上面运行的时候没有必要检查其“安全性”，也没有必要去检查代码运行是否能够保证终止，因为在这些情况中唯一的受害人是那些可疑的客户。于是Xen提供了更通用的方案：这个方案不需要由一个可信的编译器为被操控的代码做数字签名（比如SPIN[5]），不需要这些代码被一个安全证明伴随（比如PCC[31]），不需要由一种特殊的语言写成（比如SafetyNet[22]或者其它基于Java的系统），也不需要依赖于特殊的中间件（比如移动代理（mobile-agent）系统）。当然，这些其它的技术能够继续在运行在Xen上的guest OS中使用，而且可能会对那些时限更短暂的任务负载有着特别的用途，因为这类任务没有机会被成批处理以减少启动一个新的domain的代价。（//这段的意思，我的感觉是在操作系统外延研究和主动网络通信研究为了保证代码安全，采用了多种多样的方法；但是在Xen中，这些方法都是不必要的，因为Xen的安全性确认策略比较简单，前文有提及；但是这些方法在Xen中也还是有它们的作用，比如对于时限短暂的任务，它等不及成批地被确认，那么它就需要用其它方法保证安全性。）
关于语言级虚拟机（//比如Java虚拟机）方法中也存在着类似的问题：一个管理资源（resource-managed）的JVM[9]肯定能够操控不可信的应用，前提是这些应用必须被编译为Java字节码并且遵循特别的系统安全模型（//不可信的代码，即使出了问题，但是由于其遵循系统安全模型，所以也不会造成危害）。这样的话，Xen就能够容易地支持语言级虚拟机，就像支持其它运行在guest
OS上的应用一样。（//这段的意思，和前面类似，仍旧是表明Xen并不提供过多的安全性检查；如果要跑语言虚拟机之类的应用，语言的安全性要由虚拟机应用本身保证，而不关系到Xen。）
5.讨论和结论
我们在上文介绍了Xen hypervisor。它能够将计算机的资源划分给各个运行着guest
OS的domain。我们的准虚拟化设计特别强调了性能和资源管理。我们还描述和评估了XeonLinux，XeonLinux是将Linux 2.4内核向Xen上做的完全移植。
5.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分配之前发生了和该页相关的错误，那么对错误的处理是不需要磁盘访问的（我的理解是，以往的方法如果操作系统释放了内存资源的话，那么它如果再想使用刚才释放页上的资源就必须重新从磁盘上调入；而现在的last-chance，就给了操作系统一个机会，如果出现了和刚释放掉的页内容相关的错误，那么操作系统可以直接从这个LPC中调相关页，而不用访问磁盘）。
Xen的一个重要角色是作为XenoServer的基础。XenoServer的设计目标超越了单机的范畴，它要搭建的是支持一个互联网规模计算架构所必需的控制系统。对于我们的设计来说，关键在于资源的使用要被精确地计算并且由工作的发起者想办法满足资源需求 — 如果资源必须要及时兑现，我们就使用一个拥塞定价策略来处理那些超过资源提供能力的要求，使用透支的方法满足超出的需求。这就必须要有精确、及时的I/O调度，它要能够更有弹性地处理那些不友好（//恶意透支？）的工作负载。我们还计划创建虚拟块设备租借等形式，将会计学中的一些理论（//上述的租借，透支之类的概念都是属于会计学的范畴）借鉴进我们的块存储架构中。
为了能够为XenoServer的管理和经营提供更好的支持，我们正在加入对日志审核和日志鉴证更彻底的支持。我们还在开发其它的VFR规则，希望这些规则能够使我们检测和防止更大范围的对社会有危害的网络行为。最终，我们正在继续我们在XenoXP上的工作，最重要的工作就是编写网络和块设备驱动实例，工作的目标是完全支持企业级的服务器应用（如IIS）。
5.2结论
Xen提供了一个优秀的平台，在这个平台上能够配置广泛的多样化的以网络为中心的服务，比如动态web内容的局部镜像，媒体流的编码转换和分发，多用户游戏和虚拟现实服务器，还有为瞬时连接设备提供短暂网络连接的“智能代理”[2]服务。
Xen直接解决的是在部署服务时遇到的最大障碍，即当前不能够在低实例化开销的前提下，对瞬时服务器操控较短的时间（//瞬时服务器：时有时无，有时候需要有时候不需要；而即使是每次需要，也只是操作很短的时间，马上就又不需要了；所以这样的话，频频切换，就需要很大的实例化开销，因为每次启动瞬时服务，就要实例化一次；但是Xen中，反正我可以跑多个系统，那就专门留一个或几个系统给你跑瞬时服务，同时还不耽误我其它服务的性能）。通过允许100个操作系统运行在单台服务器上，我们减少了两个数量级的相关开销。更进一步的，我们可以把对每个操作系统进行设定和配置的过程转变为软件行为，这样就能够更容易地操控更细粒度的时间片。
正如我们在第4部分给出的实验结果，在Xen上运行XenoLinux的性能几乎与本地Linux系统的性能相同。之所以会有这样的结果，主要得益于对两个部件之间接口（//就是VMM吧？操作系统和底层硬件两个部分之间的接口）的细致设计，这使得我们几乎感觉不到在使用资源管理工具时带来的开销。我们的下一步工作是移植BSD和Windows
XP的内核到Xen上来验证Xen提供的接口的普适性。
