Xen和虚拟化技术学习指南

Xen和虚拟化技术学习指南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原型系统能够支持多个我们研发的Xen o Linux guest OS实例的并发执行；每个实例都给出了和非虚拟化情况下的Linux 2.4中相同的应用二进制接口。

目前，我们对Windows XP到Xen的移植还没有完全完成，但是已经能够运行简单的用户空间进程。

移植NetBSD的工作也在进行中。

Xen使得用户能够动态地实例化一个操作系统以执行他们需要的应用。

在Xen oServer项目[15，35]中，我们在ISP或者Internet exchange（//布置在这些场合中经济划算而且又具有战略意义的地方）的标准服务器硬件上配置了Xen。

我们在启动一个新的虚拟机的时候需要执行许可控制（admission control），希望每个虚拟机能够以某种方式为它需要的资源付出代价。

我们在其它文章中讨论过我们在这个方向上的思路和方法[21]；现在这篇文章则将焦点关注于虚拟机。

现在有一些方法用于构建能够在共享的机器上操控多个应用和服务器（//server：这里提到的server应该是大规模应用的意思，比如数据库服务器）的系统。

也许最简单的方法就是部署一个或多个运行着标准操作系统（如Linux或者Windows）的主机，然后允许用户们安装文件和启动进程—应用间的保护是由传统的操作系统技术提供的（//这里提到的做法，就是类似并行机性质的，各个节点都是独立的主机，但是一个应用可以在多个节点上面并行执行）。

实验显示：由于要针对各个脱节（//supposedly disjoint：逻辑上脱节，指的是应用不具有连贯性/兼容性，所以针对每个应用都要单独配置一次，如果能想办法将前后有关联的应用放在一起执行，可以大大减少相关的开销，如配置开销，通信开销等等）的应用进行复杂的配置，这些配置过程导致的交互行为会使系统管理任务迅速成为时间消耗巨大的任务。

更重要的是，这样的系统不能够充分地支持性能隔离；某个进程的调度优先级，存储要求，网络通信量和磁盘访问等等特征都会影响到其它进程的性能。

如果是在资源供应充足而且用户群体是限定（比如计算网格或者PlanetLab平台实验）的情况下，这个系统还是可以接受的。

但是当资源是供不应求的时候，或者用户间不相协作（//uncooperative：不相协作，比如用户间的需求有冲突，那么一定会互相影响的）的时候就不行了。

一个解决这个问题的方法是改进对操作系统性能隔离的支持。

这已经在resource containers，Linux/RK，Q Linux 和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上的Xen o Linux与单独的Linux，VMware Workstation和用户模式Linux（UML）的性能比较结果。

最后的第5部分讨论了未来的工作并作了总结。

2. Xen：方法和概述在传统的VMM中，虚拟硬件的功能是与底层机器上的真实硬件完全相同的。

这种“完全虚拟化”（full virtualization）的方法最显而易见的好处在于操作系统可以不经任何修改就直接在虚拟硬件上运行，但是它也有很多缺点。

特别是针对那些当前被广泛应用的IA32（或者称作x86）架构，这种方法带来的缺陷更是不容忽视。

x86架构的设计从来就不支持完全的虚拟化。

如果要正确实现x86架构虚拟化，VMM就必须能够对某几条特定的“超级指令（supervisor instruction）”进行操作。

但是，如果在没有足够特权的情况下执行这些超级指令会导致“沉默的失败（//fail silently：如果特权级不够，那么会直接导致执行失败，不会产生其它响应）”，而并非产生一个便于我们使用的陷阱（trap）。

另外，将x86架构中的MMU进行有效的虚拟化也是一件很困难的事情。

这些问题是可以被解决的，但是在解决的同时必须要付出操作复杂度增加和系统性能降低的代价。

VMware ESX Server[10]需要动态地重写那些被VMM操控的机器码部分，在其中有可能需要VMM 干涉的地方插入陷阱操作（//在什么地方插入陷阱操作，是在程序运行起来后才知道的，所以需要动态地重写相关代码）。

因为务必要对所有那些不能够引起陷阱的特权指令进行捕捉和操作，所以这种转换（//动态重写代码）要被应用于整个guest OS的内核（导致了相关的转换，执行和缓存等开销）。

ESX Server实现中采用的技术是建立系统结构（system structure）（比如页表）的影子版本，通过为每一次“更新”操作设立陷阱来解决虚拟页表和物理页表的一致性问题（//具体细节还是要看ESX Server的说明）。

但是在处理“更新密集”型的操作（如创建新的应用进程）的时候，该方法会带来高昂的开销。

除了x86架构非常复杂的原因，还有一些其它方面的争论反对“完全虚拟化”。

其中值得一提的是，被操控的操作系统在一些情况下需要接触到真实的资源。

例如，提供真实时间和虚拟时间以允许guest OS能够更好地支持“时间敏感”型的任务，还可以正确地操作TCP超时和RTT估算；给出真实的机器地址以允许guest OS能够利用超级页（superpage）或者页染色（page coloring）等方法改进性能。

我们提出的虚拟机抽象能够避免完全虚拟化带来的种种缺陷。

这种虚拟机抽象和底层硬件相似却并不完全相同，因此被称之为“准虚拟化”（//paravirtualization：或者翻译为半虚拟化？后面译文沿用准虚拟化）方法。

这种方法虽然需要对guest OS进行一些改动，但是它能够改善性能。

还有特别重要的一点需要说明：准虚拟化方法不会对应用二进制接口（ABI）进行修改，因此用户也就不用修改那些在guest OS上执行的应用程序。

我们进行的关于准虚拟化方法的讨论要遵循以下一些规则：1.最基本的是要支持那些不经改动的应用二进制文件的执行，即用户不用对应用程序做针对Xen的转换。

因此我们必须虚拟化现有的标准ABI所需的全部体系结构特征。

2.很重要的一点是要支持完整的多应用操作系统。

这就需要将在单个guest OS实例中的复杂的服务器配置虚拟化（//例如，如果guest OS上配置了ftp服务，那么虚拟硬件就要打开相应端口）。

3.准虚拟化务必要有很高的性能。

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

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

请注意，我们在这里提出的准虚拟化的x86抽象的方法是与最近在Denali项目中提出的方法有很大差异的。

Denali是为了支持数以千计的运行着网络服务的虚拟机而设计的。

这些网络服务中绝大部分是小规模的，不流行（//应用的不流行也就说明了运行该应用的环境比较少，所以只要针对这些相应的特定环境作专门的虚拟化即可）的应用。

与之相反的是，Xen的设计最终要支持近100个运行着业界标准应用和服务的虚拟机。