虚拟机监视器Xen和虚拟化技术（一）

核心提示：1. 引言现代计算机具有足够强大的能力来利用虚拟化技术支持多个虚拟机（VM: virtual machines），并且在每个虚拟机上各自运行单独的操作系统实例，虚拟机监视器Xen和虚拟化技术（一），这直接导致了虚拟机技术发展的又一个春天，在本文中，第4部分给出了使用业界标准的测试程序评估运行在Xen上的XenoLinu

　　1. 引言
　　
　　现代计算机具有足够强大的能力来利用虚拟化技术支持多个虚拟机（VM: virtual machines），并且在每个虚拟机上各自运行单独的操作系统实例。这直接导致了虚拟机技术发展的又一个春天。在本文中，我们提出了Xen，一个高性能的用于资源治理的虚拟机监视器（VMM: VM monitor）。Xen能够支持的应用比如：server consolidation，co-located hosting facilities，distributed web services，secure computing platforms[12，16]和application mobility。
　　
　　成功地对一台机器进行划分，使它能够支持多个操作系统的并发执行，这个过程具有很多的挑战。首先，虚拟机必须是彼此相隔离的：假如一个虚拟机的执行会影响另一个的性能，这是不可以被接受的。这一点在操作各个虚拟机的用户相互间并不信任的情况下显得非凡重要。其次，它必须支持多种多样的不同操作系统以提供给各种异构（heterogeneity）的流行应用的支持（//这里的异构指的是应用开发依托的操作系统不同，因此在实现上也就有很大差异，使得应用并不能够跨平台移植，因为Xen不需要对应用程序进行修改，那么它就必须支持各种常用的操作系统；所谓流行的应用，就是那些大家常用的、必需的应用）。第三，由虚拟化技术引入的性能开销必须要小。
　　
　　Xen操控（//host：操作和控制）的是常用的操作系统，但是需要对操作系统中的某些相关部分进行一些修改。在本文中描述和评估的Xen原型系统能够支持多个我们研发的Xenolinux guest OS实例的并发执行；每个实例都给出了和非虚拟化情况下的Linux 2.4中相同的应用二进制接口。目前，我们对Windows xp到Xen的移植还没有完全完成，但是已经能够运行简单的用户空间进程。移植NetBSD的工作也在进行中。
　　
　　Xen使得用户能够动态地实例化一个操作系统以执行他们需要的应用。在XenoServer项目[15，35]中，我们在ISP或者Internet exchange（//布置在这些场合中经济划算而且又具有战略意义的地方）的标准服务器硬件上配置了Xen。我们在启动一个新的虚拟机的时候需要执行许可控制（admission control），希望每个虚拟机能够以某种方式为它需要的资源付出代价。我们在其它文章中讨论过我们在这个方向上的思路和方法[21]；现在这篇文章则将焦点关注于虚拟机。
　　
　　现在有一些方法用于构建能够在共享的机器上操控多个应用和服务器（//server：这里提到的server应该是大规模应用的意思，比如数据库服务器）的系统。也许最简单的方法就是部署一个或多个运行着标准操作系统（如Linux或者Windows）的主机，然后答应用户们安装文件和启动进程— 应用间的保护是由传统的操作系统技术提供的（//这里提到的做法，就是类似并行机性质的，各个节点都是独立的主机，但是一个应用可以在多个节点上面并行执行）。实验显示：由于要针对各个脱节（//supposedly disjoint：逻辑上脱节，指的是应用不具有连贯性/兼容性，所以针对每个应用都要单独配置一次，假如能想办法将前后有关联的应用放在一起执行，可以大大减少相关的开销，如配置开销，通信开销等等）的应用进行复杂的配置，这些配置过程导致的交互行为会使系统治理任务迅速成为时间消耗巨大的任务。
　　
　　更重要的是，这样的系统不能够充分地支持性能隔离；某个进程的调度优先级，存储要求，网络通信量和磁盘访问等等特征都会影响到其它进程的性能。假如是在资源供给充足而且用户群体是限定（比如计算网格或者PlanetLab平台实验）的情况下，这个系统还是可以接受的。但是当资源是供不应求的时候，或者用户间不相协作（//uncoOperative：不相协作，比如用户间的需求有冲突，那么一定会互相影响的）的时候就不行了。一个解决这个问题的方法是改进对操作系统性能隔离的支持。这已经在resource containers，Linux/RK，QLinux和SILK中被或多或少地实现了。这些方法中存在着一个难点是难以确保所有的资源都能够正确地分配给有相应资源需求的进程。例如，缓冲区cache或者存储页面的替换算法导致的在应用间的复杂的交互行为（//比如存储页面替换的时候，某个进程的页面替换序列会干扰到其它进程的，要免除这个影响就需要有复杂的机制用于进程间的协调）。这就是存在于操作系统中的“QoS干扰问题（QoS crosstalk）”。在低层采用多路执行技术能够缓解这个问题带来的影响，这已经在Exokerne和Nemesis操作系统中得到证实。在这些操作系统中，任务间无意识的或者不受欢迎的交互行为被最小化了。
　　
　　我们使用了同样的基本方法来构建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部分讨论了未来的工作并作了总结。