Xen 虚拟机架构

xq8995209

Xen 是一个基于开源软件组织的虚拟机监控器(即 Virtual Machine Monitor 简称 VMM)，可以允许在单一的物理机器上同时运行多个操作系统实例。　　　　虚拟化技术概述
　　　　虚拟计算机的概念最早由 IBM 公司在上世纪六七十年代提出，并将其运用于 VM/370 系统中以共享昂贵的大型机系统(Main Frame)。之后的发展起起伏伏，一度由于分时操作系统的出现而处于停滞状态。上世纪九十年代随着 JAVA 虚拟机的推出，尤其是之后 Vmware 公司 Vmware ESXserver 和 Vmware workstation 虚拟机的推出，使对虚拟机技术的研究再次成为处理器设计人员、软件设计人员、服务器设计人员和网络安全设计人员的热门研究课题。

　　　　如图 1 所示，虚拟化技术通过在现有平台(机器)上添加一层薄的虚拟机监控程序(Virtual Machine Monitor，简称 VMM)软件而实现对系统的虚拟化，如虚拟处理器，虚拟内存管理器(MMU)和虚拟 I/O 系统等。虚拟机监控程序又被称之为监管程序(Hypervisor)。从应用程序的角度看，程序运行在虚拟机上同运行在其对应的实体计算机上一样。虚拟机技术使得一台物理计算机可以生成多个不同的虚拟机分别运行多个不同或相同的操作系统。虚拟机技术通过将不同的应用运行在不同的虚拟机上，可以避免不同应用程序之间的互相干扰，例如一个应用的崩溃不会影响到其它的应用等。这种由虚拟机技术实现的各个应用之间的完全隔离在服务器领域具有尤其重要的意义，同时虚拟机技术也可以使得企业、高校或研究所可以在不必购置大量物理计算机的情况下实现大规模的计算机网络以从事生产及研究，例如网络及网络应用研究，操作系统内核(Kernel)软件的开发和用户操作系统的开发等。
　　　　VMM 抽象的虚拟机的指令集(Instruction Set Architecture 简称 ISA)可以等同于它运行的物理机器，也可以作些微修改。当虚拟的指令集与物理的指令集相同时，该虚拟机可以运行没有任何修改的操作系统；而当两者不完全相同时，客户机的操作系统就必须在源代码级或二进制代码级作相应修改。根据是否需要修改客户机操作系统的源代码，虚拟化技术又可以分为(1)泛虚拟化(Paravirtualization)和(2)完全虚拟化(Full-virtualization)。完全虚拟化由于不需要修改客户机操作系统，因此具有很好的兼容性和同时支持异种操作系统或不同版本操作系统的能力。相反泛虚拟化技术则通常具有比完全虚拟化技术更好的性能。
　　　　泛虚拟化技术在最早的 IBM VM/370 上就已经使用，但它的使用仅仅是为了支持传统的操作系统，因此被限制在很小的范围。美国华盛顿大学计算机科学与工程系的 Steven D. Gribble 领导的 Denali 项目和英国剑桥大学计算机实验室的 Ian Pratt 和 Keir Fraster 领导的 Xen 项目组实现了 X86/PC 上的泛虚拟化，使泛虚拟化技术重新成为最热门的虚拟化技术之一。随着 Intel® 公司在 2005 年初推出基于处理器硬件的虚拟化技术(Intel®Virtualization Technology 简称 Intel®VT 技术)，支持未经修改的操作系统的完全虚拟化技术同泛虚拟化技术一样成为当今虚拟化领域中的两个主要研究方向。
　　　　Xen 虚拟机
　　　　Xen 是一个基于开源(Open Source)代码的系统虚拟机，最初基于 32 位 X86 体系结构而设计开发，支持同时运行多至约 100 个虚拟机。Xen 引入的管理接口(Hypercalls)和事件(Events)机制，以及预先定义的虚拟机和 VMM 之间的共享内存数据交换机制都使得新的客户机体系架构(Xen 虚拟机架构)具有更高的总体性能，但同时也就注定了它必须修改客户机操作系统源代码。
　　　　Xen 将客户机称之为虚拟域 (Domain)，其中 0 号虚拟域为服务域作为监控程序的扩展提供系统的管理服务。监控程序拥有部分硬件 IO 资源如定时器设备、中断设备PIC/Local APIC/IO APIC 等，其他虚拟域也可以拥有部分的 IO 资源，如硬盘网卡等。拥有物理设备的虚拟域称为隔离设备驱动域(Isolated Driver Domain)或简称设备驱动域(Driver Domain)。普通虚拟域只有虚拟设备而不拥有直接的硬件设备资源访问权。Xen项目也将 Hypervisor 称为 Xen。
　　　　Xen 本身主要基于开源的 Linux 内核代码移植而来，同时运行其上的 XenLinux 也从 Linux 移植而来，意为支持 Xen 架构的Linux。同样支持 Xen 架构的 FreeBSD 和Windows XP 也能够在 Xen 上运行。应用程序(X86)均不需任何修改就可以在 Xen(X86) 上运行，如 Linux 应用程序可以在 XenLinux 上运行而 Windows XP 应用程序可以在 XenXP 上运行。
　　　　Xen 泛虚拟化体系结构
　　　　Xen 监管程序(hypervisor)运行在最高优先级(Ring 0)上，泛虚拟化的客户域运行在较低的优先级上(Ring1-3 )。Xen/X86 泛虚拟化域的内核运行在优先级 1 上，而应用程序仍然运行在优先级 3 上。Xen 服务虚拟域拥有对整个(或部分)物理系统资源的管理功能，如块设备，显示和输入输出等。

