Xen虚拟化概述：
一.Xen虚拟化类型
1.半虚拟化 Para-Virtualization
半虚拟化是Xen主导的虚拟化技术，这种技术允许虚拟机操作系统感知到自己运行在XenHypervisor上而不是直接运行在硬件上，同时也可以识别出其他运行在相同环境中的客户虚拟机。
在XenHypervisor上运行的半虚拟化的操作系统，为了调用系统管理程序（XenHypervisor），要有选择地修改操作系统(即内核)，然而却不需要修改操作系统上运行的应用程序。由于Xen需要修改操作系统内核，所以您不能直接让当前的Linux内核在Xen系统管理程序中运行，除非它已经移植到了Xen架构。不过，如果当前系统可以使用新的已经移植到Xen架构的Linux内核，那么您就可以不加修改地运行现有的系统。
简单来讲就是：为了调用Hypervisor，需要修改当前的Linux内核(除非已经植到Xen架构的内核)，然后选择该修改后的内核运行Linux系统；
以上摘自网络
半虚拟化也称半虚拟化简称为PV，PV不需要host的CPU的虚拟化扩展，因此虚拟化的是硬件架构(不支持硬件辅助虚拟化)，过去PV的Guests(DomU)和control domain(Dom0)需要内核和硬件驱动的支持，但是现在只需要部分内核和操作系统即可；
PV实现了以下功能：
Disk and Network drivers
Interrupts and timers
Emulated Motherboard and Legacy Boot
Privileged Instructions and Page Tables
PV的IO驱动程序
Disk和Network的支持(通常PV也可以应用于其他外围设备，如音频，USB等)是通过一对PV front-end和PV back-end 端驱动实现的。架构上，PV通过开放额外的通信通道(hypervisor和Guests上操作系统之间)凭借PV前端和后端驱动来工作的。
下图概述了硬件驱动如何与PV的前端及后端交互
PV架构：
官方详细资料：
2.完全虚拟化 Hardware Virtual Machine
完全虚拟化又称“硬件虚拟化”，简称HVM，是指运行在虚拟环境上的虚拟机在运行过程中始终感觉自己是直接运行在硬件之上的，并且感知不到在相同硬件环境下运行着其他虚拟机的虚拟技术。
在Xen Hypervisor运行的完全虚拟化虚拟机，所运行的操作系统都是标准的操作系统，即：无需任何修改的操作系统版本。同时也需要提供特殊的硬件设备。
值的注意的是，在Xen上虚拟的Windows虚拟机必须采用完全虚拟化技术。
以上摘自网络
完全虚拟化或硬件辅助虚拟化采用host CPU的虚拟化扩展来虚拟化Guests。HVM需要Intel-VT或AMD-V硬件扩展的支持。Xen
使用Qemu来模拟PC硬件，包括BIOS，IDE磁盘控制器，VGA图形适配器、USB控制器、网卡等。虚拟化硬件扩展用于提高仿真的性能。完全虚拟化的Guest不需要任何内核支持，这意味着Windows操作系统可以作为一个HVM Guest。因为需要模拟，所以完全虚拟化的Guests比半虚拟化的Guests的速度要慢。
注意，对于I/O来说可以使用PV Drivers来加速HVM Guests，但在windows上这需要安装适当的PV Drivers；
下图显示了HVM以及HVM+PV的不同
下图显示了HVM+PV的架构
官方资料：
补充：CPU完全虚拟化IO半虚拟化(PVHVM)
为了提高性能，完全虚拟化的Guests可以使用特殊的半虚拟设备驱动程序（PVHVM或PV-on-HVM驱动）。这些驱动程序在HVM环境下优化PV驱动，模拟磁盘和网络IO的旁路运行，从而让PV在HVM中有更好的性能。这意味着对guests上的操作系统来说可以得到最佳的性能，如windows操作系统。
注意，PV(半虚拟化)的Guests自动使用PV驱动：因此不需要这些驱动程序,因为你已经自动使用了优化的驱动程序。PVHVM驱动程序只会在HVM（全虚拟化）guest虚拟机中需要。
HVM和HVM+PV以及PVHVM的不同
官方资料：
二.基本组件
Xen虚拟化架构
hypervisor直接运行于硬件之上，负责处理CPU，内存和中断，是退出bootloader程序后第一个运行的。在hypervisor上运行着许多虚拟主机，一个运行着的虚拟主机示例被称为Domain或Guest，其中一个特殊的Domain被称为Domain0，它包含了系统中所有设备的驱动，它也包含了一个控制栈(console stack)来管理其他Guest的创建，销毁和配置；
其中的组件有：
官方资料：
1.Hypervisor
一个格外精简(小于150000行代码)的软件层，直接运行于硬件之上，是Guest操作系统与硬件资源之间的访问接口。通过将Guest操作系统与硬件进行分类，Hypervisor可以允许Guest操作系统安全，独立的运行在相同硬件环境之上；
2.Guest Domains/Virtual Machines(也可以理解为DomainU)
被虚拟化的环境，每一个都运行着自己的操作系统和应用程序。Hypervisor支持两种虚拟化模式：半虚拟化和完全虚拟化。在一个Hypervisor上同一时间内可以运行任意的Guest类型(操作系统)。在HVM Guest上也可以使用半虚拟化技术：在PV
和HVM之间创建一个连续体，这种方法被称为PV on HVM。Guests从硬件上完全隔离：换句话说，它们没有权限去访问硬件
和I/O功能。因此它们被称为非特权域(或DomainU)；
3.The Control Domain (Domain 0)
是一个具有特殊权限的特殊虚拟主机，如直接访问硬件的能力，处理所有对系统I/O功能的访问，和其他虚拟主机交互等。它还提供了一个在外部能控制系统的接口，如果没有了Domain0，那么Hypervisor就无法工作了，而且它还是系统启动的第一个虚拟主机；
4.Toolstack and Console
Domain0包含一个控制栈(也成为工具栈Toolstack)，它允许用户管理虚拟主机(包括创建，销毁和配置)。该工具栈提供的一个接口可以是一个命令行控制台，图形界面接口或者像OpenStack或CloudStack的cloud orchestration stack
5.Xen Project-enabled operating systems(操作系统)
Domain0需要一个Xen支持的内核，半虚拟化的Guest需要一个支持PV的内核。最近的Xen支持的Linux发行版(如centos6)通常包含包括Hypervisor和Tools的安装包，可以在各镜像站中的centos中看到，如
那么再看Xen的组件结构图就容易了
三.Xen基本体系架构及运行原理(摘自网络)
1.体系架构
Xen 的 VMM ( Xen Hyperviso ) 位于操作系统和硬件之间，负责为上层运行的操作系统内核提供虚拟化的硬件资源，负责管理和分配这些资源，并确保上层虚拟机（称为域 Domain）之间的相互隔离。Xen采用混合模式，因而设定了一个特权域用以辅助Xen管理其他的域，并提供虚拟的资源服务，该特权域称为Domain 0，而其余的域则称为Domain U。
Xen向Domain提供了一个抽象层，其中包含了管理和虚拟硬件的API。Domain 0内部包含了真实的设备驱动（原生设备驱动），可直接访问物理硬件，负责与 Xen 提供的管理 API 交互，并通过用户模式下的管理工具来管理 Xen 的虚拟机环境。
Xen2.0之后，引入了分离设备驱动模式。该模式在每个用户域中建立前端（front end）设备，在特权域(Dom0)中建立后端(back end)设备。所有的用户域操作系统像使用普通设备一样向前端设备发送请求，而前端设备通过IO请求描述符(IO descripror ring)和设备通道（device channel）将这些请求以及用户域的身份信息发送到处于特权域中的后端设备。这种体系将控制信息传递和数据传递分开处理。
在Xen体系结构设计中，后端设别运行的特权域被赋予一个特有的名字---隔离设备域(Isolation Device Domain, IDD)，而在实际设计中，IDD 就处在Dom0中。所有的真实硬件访问都由特权域的后端设备调用本地设备驱动 (native device drive)发起。前端设备的设计十分简单，只需要完成数据的转发操作，由于它们不是真实的设备驱动程序，所以也不用进行请求调度操作。而运行在IDD中的后端设备，可以利用Linux的现有设备驱动来完成硬件访问，需要增加的只是IO请求的桥接功能---能完成任务的分发和回送。
Xen体系架构图
2.Domain 管理和控制
开源社区中将一系列的Linux精灵程序分类为“管理”和“控制”两大类。这些服务支撑着整个虚拟环境的管理和控制操作，并且存在于Domain 0虚拟机中。下面将对直接服务进行详细的描述。
注：为了清晰的描述Xen的运行流程，画图时将精灵程序放在Domain0外部来描述，但事实上所有精灵程序都存在于Domain 0之中。
2.1 Xend
Xend精灵线程是一个Python应用程序，它作为Xen环境的系统管理员。它利用Libxenctrl类库向Xen Hypervisor发出请求。
所有Xend处理的请求都是由XM工具使用XML RPC接口发送过来的。
2.2 Xm
用于将用户输入通过XML RPC接口传递到Xend中的命令行工具。
2.3 Xenstored
Xenstored精灵程序用于维护注册信息，这些信息包括内存和在连接Domain 0和所有其他Domain U之间的事件通道。Domain 0虚拟机利用这些注册信息来与系统中其他虚拟机建立设备通道，即帮助Domain U虚拟机访问硬件资源。
2.4 Libxenctrl
Libxenctrl是C程序类库，用于让Xend具有通过Domain 0与Xen Hypervisor进行交互的能力。在Domain 0中存在一个特殊的驱动程序称作privcmd，它将请求发送给Hypervisor。
2.5 Qemu-DM
在Xen环境下，每个完全虚拟化虚拟机都需要拥有自己的Qemu精灵程序。Qemu-DM处理在Xen环境下完全虚拟化客户机所能允许执行的所有关于网络和磁盘请求和操作。Qemu程序必须存在于Hypervisor之外同时又需要访问网络和I/O，所以Qemu-DM必须存在于Domain 0 中（参见前面章节对Domain 0 的描述）。
未来版本的Xen中，一种新的工具Stub-DM将会提供一系列对所有完全虚拟化客户机都可用的服务，以此来替代需要在每个虚拟机上都生成一个Qemu的逻辑。
2.6 Xen Virtual Firmware
Xen Virtual Firmware是被嵌入到所有完全虚拟化客户机中的虚拟的BIOS系统，来确保所有客户操作系统在正常启动操作中接收到标准的启动指令集并提供标准的软件兼容环境。
3.半虚拟化环境下Domain 0与Domain U通信
Xen Hypervisor不负责处理网络和磁盘请求，因此半虚拟化客户机（Domain U PV）必须通过Domain 0 与Xen Hypervisor进行通信，从而完成网络和磁盘的操作请求。下面以半虚拟化客户机（Domain U PV）执行向本地磁盘写入数据为例描述Domain 0与Domain U PV的交互过程。
半虚拟化客户机（Domain U PV）的PV Block Driver接收到要向本地磁盘写入数据的请求，然后通过Xen Hypervisor将与Domain 0共享的本地内存中的数据写入到本地磁盘中。在Domain 0 和半虚拟化Domain U之间存在事件通道，这个通道允许它们之间通过存在于Xen Hypervisor内的异步中断来进行通信。Domain 0将会接收到一个来自于Xen Hypervisor的系统中断，并触发Domain 0中的Block Backend驱动程序去访问本地系统内容，并从与半虚拟化客户机的共享内存中读取适合的数据块。从共享内存中读取的数据随后被写入到本地磁盘的指定位置中。
Domain U PV执行磁盘操作实例
上图中所显示的事件通道是直接连接Domain 0 和Domain U PV是为了清晰和简单的描述系统是如何运行的。但事实上，事件通道（Event Channel）运行于Xen Hypervisor中，并在Xenstored中注册特定的系统中断，以此来让Domain 0 和Domain U PV能够通过本地内存快速的共享信息。
参考文章：
http://my.oschina.net/davehe/blog/94039#navbar-header
http://wangzan18.blog.51cto.com/8021085/1727106 小小水滴博客
关于虚拟化技术可参考：
http://wangzan18.blog.51cto.com/8021085/1730261
