Xen虚拟化之一：Xen环境组件详解

Xen是一个开放源代码虚拟机监视器(Virtual Machine Monitor，简称为VMM)，由剑桥大学开发，它致力于实现在单个计算机上运行多达128个有完全功能的操作系统。Xen通过一种叫做半虚拟化(paravirtualization)的技术获得高效能的表现（较少的效能损失，典型的情况下大约损失 2%，在最糟的情况下会有 8% 的效能耗损；与其它使用完全的虚拟化却造成最高到 20% 损耗的其他解决方案形成一个明显的对比），甚至在某些与传统虚拟技术极度不友好的架构上（x86），Xen也有极佳的表现。

Xen虚拟化环境由几个虚拟化组件协同实现：Xen Hypervisor、Domain 0和Domain U。 

Xen架构 (图片来源：http://wiki.xen.org/wiki/Xen_Overview)

1.1   Xen Hypervisor

 Xen Hypervisor是计算机硬件的软件抽象层，它直接运行于硬件之上，并将其计算能力通过抽象接口(虚拟机)提供给运行于其上的任何操作系统。它的首要任务在各虚拟机之间进行CPU资源调度、内存资源分配及中断请求管理，并负责控制共享处理环境的各虚拟机的执行。但它并不负责实现计算机系统应该具备的网络、外部存储设备、显示设备或其它通用I/O功能等。

1.2 Dom0

Xen虚拟化环境中用域(domain)来描述各虚拟机，每个域都有其ID等属性，因此各虚拟机常表示为domain 0、domain 1等，也可以使用简写的方式，如dom0。Dom0是运行Xen Hypervisor上的一个独特的虚拟机，其操作系统内核为经过特殊修改的Linux内核，其能够直接访问硬件I/O资源及与其它虚拟机进行交互。其它的域没有直接直接访问硬件I/O资源的权限，并且彼此间是高度隔离的。因此，dom0也被称作特权域，其它域则统一称为DomU(Unprivileged Domain)。需要注意的是，DomU通过Dom0来实现I/O功能，因此，在DomU运行之前必须先启动Dom0。

Linux内核自 2.6.37 版本起添加了对Xen Dom0的支持，并且自3.0的版本起添加进了Xen所需要的关键性驱动及优化，因此，只需要在3.0及之后版本的内核编译时启用了相应的选项，其就可以直接运行于Dom0。

Dom0提供了两种两类特殊驱动：网络后端驱动(Network Backend Driver)和块设备后端驱动(Block Backend Driver)，分别用以支持来自DomU的对网络及本地磁盘的访问请求。网络后端驱动通过直接与本地网络设备交互来处理来自于DomU的各网络相关请求，块设备后端驱动则基于与本地磁盘交互来执行DomU的数据读写请求。

Dom0通常会包含一个工具栈(Toolstack)，其能够实现让用户完成虚拟机的创建、删除、配置等功能。此工具栈还提供了一个访问接口，因此，其管理功能还可以通过相应的命令行工具、图形化控制台或者如Cloudstack或Openstack类的云计算环境来完成。

1.3 DomU

如前所述，DomU是非特权域，它们均无权限直接访问硬件资源。Xen支持两种不同类型的虚拟模式：PV(Paravirtualization)和HVM(Hardware-assisted or Full Virtualization)，它们可以同时运行于同一个Xen Hypervisor上，并且甚至可以在HVM环境使用PV技术，这也称作PV on HVM。

1.3.1 Xen半虚拟化(Xen Paravirtualization)

半虚拟化(Paravirtualization，简称为PV)是由Xen开发的高效且轻量级的虚拟化技术，现已经为众多虚拟化平台所借用。PV不要求CPU支持虚拟化扩展，但依赖于Xen-PV-enabled内核和PV驱动程序，因此，客户机(guest)明确知道自己运行于hypervisor之上，它不需要仿真硬件，从而能高效运行。目前，已经为Linux、NetBSD、FreeBSD和OpenSolaris实现了Xen-PV-enabled内核，而且自 2.6.24 起，Linux内核已经通过Linux pvops framework原生支持Xen-PV，因此，大多数的Linux发行版都能直接运行于PV环境。

PV客户机中包含两类特殊驱动：网络前端驱动(Network Frontend Driver)和块设备前端驱动(Block Frontend Driver)，分别用以与Dom0中对应的后端驱动通信以完成网络访问和块设备访问。

Xen PV (图片来源：http://wiki.xen.org/wiki/File:XenPV.png)

1.3.2 Xen完全虚拟化(Xen Full Virutalization)

完全虚拟化也称作硬件辅助的虚拟化(Hardware-assisted virtualizion)技术，它利用CPU的特殊扩展功能实现客户机的虚拟。HVM依赖于Intel VT或AMD-V硬件扩展，同时，Xen还使用Qemu来为HVM模拟PC硬件，如BIOS、IDE磁盘控制器、VGA图形适配器、USB控制器及网络适配器等，而CPU的虚拟化扩展技术还能够大大提升这些仿真硬件的性能。HVM不要求操作系统做出任何修改即可正常运行，故此，windows等操作系统均可支行于HVM环境。但需要注意的是，HVM虚拟机需要仿真多种硬件，因此其性能不如PV虚拟机。

1.3.3 P V on HVM

为了提高其性能，HVM客户机也可以使用特殊的半虚拟化驱动(PVHVM或PV-on-HVM驱动)，这类驱动是为HVM环境专门优化的PV驱动，由此可以使得HVM不再依赖于磁盘及网络I/O的仿真，从而在HVM上提供接近甚至优于PV环境的性能。

1.4 工具栈(toolstack)、管理API(Managment APIs)和控制台(Consoles)

Xen能够与多个不同的工具栈结合工作，如默认的工具栈、Libvirt工具栈及XAPI工具栈。通常，每个工具栈都提供了一个API及相应的命令行工具。

Xen Toolstack (图片来源：http://wiki.xen.org/wiki/File:ToolStacks.png) 

1.4.1 Libxenlight (libxl)

 libxenlight是一个底层的、轻量级C程序库，便于理解、修改和扩展，其目的是为所有的工具栈提供一个通用、简单、健壮的API，也是xen操作的基础代码。共设计目标：

◇     提供机制，而非策略

◇     无状态

◇     向上隐藏xenstore、libxenctrl和libxenguest

◇     尽可能简单 

1.4.2 常见的工具栈

◇ Default / XEND

Xen 4.0及之前的版本中默认使用的工具栈，Xen 4.1提供了新的轻量级工具栈xl，但仍然保留了对Xend/xm的支持，但Xen 4.2及之后的版本已弃用。但xl在很大程度上保持了与xm的兼容。

◇ Default / XL

xl是基于libxenlight创建的轻量级命令行工具栈，并从Xen 4.1起成为默认的工具栈。xl与Xend的功能对比请参照http://wiki.xen.org/wiki/XL_vs_Xend_Feature_Comparison。xl的运行不需要用到xend服务。

◇ XAPI / XE

XAPI即Xen管理API(The Xen management API)，它是Citrix XenServer和XCP默认使用的工具栈。目前，其移植向libxenlight的工作正进行中。XAPI是目前功能最通用且功能最完备的Xen工具栈，CloudStack、OpenNebula和OpenStack等云计算解决方案都基于此API管理Xen虚拟机。

工具栈架构 (图片来源：http://www.slideshare.net/xen_com_mgr/xen-summit-amd2010v3) 

◇ libvirt / VIRSH

 libvirt是一个通用的虚拟化API和工具组件，可用于管理众多的虚拟化技术，目前1.0版本业已移植到libxenlight。 

libvirt架构 (图片来源：http://blog.imm.cnr.it/content/collegamento-macchine-virtuali-con-libvirt) 

1.4.3 选择合用的工具栈

三种流行的工具栈功能对比 (图片来源：http://wiki.xen.org/wiki/Choice_of_Toolstacks)

1.4.4 Xen高级管理工具

除了基础的工具栈外，Xen还有许多高级管理工具，它们以各种方式为Xen提供了更为便捷的管理接口。常见的如virt-manager/libvirt、xen-tools、Zentific、Convirt、Xen Orchestra和Ganeti等，此外还有基于云平台的管理工具，如Eucalyptus、OpenNebula和openQRM等。

具体的工具列表，请参见http://wiki.xen.org/wiki/Xen_Management_Tools。 

1.5 XenStore

XenStore是域间共享的信息存储空间，它也是一个有着层级结构的名称空间或数据库，位于Dom0上由Dom0进行管理，支持事务和原子操作，如读写一个“键”。各域通过向XenStore数据进行读写操作完成彼此间的通信。在有新的值写入XenStore时，对应的域则会收到通知。

XenStore通常用作控制DomU中设备的机制，可通过多种不同的方式对其进行访问，比如在Dom0中使用Unix套接字、内核API或者ioctl接口/proc/xen/xenbus。设备驱动可以通过这些接口之一向XenStore写入请求等。尽管驱动程序可以向XenStore存储任何数据，但它主要设计用来存储较少的数据片断，如配置信息或状态信息。XenStore通常存储为Dom0的/var/lib/xenstored/tdb文件。

下一节：“Xen虚拟化系列之二：在RHEL6.3 x86_64安装配置xen 4.2详解”

本文出自 “马哥Linux培训” 博客，转载请与作者联系！