　　　　Xen 支持泛虚拟化域和完全虚拟化域的同时运行，如图 2 所示。虚拟域0(即服务虚拟域)作为 hypervisor 的扩充，直接拥有系统硬件输入输出设备(IO,DMA等)，也因此必须具有对这些设备响应的原生(Native)驱动程序。虚拟域0提供对整个系统的管理平台，也是一个设备驱动域。虚拟域1是一个设备驱动域拥有部分物理设备，因此也需要 Native 驱动程序以及向其它客户机提供后端设备驱动程序。虚拟域2是一个用户泛虚拟化域，它不具有物理硬件设备，相反通过虚拟设备(即前端设备驱动程序)向位于虚拟域0 的后端设备驱动程序申请服务而实现对设备的访问。另外，未经修改的操作系统上也可以运行泛虚拟化的前端设备驱动程序以获取更高的性能。
　　　　事件通道(Event Channel)
　　　　事件通道是 Xen 用于虚拟域和 VMM 之间、虚拟域和虚拟域之间的一种异步事件通知机制。在 32 位 X86 架构下共有 1024 个事件通道，共分 8 组，每 128 个通道一组。Xen 架构上的物理中断 (pIRQ) 、 虚拟中断(vIRQ)、虚拟处理器间中断(vIPI)和虚拟域间通信(Inter Domain Communication 简称IDC)均通过事件通道实现。向事件通道发送消息会在每一个虚拟域的内部数据结构(evtchn_pending)中置位以便客户机处理。如果目标虚拟处理器正在运行则需要通过物理IPI 打断当前虚拟机的执行，以及时响应异步事件。
　　　　Xen 架构上的物理中断等同于原生系统上的中断，使拥有原生设备的 Xen 虚拟域可以最大程度地利用原生操作系统(Linux)的设备驱动程序。事件通道机制使得 hypervisor 在向客户机异步通知时可以一次承载多个异步事件(含物理中断)，从而一次虚拟域与 hypervisor 之间的边界穿越可以使客户机批处理多个中断事件，大大提高了系统的总体性能。
　　　　泛虚拟域对虚拟中断和物理中断的处理完全一样，在 Linux 中它们都由 do_IRQ 中断服务程序处理。同时将整个系统的中断数目相应增加到 512 个，其中的前 256 个为物理中断使用以保持与原生系统的相似性，后 256 个为虚拟中断使用。
　　　　Hypervisor 服务(Hypercall)
　　　　Xen 虚拟域本身并不能直接访问本虚拟域以外的物理资源，包括 hypervisor 本身，但是虚拟域可以通过 hypercalls 向监管程序申请各种服务。Hypercalls 就如同传统操作系统下的系统调用，监管程序通过它向各虚拟域提供各种服务，如 MMU 更新(do_mmu_update)、dom0 操作(do_dom0_op)请求、虚拟处理器状态(do_vcpu_op)等等。在 32 位 X86 架构下 hypercall 通过 int0x82 陷阱(trap)指令实现，因为传统操作系统本身并不使用 int 0x82(Linux 使用 int 0x80 作为系统调用指令，int 0x82 并未使用)。Hypercall 的具体功能识别号由 eax 表明，而其它参数则在 ebx, ecx, edx, esi 和 edi 中。为了减少虚拟域和 hypervisor 之间的特权级别(ring)切换次数，Xen 提供对 hypercall 的批处理，即将几个 hypercall 功能请求放在一个列表中由专门的 do_multicall_call请求完成。
　　　　只有特权级别为1的代码(泛虚拟化域的 kernel)才能向 Xen 发送 Hypercall 请求，以防止应用程序(特权级3)的错误调用导致对系统可能的破坏。因此只有运行在特权级1的虚拟域操作系统内核才能申请hypercall。但是一些 Xen 专用的特别程序如 xend 或 xm 也需要有 hypervisor 的服务来完成特殊的操作如生成一个新的虚拟域等，这在 XenLinux 中是通过一个称为 privcmd 的内核驱动程序实现。应用程序通过ioctl 向该驱动程序提出服务请求，运行在虚拟域内核(特权级1)的 privcmd 驱动程序再将服务请求以 hypercall 形式转向 hypervisor 并由后者完成。
　　　　Xen 硬件虚拟机体系结构
　　　　泛虚拟化技术通过对客户机操作系统的修改，绕开了传统 X86 体系结构的虚拟化漏洞，并以良好的性能赢得了在开源软件操作系统(如 Linux)上的广泛关注，但是无法支持象 Windows 这样的私有操作系统。硬件虚拟化技术在芯片硬件层面上弥补了 X86 体系结构的虚拟化漏洞，使 hypervisor 对未经修改的操作系统的支持成为可能，如 Intel®VT 和 AMD SVM 技术。
　　　　Intel® VT 技术引入了一种新的处理器操作，称为 VMX(Virtual Machine Extensions)。VMX 操作可以在根状态(root)或非根状态(non-root)下执行，通常虚拟机监控程序(VMM)在根状态下执行而客户机软件则运行在非根状态。VMM 可以通过虚拟机进入(VM entry)使处理器进入 VMX 非根状态，相反通过虚拟机退出(VM exit)可以使控制权回到 VMX 根状态。
　　　　处理器处于 VMX 根状态时的功能和权限就像没有 VMX 的系统一样，只是引进了一些新的支持 VMX 的指令，而处于非根状态的处理器的行为则受到了限制。某些特定的指令，事件或状态会导致虚拟机退出到 VMM 进行特权资源虚拟化，但客户机软件本身并不知道自己是否运行在虚拟机上。

