|
XEN方法和概述 在传统的VMM中虚拟硬件的功能是与底层机器上的真实硬件完全相同的这种完全虚拟化（full virtualization）的方法最显而易见的好处在于操作系统可以不经任何修改就直接在虚拟硬件上运行但是它也有很多缺点特别是针对那些当前被广泛应用的IA（或者称作x）架构这种方法带来的缺陷更是不容忽视 x架构的设计从来就不支持完全的虚拟化如果要正确实现x架构虚拟化VMM就必须能够对某几条特定的超级指令（supervisor instruction）进行操作但是如果在没有足够特权的情况下执行这些超级指令会导致沉默的失败（//fail silently如果特权级不够那么会直接导致执行失败不会产生其它响应）而并非产生一个便于我们使用的陷阱（trap） 另外将x架构中的MMU进行有效的虚拟化也是一件很困难的事情这些问题是可以被解决的但是在解决的同时必须要付出操作复杂度增加和系统性能降低的代价VMware ESX Server[]需要动态地重写那些被VMM操控的机器码部分在其中有可能需要VMM干涉的地方插入陷阱操作（//在什么地方插入陷阱操作是在程序运行起来后才知道的所以需要动态地重写相关代码）因为务必要对所有那些不能够引起陷阱的特权指令进行捕捉和操作所以这种转换（//动态重写代码）要被应用于整个guest OS的内核（导致了相关的转换执行和缓存等开销）ESX Server实现中采用的技术是建立系统结构（system structure）（比如页表）的影子版本通过为每一次更新操作设立陷阱来解决虚拟页表和物理页表的一致性问题（//具体细节还是要看ESX Server的说明）但是在处理更新密集型的操作（如创建新的应用进程）的时候该方法会带来高昂的开销 除了x架构非常复杂的原因还有一些其它方面的争论反对完全虚拟化其中值得一提的是被操控的操作系统在一些情况下需要接触到真实的资源例如提供真实时间和虚拟时间以允许guest OS能够更好地支持时间敏感型的任务还可以正确地操作TCP超时和RTT估算给出真实的机器地址以允许guest OS能够利用超级页（superpage）或者页染色（page coloring）等方法改进性能 我们提出的虚拟机抽象能够避免完全虚拟化带来的种种缺陷这种虚拟机抽象和底层硬件相似却并不完全相同因此被称之为准虚拟化（//paravirtualization或者翻译为半虚拟化？后面译文沿用准虚拟化）方法这种方法虽然需要对guest OS进行一些改动但是它能够改善性能还有特别重要的一点需要说明准虚拟化方法不会对应用二进制接口（ABI）进行修改因此用户也就不用修改那些在guest OS上执行的应用程序 我们进行的关于准虚拟化方法的讨论要遵循以下一些规则 最基本的是要支持那些不经改动的应用二进制文件的执行即用户不用对应用程序做针对Xen的转换因此我们必须虚拟化现有的标准ABI所需的全部体系结构特征 很重要的一点是要支持完整的多应用操作系统这就需要将在单个guest OS实例中的复杂的服务器配置虚拟化（//例如如果guest OS上配置了ftp服务那么虚拟硬件就要打开相应端口） 准虚拟化务必要有很高的性能另外针对那些不协作（//uncooperative这里的不协作是指硬件架构不支持共享所以才需要资源隔离）的机器架构如x架构准虚拟化还需要能够提供很强的资源隔离能力 在协作（cooperative）的机器架构上准虚拟化方法要能够完全地隐藏资源虚拟化带来的影响减少guest OS在正确性和性能上面临的风险 请注意我们在这里提出的准虚拟化的x抽象的方法是与最近在Denali项目中提出的方法有很大差异的Denali是为了支持数以千计的运行着网络服务的虚拟机而设计的这些网络服务中绝大部分是小规模的不流行（//应用的不流行也就说明了运行该应用的环境比较少所以只要针对这些相应的特定环境作专门的虚拟化即可）的应用与之相反的是Xen的设计最终要支持近个运行着业界标准应用和服务的虚拟机由于设计目标的极大差异我们不妨将Denali的设计选择和我们自己的设计规则做一个有益的讨论 首先Denali不需要关注现有的ABI因此他们的VM接口忽略掉了相关的架构特征例如Denali并不完全支持x的分段机制但是这一点却是在NetBSDLinux和Windows XP等操作系统的ABI中都有提出并且被广泛使用例如线程库中经常会使用分段机制来寻址线程局部数据 其次Denali的实现没有解决在单个guest OS中支持多个应用（application multiplexing）的问题也没有解决多地址空间的问题应用被显式地链接到Ilwaco guest OS实例上这么做在某种意义上类似于之前在Exokernel中的libOS[]因此每个虚拟机只能操控一个单用户单应用的没有保护措施的所谓的操作系统在Xen中与之相反每个虚拟机上能够操控一个真正的操作系统这个操作系统上能够安全地执行数以千计个不经改动的用户级进程虽然Denali号称开发了一个虚拟MMU原型能够对其在该领域有所帮助但是我们没有看到公开的技术细节和评估报告 再次在Denali体系结构中是由VMM执行全部的内存与磁盘间的页面调度的这可能是与虚拟层缺乏存储管理支持有关由VMM完成页面调度是与我们的性能隔离目标相违背的那些有恶意的虚拟机可能会故意产生抖动行为导致其它虚拟机的CPU时间和磁盘带宽被不公平地剥夺（//VMM监控很多VM各个VM上再跑操作系统所以如果很多事情都放在VMM中做必然会影响到各个VM所以要把一些事情放在上面的操作系统做来达到隔离性）在Xen中我们希望每个guest OS在其自己分配到的内存空间和磁盘区域内执行它自己的页面调度（此前已经有selfpaging的方法被提出） 最后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运行的特权级更高 虚拟机接口 一个准虚拟化的x接口主要包括了系统中的三个大的方面存储管理CPU和设备I/O在下面我们将依次介绍各个机器子系统的情况并讨论在我们的准虚拟化架构中是如何体现的虽然在我们的实现中有相当一部分如存储管理是专门针对x的但是实际上还有很多方面（比如我们虚拟的CPU和I/O设备）都是可以很容易地应用于其它机器架构上的更进一步地说在与RISC架构在实现上有差异的很多地方x往往表现出的是该方面最坏情况时的情形例如对硬件页表进行有效的虚拟化就比虚拟化一个软件管理的TLB困难很多 存储 管理分段不能够使用具有完全特权级的段描述符不能够与线性地址空间的最顶部交迭（//因为最顶部是Xen） 分页guest OS直接对硬件页表做读访问但是更新（//就是写）是分批进行的而且要经过hypervisor确认一个domain可以被分配在不连续的页面上 CPU保护guest OS必须运行在低于Xen的特权级上 异常guest OS必须将异常句柄的描述符表在Xen中记录除了页面错误外其它句柄和真实的x架构相同 系统调用guest OS为系统调用提供一个快速的句柄允许应用直接调用它所在的guest OS而不必间接地通过Xen完成每次调用 中断硬件中断被一个轻量级的事件系统替换 时间每个guest OS具有一个定时器接口可以得到真实的和虚拟的时间 设备I/O网络磁盘……虚拟设备访问起来很简单数据传递使用的是异步I/O环由一个事件机制替换硬件中断来发布通告 存储管理 虚拟化存储毫无疑问是准虚拟化一个体系结构中最困难的部分它包括hypervisor所需的机制和移植各个guest OS所需的改动如果在架构中提供了由软件管理的TLB的话那么这个任务会变得轻松些它们可以以比较简单的方式被有效地虚拟化[]带标记的TLB是另外一个在大部分RISC架构（这些RISC架构主要用于构建服务器比如AlphaMIPS和SPARC）中支持的有用特征其中每个TLB项都有和地址空间标识符相关的标记这使得hypervisor和各个guest OS能够有效地在被隔离开的地址空间内共存这时在执行转移（//transferring execution在进程执行间切换的时候执行的指令序列从一个进程转移到另一个进程称为执行转移）的时候是不需要刷新（flush）整个TLB（//只对具有和自己的地址空间标识符相吻合的TLB项进行操作） 不幸的是x架构并没有由软件管理的TLB取而代之的是在发生TLB失效的时候处理器会自动通过遍历硬件页表结构来处理因此为了获得最好的可能达到的性能当前地址空间内所有的有效页传输）都要在硬件可访问的页表中给出（//最好情况理应如 |
