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。）