　　　　VMX 操作新定义了虚拟机控制结构(Virtual Machine Control Structure)，简称VMCS。Xen 对硬件虚拟处理器的管理通过 VMCS 实现，如图3所示。当虚拟机进入时(处理器控制从 VMX 根状态进入 VMX 非根状态)，处理器状态被保存在 VMCS 中(Host状态)，同时客户机状态从 VMCS 中装入。相反当虚拟机退出时(从 VMX 非根状态进入 VMX 根状态)，处理器状态被保存在VMCS 的中(客户机状态)，而Host 状态则从 VMCS 中装入。VMM 可以对不同虚拟处理器的 VMCS 分别设置不同虚拟机退出条件，从而实现对不同客户机的不同虚拟化策略。

　　　　支持硬件虚拟机的 Xen 架构如图4所示，在 64 位 VMM 上的 VMX 虚拟机可以同时支持 32 位客户机和 64 位客户机并存，并且运行在完全的(客户机)特权级别上。运行在硬件虚拟机上的客户机操作系统不需要任何修改，可以支持从开源的 Linux(2.4 版本和 2.6 版本) 到私有的 Windows (WindowsXP, Windows2000) 以及对这些操作系统的安装。有报道指出 FreeBSD 也可以成功在 Xen 硬件虚拟机上运行。
　　　　内存虚拟化
　　　　每一个 X86 客户机的内存地址总是从 0 开始的，而位于该地址的物理内存只有一块。因此监控程序必须把客户机从 0 开始的内存地址映像到其他物理内存页，也因此监控程序必须把客户机虚拟地址(guest virtualaddress)到客户机物理地址(guest physicaladdress)的映像(客户机页表)进行重新映像，即建立客户机虚拟地址到机器物理地址(machine physical address 或 physicaladdress)的映像。Xen泛虚拟化实现采用修改客户机页表的方式实现这一重新映像，硬件虚拟机采用影像页表(shadow page table)方式实现。
　　　　Xen 泛虚拟化的 hypervisor 和客户机共享同一个地址空间。32 位 X86(非 PAE 模式)架构下的 hypervisor 占有 4G 空间的高 64M地址空间即从 0XFC000000 到 0XFFFFFFFF，这通过重定向泛虚拟化客户机的 GDT 表实现。hypervisor 为每一个虚拟域准备一个内部 GDT 表以容纳客户机 GDT，但同时为 Xen 保留一部分描述符空间用于 1) hypervisor 将自身的代码和数据分别映像到ring0, 1 和 3；2) 映像每一个 CPU 的 TSS；3) 映像每一个 CPU 的 LDT。因此泛虚拟化的 Xen 客户机只能使用 0 到 4G-64M 的地址空间，这并不会影响 Linux 应用程序的正常执行(应用程序只使用 0-3G 地址空间)。

　　　　Xen 虚拟域的初始内存大小在该虚拟域启动时确定，各虚拟域以分区(partition)形式共享整个系统的物理内存。XenLinux 实现了气球(ballon)驱动程序(如图 5 所示)来调节各虚拟域之间的物理内存共享。当一个虚拟域 A 需要更多的内存时，它可以通过气球驱动程序向 Hypervisor 提交内存请求，Hypervisor 可以在未分配的内存中或向其它虚拟域 B 通过气球驱动程序回收内存而提供该 A。虚拟域 A 的气球驱动程序在得到Hypervisor 新提供的内存后向操作系统释放。
　　　　设备虚拟化
　　　　除了处理器和内存，计算机的运行离不开外围设备，如硬盘、显示器、键盘鼠标等，同样虚拟机的运行也离不开虚拟平台上的各种各样的设备。这些设备通常可以归纳成 3类：1) 泛虚拟化设备；2) 仿真设备；3) 直接分配设备(Direct Assignment)。泛虚拟化设备是一种存在于特定环境下(Xen)的一种完全虚拟的设备，它需要在客户机操作系统上安装全新的驱动程序以实现对虚拟设备的访问；仿真设备则利用软件方法仿真一个操作系统能够识别的物理设备，通常也是现实世界中已经存在的设备，如IDE 硬盘。对于仿真设备，客户机操作系统及 BIOS 本身具有对该种设备的驱动程序，因此不需重新开发客户机驱动程序；直接分配设备是指将一个系统上物理存在的设备，排他性地赋予一个虚拟机。如在一个有两块以太网卡的机器上，将其中的一块排他性地赋予一个硬件虚拟机如 VMX 虚拟域。拥有直接分配设备的虚拟域即为隔离设备驱动域，如图 2 中的虚拟域 1。
　　　　Xen 虚拟设备
　　　　如图 2 所示，除了虚拟域 0 和隔离驱动域外，Xen 虚拟域 2 本身并不拥有真正的物理设备，而是虚拟设备，如虚拟的控制台(输入输出)，虚拟的块设备甚至虚拟的网络设备。Xenbus 为所有泛虚拟化的设备驱动程序在虚拟域之间的通信提供了一个抽象的总线，Xen 虚拟设备都必须在初始化时向 Xenbus 注册，而将大部分的内部初始化和设置推迟到 Xenbus 探测(probe)时。Xen 常规的块设备驱动程序分成前端驱动程序(Front-enddriver)和后端驱动程序(Back-end driver)，如图 2 上的前端设备驱动程序在接到来自操作系统的读写请求时，通过事件通道和共享内存向位于隔离驱动域的后端设备提出服务请求。后端设备在收到服务请求后则通过该虚拟机上的原生设备完成读写请求。典型的 Xenbus 上虚拟设备包括虚拟块设备(VBD)和虚拟网络接口(VNIF)。
　　　　仿真设备
　　　　如图 4 所示，在硬件虚拟机中，为实现物理设备的共享，客户机的 I/O 访问(含内存映像 I/O-Memory Mapped IO)必须被 Xen 捕获，由设备模型(Device Model)进行仿真。硬件虚拟化技术提供了对客户机 I/O 操作的捕获支持，而对于内存映像 I/O，则通过页缺失(Page fault)被 Xen 捕获。但是 Xen 监控程序本身并没有驱动程序去直接访问这些设备，因此这些 I/O 访问的仿真最终由 Xen交由虚拟域0 完成。从客户机操作系统的角度看，仿真设备同真实的物理设备并没有区别。
　　　　位于 Dom0 的设备模型(Device Model)向硬件虚拟机提供了一个虚拟的 PC 平台(虚拟设备)。每一个硬件虚拟机都可以看到一个完整的虚拟 PC 平台，包括键盘、鼠标、实时时钟、可编程定时器(8254)、可编程中断控制器(8259)、CMOS、软盘、IDE 硬盘、CDROM和 VGA 图形卡等。
　　　　直接分配设备
　　　　客户机操作系统对直接分配设备的访问就如同在原生系统上一样。直接分配设备在本质上是一个不参与虚拟化的真实物理设备，客户机对直接分配设备的 I/O 访问直接传送给物理设备，而物理设备产生的中断也直接传递到该虚拟机，同时直接分配设备的 DMA 操作结果也必须可以直接被该虚拟机接受。

　　　　运行在客户机上的未经修改的操作系统本身并不知道监控程序已经将它的客户机物理地址作了重新映像；另外，DMA 操作只支持小于 4G 的物理内存地址，这在 32 位虚拟机上没有任何问题，但是在 36 位地址的PAE(Physical Address Extensions)模式和 64位机上则是一个大问题；因此未经修改的操作系统并不能够支持直接分配设备。Xen 泛虚拟化域采用修改设备驱动程序的方法，将 DMA 操作的客户机地址转换成物理地址的方法实现物理设备的直接内存存取即DMA。这在物理内存小于 4G 的系统上总能实现，但是对于物理内存大于 4G 的系统则未必可行，因为驱动程序得到的物理内存地址可能大于4G。Intel® 的设备虚拟化技术提供了基于硬件的解决方案，如图 6 所示，通过引入硬件 DMA 地址重新映像的方法，将客户机物理地址转化成机器物理地址(设备 A 和 B 所用的 DMA 地址是客户机物理地址), 从而实现对设备 DMA 的支持。Xen 硬件虚拟机采用的硬件设备虚拟化技术，通过 VMM 向硬件提供客户机 DMA 物理内存到机器物理地址的映像页表，实现未经修改的操作系统对直接分配设备的访问支持。
　　　　Xen 跨平台支持
　　　　Xen 作为一个开源的泛虚拟化解决方案，它的总体框架具有对其他处理器(X86以外)架构的支持。Xen 3.0 已经实现对 Intel® 安腾架构(Itanium)的支持(Xen/IA64)，同时对 IBM Power PC 架构的支持也正在开发中(Xen/PPC)。同 X86 一样，泛虚拟化的 Xen/IA-64 客户机运行在 ring 1-3，通过 Event Channel 和 Hypercalls 同监控程序协同工作。同时 Xen/IA-64支持虚拟块设备(VBD)和虚拟网络(VNIF)。

　　　　在完全虚拟化支持方面，安腾架构也如同 X86 架构一样存在虚拟化支持的漏洞。Intel® VT 技术引入了一个新的处理器模式——虚拟机模式，通过 PSR 寄存器中的 VM(Virtual Machine)位实现。当 VM 位为 0 时，处理器工作在 Host 模式，就如同没有硬件虚拟化技术支持一样。当 VM 位为 1 时，处理器工作在虚拟机模式，具有全部的 4 个ring。处于虚拟机模式时，不管处理器是否处于 ring 0 它对特权资源的访问都会产生打断(interruptions)，进而使处理器进入Host模式。如图 7 所示，VMM 运行在 Host 模式，具有完全的特权级别，处理器被打断后直接进入 VMM，从而实现对特权资源的虚拟化。不同于 X86，安腾架构有一层称之为 PAL(Processor Abstraction Layer) 的处理器抽象层，将不同处理器实现之间的不同特点经过抽象提供一个统一的固件接口(firmwareinterface)。Intel® VT 技术同时实现了 PAL 的虚拟化支持。
　　　　Xen 最新进展
　　　　2005 年 12 月 5 日，XenSource 向外发布了 3.0 版本。Xen 3.0 支持 Intel® VT 技术、客户机 SMP 及客户机 CPU 热插拔、动态移植、32 位/64 位和 PAE 客户机支持、安腾架构支持、安全平台、虚拟机的保存和恢复等等。动态移植技术可以使得一个虚拟机在不同的物理机器间移植而不需要关闭机器，同时不中断虚拟机对外的服务。动态移植理论上可以使虚拟机器的服务永不间断，在物理机器寿命到来之前移植到一个新机器上而继续运行。虚拟机的保存和恢复可以为用户提供机器级别的备份，而不需要关心用户程序本身是否有备份功能，实现灾难时候的恢复。
　　　　预计 2006 年 9 月，XenSourcee 将向外发布他的第一个正式产品 XenEnterprise。XenEnterprise 基于 Xen 3.0.3，在这之前，Redhat 在他的 Fedora Core 4.0 和 Fedora Core 5.0 中已经集成了 Xen，Novell 在他的 SUSE Linux 10.1 和 SLES 10 中也已经集成了 Xen。同时 Redhat 计划在他的下一个企业 Linux 即 RHEL5.0 中集成 Xen。Xen 今天已经是一个事实上的开源虚拟化解决方案标准。
　　　　Xen 虚拟机技术的开源特性、它的接近于原生系统的性能、永不停机的动态移植功能、以及同时对泛虚拟化客户机操作系统和未经修改的操作系统的支持，吸引了包括华尔街分析师在内的广泛关注。利用 Xen 进行服务器加固(Server Consolidation)，搭建有虚拟机组成的网络试验和教学系统，利用虚拟机的保存/恢复(Save/Restore)实现服务器灾难恢复(Disaster Recovery)等等，必将进一步提升国内企事业单位的计算机使用和管理水平，节约宝贵的设备购置经费和极大地提高系统的整体环境安全。
　　　　[Reference]
　　　　[1] Pratt, Ian; Fraser, Keir; Hand, Steve;Limpach, Christian; Warfield, Andrew;Magenheimer, Dan; Nakajima, Jun; Mallick,Asit; “Xen 3.0 and the Art ofVirtualization,” in Proceedings ofLinux Symposium, Volume Two, 2005.
　　　　[2] Jeremy Sugerman, GaneshVenkitachalam and Beng-Hong Lim,“Virtualizing I/O Devices on VMwareWorkstation
　　

　　

　　

　　

　　

　　

　　

　　-----------------------------------------------------------------------------------------------------------------------------------------
　　

　　

　　
在 Linus 明确表示 Linux Kernel 3.0 只是一个版本号的改变，而非里程碑式的飞跃后，许多人对此表达了失望，一个没有重量级功能的新版本似乎配不上这个新的版本号。不过对有些人来说，其中的一个新功能或许可以担的上这个重任，那就是 Xen 的 block backend driver。这个功能加上之前在 2.6.37，2.6.38，2.6.39 添加的几个 Xen 相关的功能，使得即将发布的 Kernel 3.0 包含了所有成为 Xen 的 Domain0 所必须的功能，从此为 Xen 漫长的 Kernel之路划上了一个句号，也标志着 Xen 的发展掀开了崭新的一页。 VMWare，Binary Translation 以及 Full Virtualization     提起虚拟化，一个不得不提的公司或者产品是 VMWare，如果说虚拟化最早的原型可以追溯到上世纪 70 年代的 IBM 的 VM 的话，那么当前的虚拟化热潮却是由 VMWare 引领的。相信有很多人跟我一样，对虚拟化的认知是通过 VMWare 得到的。当我初次接触 VMWare 时，我非常惊讶，居然有这样的产品实现了这么 nice 的功能。VMWare 的成功除了契合了时代的变迁所催生出的虚拟化需求外，也得益于自身产品的优秀。VMWare 产品的简单，便捷，易于理解当然是其中非常重要的一个优势，但更重要的原因来自于VMWare 创造性的解决了 x86 平台内在不支持虚拟化的难题。     x86 平台难以虚拟化的本质主要来自于 CPU 的虚拟化。众所周知，x86 处理器的指令有 4 个特权等级，分别是 Ring 0 ~ 3。正常情况下，application 工作在最低特权级，即 Ring 3，而 kernel 工作在最高特权级，也就是 Ring 0，因为有许多硬件操作必须要在该级别下才能完成。在虚拟化的情况下，也就是有多个 OS 同时运行的情况下，显然这多个 OS 不能同时运行于 Ring 0，因为 OS 需要运行的某些 Ring 0 特权指令将互相干扰。因此一般的解决方案是将虚拟化软件（通常称作Virtual Machine Monitor，或 hypervisor）放在 Ring 0，而将运行在虚拟机里的 guest OS 放到 Ring 1 或 Ring 3 中。一个正常的硬件设计是，当这些原本应该运行在 Ring 0 级别的指令在非 Ring 0 的级别里被执行时，处理器报错，这样运行在 Ring 0 的 hypervisor 就能捕获该错误，从而做相应的处理（比如模拟或替换该指令）实现虚拟化，然而 x86 处理器有一些特权指令在 Ring 0 及非 Ring 0 下都能执行， 并且有不同的含义，这就使得运行在Ring 0 级别里的 hypervisor 无法捕获该指令，而该指令的运行也于原本的意义不同。     对此 VMWare 的解决方案是 Binary Translation，也就是 hypervisor 提前扫描 guest OS 待运行的指令，发现有这种无法捕获或无法虚拟化的特权指令时，将其替换成相应的一系列可捕获的指令，从而实现 guest OS 的虚拟化。当然除了 CPU 的虚拟化外，内存，I/O 设备的虚拟化也不那么容易，不过是 CPU 虚拟化方式的不同决定了各解决方案的不同。VMWare 的这种解决方式最大的优点是 guest OS 无需修改就可以运行在 VMWare 的虚拟机上，当然这个优点是相对于后来出现的Xen 而言的，这种虚拟化方式也称作 Full Virtualization。     VMWare 的 Full Virtualization 解决方案一个致命的缺点是性能上的瓶颈，因为 hypervisor 要在运行时扫描指令，分析并替换，这个消耗是客观无法去掉的。当然 VMWare 采取了很多方法来弥补这些缺陷，使得虚拟机的运行不至于慢的难以忍受，造成的结果就是实现相当复杂。因此在 VMWare 掀起了虚拟化的浪潮之后，许多想投入到这个领域中去的人开始想办法从其它角度来解决 x86 难以虚拟化的难题。 Xen 的出现以及 Paravirtualization     Xen 的开发人员就想出了一个巧妙的办法。Xen 最初始于剑桥大学的一个研究项目，他们的出发点是既然 x86 系统难以虚拟化，那么我就假定 guest OS 运行在一个类似 x86 的平台上，该平台由 Xen 来提供。具体点说就是 Xen 实现了一个类似微内核这样的系统，该系统运行在物理硬件平台上（Ring 0 级别），而 guest OS 运行在 Xen 上（Ring 1 级别），于 VMWare 不同的是，运行在 Xen 上的 guest OS 需要修改，因为 Xen 提供或虚拟的硬件环境已不再是x86 平台，而是一个类 x86 平台，当然再上面的 application 不需要修改。这种虚拟化的方式称作 Paravirtualization。     这就意味着，guest 原本需要运行某些 Ring 0 级别的特权指令才能完成的任务，现在要修改为调用 Xen 提供的相应的指令（称作 hypercall，从实现方式来说类似于 system call）。显然开源的易于修改的 Linux 是最好的目标，这也是早期的 Xen 无法支持 Windows 系统的原因。然而 Xen 的架构还远不止与此，由于 Xen 运行在物理硬件与客户机操作系统之间，因此 Xen 的重要性不言而喻，稍有差错就可能导致所有的客户机崩溃，因此要求 Xen 的代码尽量简练，实际上是越少越好，而一个完整的guest 运行所需要虚拟的硬件除了 CPU 外还有很多，例如内存，I/O 设备等等。显然如果 Xen 即支持底下的硬件设备，又要虚拟上面需要的硬件设备，那么 Xen 的实现无异于重写一个 Linux。Xen 的想法是 Xen 只支持最基本的硬件设备，也就是 CPU，内存，中断等，其它 I/O 设备由一个专门的 guest OS 来支持，而其余的 guest OS 要想访问该设备，需要通过 Xen，然后再传递到该特殊的 guest。Xen 为此将 guest 分为两个级别，一个是有访问 I/O 设备特权的特殊的guest，称作 Domain0，其它的称作 DomainU。     因此对 Linux 来说，要想运行在 Xen 上，就必须要修改 Kernel 代码，并且根据 Linux 是运行在 Domain0 级别还是 DomainU 级别而修改的代码也不同。早期的 Xen 采用 Linux Kernel 2.6.18 作为基础，进行修改并实现了 Domain0 以及 DomainU 的功能。     由于 Xen 提供的虚拟化解决方式的性能优势，以及 Xen 的开源的特性，Xen 很快就被炒上了天。当初成立该研究项目的大学教授成立了公司，并获得了风投的青睐，继而被 Citrix 收购；各大发行版纷纷抢着支持 Xen 作为自己的虚拟化方案；很多创业公司也一夜之间冒了出来，研究 Xen 或者利用 Xen，以期望在未来的虚拟化与云计算大潮中能博得一位；Xen 俨然成了虚拟化的未来。 硬件虚拟化技术的进步以及 KVM     然而技术的发展往往非人所料，由于虚拟化浪潮的热火朝天，以及 x86 平台难以虚拟化的本质，使得 Intel 与 AMD 这两大芯片商开始思考如何在处理器里添加功能克服原有的缺陷。于是在 2006 年，Intel VT-x 与 AMD-V 出现了。简单的说这两个 CPU 扩展就是在保持四个 Ring 特权级别的条件下，分出两个 forms，分别给客户机与 hypervisor 使用，由于每个 form 都有这四个 Ring 级别，因此客户机的特权指令的捕获就可以轻松实现了。硬件技术的出现很快就带动了软件技术的发展，很快有利用这种硬件虚拟化技术的软件出现了，没错，就是KVM。     比起 Xen 来，KVM 的实现更加简洁而优雅，除了利用硬件的支持，KVM 还利用了现有的 Linux Kernel 的 CPU 调度等机制，因此 KVM 不需要像 Xen 那样重新实现一个复杂的 guest OS 的调度机制，这个任务交给 Linux Kernel 来完成，此时 guest OS 对 Linux Kernel 所在的 host 来说就是一个进程。此外 KVM 的实现方式也不需要修改 guest OS，因此 KVM 的出现很快引起了 Kernel 社区开发人员的兴趣，几乎是在最短的时间内，KVM就进入了 Kernel，此时 Xen 仍然按照自己的开发模式在按部就班的进行着。 Xen 的问题     相对 KVM 来说，Xen 是一个庞大的项目，一个完整的 Xen 的搭建，需要四个组成部分，首先是最底层的 hypervisor，其次是需要修改的 Domain0 与 DomainU Kernel，最后是上层的应用管理进程。可以看出，hypervisor 与 管理进程是独立的，可以轻易安装，然而 Domain0 与 DomainU 却需要修改后的 Kernel 支持。早期 的 Xen 的源代码库里有一个修改后的 2.6.18，可以下载，编译然后安装。     这个办法并不是长久之计，Linux Kernel 的发展是很快的，一劳永逸的办法是尽快将 Xen 对 Kernel 的修改 merge 到上游 Kernel 中去。然而 Xen 的开发人员似乎并不热衷于 merge 对 Kernel 的修改。带来的问题是，对发行版来说，他们不得不花大量的精力来维护 Xen 相关的 Kernel patch，这个问题在 RHEL 5 上达到了登峰造极式的表现，RHEL 5 的 Kernel SRPM 里与 Xen 相关的 patch 有上百个。此外一些早期投入到 Xen中去的小公司在快速开始后，发现他们不得不面对一些 tricky 的问题，而且很难判断是 Xen hypervisor 的问题还是 Dom0 或 DomU kernel 的问题，或者有时候在 backport 一些最新的 Kernel bug 修复到 Dom0/DomU 时困难重重。Xen 成了这些人的梦魇。     其实 Xen 的开发人员也不是没想过将 Kernel 的修改 merge 到上游去，然而如上面所说，Xen 对 Kernel 的修改是通过类似将 Linux 移植到一个新平台（x86 的一个子平台）的方式进行的，其中有大量的对 x86 平台代码的修改与复制，对此 Kernel 开发人员非常抵触。再加上 Xen 的开发人员并不热衷于此，Xen 进入 Kernel 之路面临着一个个障碍，而且一拖就是几年。     在 KVM 逐渐开始成熟起来，而 Xen 又迟迟无法进入 Kernel 之际，Red Hat 做出了一个艰难的决定，抛弃 Xen，转投 KVM，并收购了最初开发 KVM 的公司。Red Hat 的决定带来了巨大的影响，不少发行版都抛弃了 Xen，很多人开始预言 Xen 即将灭亡，关于 Xen 与 KVM 之争也随处可见，Red Hat 与 始终支持 Xen 的 Novell 就两者的优劣还吵了一架。同时随着 KVM 的成熟，Xen 进入 Kernel 的阻力更大，许多 Kernel 开发人员认为没有必要在Kernel 里同时支持两个虚拟化框架，有 KVM 就足够了。而有关推动 Xen 修改进入 Kernel 的努力再次失败，Linus 明确表示，Xen 的代码从开发角度来说就是一个混乱，这样的代码进入 Kernel 只会给 Kernel 开发人员带来维护上的灾难，除非 Xen 的开发人员按照 Kernel 的开发规范重写 Kernel 相关的功能，否则 Xen 的修改不可能进入 Kernel。 漫漫人生路     在 Linus  明确对 Xen 的问题表态后，Xen 的开发人员开始了漫漫的 Kernel 人生路。此前在 pv_ops 出现后，Xen 的 DomU 部分已经进入了 Kernel，唯有剩下的 Dom0 部分。Xen 的开发人员开始一点一点的重写，提交，被打回，再重新修改提交，经过了两年时间的积累，Xen 对 Kernel 的修改终于在去年 2.6.37 时有了一个质的变化，2.6.37 包含了核心的 Dom0 支持，当然这还不够，Dom0 还需要一些 backend driver 来支持从 DomU过来的设备访问请求，不过这些相对来说已不那么困难，轻舟已过万重山。 Xen vs KVM     与此同时，在 Red Hat 加入 KVM 后，KVM 的发展也在日新月异。KVM 虽然利用了 CPU 的虚拟化功能，但对外围设备尤其是硬盘与网卡的虚拟还是通过 QEMU，这样的 Full Virtualization，效率并不高。为了提高效率，就要像 Xen 那样采用 Paravirtualization 的方式，即 guest 的 Kernel 知道自己访问的硬盘/网卡并不是真正的硬件设备，很快 Kernel 内部有了 VirtIO 的框架。     硬件的发展同样迅速，在第一代虚拟化技术催生了 KVM 这样的软件后，第二代的虚拟化技术致力于在性能上的提高，比如 Intel 的 EPT 以及 VT-d，AMD 的 RVI 以及 IO-MMU。在这些技术被 KVM 采用后（当然也被 Xen 采用），Xen 是否还具有天然的性能上的优势就真不好说了。相反，由于 Xen 的 Dom0 支持迟迟无法进入 Kernel，使得很多人在选择虚拟化技术时不得不三思。天平已然倾向了 KVM。 最后     到底 Xen 与 KVM 孰优孰劣，尤其是性能，不是一个轻易就可以下结论的问题。性能上的比试除了产品的架构外，更多依赖于任务本身是 CPU bound 还是 I/O bound，以及在测试过程中对搭建平台的一步步调整。不管怎么说，Xen 依然有存在的价值，Xen 也有大量的用户群。Xen 的 Kernel 部分正式进入 Linux Kernel 是一件值得高兴的事情，相信很多发行版将重新开始支持 Xen，至少在虚拟化技术前，我们又有了一个方便的选择。对于 Xen 来说，这也意味着它与 KVM 的竞争又站到了同一起跑线上。     纵观 Xen 这短短几年的发展，既有巅峰时的人人追捧，也有没落时的失意。除了虚拟化大环境技术上的变迁外，更主要的原因在于 Xen 的开发策略没有坚持通常所说的上游优先（upstream first），也就是在代码还没有进入上游的 Kernel 之前，就发布出去，从而为日后的弯路打下了基础。这样的教训令人足戒。Xen 的 Dom0 虽然进入了 Kernel，但 Xen 的故事并未结束，Xen 仍然有一些代码需要进入 Kernel，Xen 本身对硬件虚拟化技术的利用也有待提高，不管怎么说，Xen 又重新回到了人们的视野，至于 Xen 是否还能回到巅峰，只能拭目以待了。 资源 严格来说，本文的很多术语并不完全准确，所以，如果您有兴趣，您可以延伸阅读：  1. 我爱 Wikipedia: Virtualization, Hardware Virtualization, x86              Virtualization, Full Virtualization, Paravirtualization, VMWare, Xen,      KVM。   2. Intel 的网站上有许多非常棒的关于 Virtualization 的文章，比如这一篇。   3. VMWare 的网站上有许多非常棒的关于 Virtualization 的文章，比如这一篇。  4. Xen 的著名的论文以及架构介绍。   5. KernelTrap 对 KVM 的主要开发者的专访。   6. LWN 上 Virtualization 相关的文章 Xen: finishing the job, Xen again。