目录：
1. Xen的简介
1.1 Xen的大体结构
1.2 Xen对VM的称呼
1.3 Xen对CPU和内存的虚拟化过程
1.4 Xen对IO设备的虚拟化过程
1.5 Linux Kernel对Xen的支持
1.6 Xen版本发布简史
1.7 Xen的工具栈
1.8 XenStore
1.9 虚拟化中的四种网络模型
1.10 Xen的安全问题导读
2. Xen的安装及配置文件说明
2.1.1 在CentOS6.6上运行Xen的条件
2.1.2 Xen的配置
2.2.1 Xen 启动DomU的配置文件说明
2.2.1.1 如何创建一个Xen PV模式的VM 【注:HVM模式的VM创建参见试验部分】
3. 使用libvirt实现Xen虚拟机的图形管理
4. PV DomU的根文件系统可以以多种不同的方式安置
1. Xen的简介
Xen是一个开源的可直接运行于硬件层之上的虚拟化软件,它可在传统虚拟技术极度不友好的X86架构上也有上佳的表现它是英国剑桥大学开发的开源虚拟化软件,它的初衷是在一台物理机上运行上百台虚拟机;
Xen的设计十分精巧,它属于虚拟化type-I ,因为Xen实际是一个简化版的Hypervisor层;相对于Type-II类型的基于Host的虚拟化(如:VMware Workstattion),其性能相对会较好;Xen仅对CPU和Memory直接接管，而其它IO硬件驱动则由其上运行的第一个虚拟机来提供支持.这样做的原因是: Xen无法为众多IO设备开发驱动,而硬件设备的开发商也不会专为Xen提供驱动,因此Xen采用了这样一种特别的设计方式。
Xen默认认为自己是直接运行于硬件层之上的虚拟化软件,并且可以直接驱动CPU和内存,需注意CPU和内存是所有想要运行的操作系统必须能直接支持的,但Xen为保证自身的小巧,它并没有提供虚拟机的管理接口,因此它采用了一种独特的方式,先运行一台特权虚拟机,且这台VM必须支持Kernel的修改,因此选择开源的Linux做为特权VM是最合适的,这样也可方便采用Linux所支持的方式来开发虚拟机管理接口,实现与Xen Hypervisor层直接交互来完成为VM分配CPU和内存资源 及 创建、删除、停止、启动VM的管理接口;通常这台特权虚拟机一定会采用当前比较流行的Linux发行版,因为它能支持更多IO硬件设备,如:网卡,磁盘,显卡,声卡等; 到目前为止，NetBSD, GNU/Linux, FreeBSD和Plan 9，OpenSolaris等系统已经支持已半虚拟化方式运行在Xen的DomU中；目前Xen已经支持x86，x86_64和ARM等平台，并正在向IA64、PPC移植。移植到其他平台从技术上是可行的，未来有可能会实现。
Xen虚拟机支持在不停止的情况下在多个物理主机之间实时迁移。在操作过程中，虚拟机在没有停止工作的情况下内存被反复的复制到目标机器。虚拟机在最终目的地开始执行之前，会有一次60-300毫秒的非常短暂的暂停以执行最终的同步化，给人无缝迁移的感觉。类似的技术被用来暂停一台正在运行的虚拟机到磁盘，并切换到另外一台，第一台虚拟机在以后可以恢复。
1.1 Xen的大体结构:
Xen的组成分为三部分:
(1) 硬件层之上的Xen Hypervisor层：负责直接驱动CPU和Memory这些基础硬件,
为其它所有虚拟机提供CPU、内存、Interrupt(中断)管理,并且还提供了HyperCall的调用。
(2) 第一个虚拟机: 此虚拟机在Xen中称为特权虚拟机: 它有整个虚拟化环境的访问权,并负责创建用户级虚拟机,
并为其分配I/O设备资源.它的Kernel是经过特别修改的VM,它可以直接访问IO硬件也可访问其它用户VM。
(3) 其它众多虚拟机: 这些虚拟就是用户级虚拟机: 它们是实际提供给用户使用的虚拟机,也是相关隔离的VM。
需要注意：Xen支持三种虚拟化,当然此处的虚拟化特指CPU的半虚拟化或完成虚拟化.
<1> Para-Virtualization(半虚拟化): 在这种虚拟化中,CPU不要求支持HVM特性,
但GuestOS的Kernel必须允许被修改.否则将无法支持该GuestOS运行在DomU中。
这是因为必须让GuestOS知道自己是运行在虚拟化环境中,这样它在进行特权指令操作硬件时，
会直接发起HyperCall向Xen Hypervisor发起请求来完成所谓的硬件操作。
在PV技术下，能够运行在DomU上的OS包括：
Linux, NetBSD, FreeBSD, OpenSolaris
<2> HVM(基于硬件的完全虚拟化): 此种虚拟化需要借助于Intel的VT-x 或 AMD的AMD-v 的HVM技术
及Qemu的IO硬件模拟，才能支持GuestOS的kernel不修改,就可直接被DomU支持。
这是因为Xen Hypervisor是运行在CPU的环-1上的，GuestOS的kernel是运行在CPU的环0上,GuestOS
向环0上发起的所有假特权指令调用都由CPU直接捕获,并交由环-1上的Xen Hypervisor处理,最后由Xen代其执行
这样DomU若发起关机指令时,Xen仅会切断该GuestOS的电源,而不会影响其它GuestOS。
在HVM技术下，能够运行在DomU上的OS包括： 所有支持X86架构的OS.
<3> PV on HVM: I/O设备半虚拟化运行，CPU运行于HVM模式
此中方式是为了解决HVM方式中IO设备也必须完全模拟而带来的性能低下问题；通过让CPU进行
完全虚拟化，而I/O设备则采用在GuestOS中安装相应的IO驱动实现IO的半虚拟化的方式来提高效率。
在PV on HVM的技术下，能够运行在DomU上的OS包括：
只要OS能驱动PV接口类型的IO设备,即可.
1.2 Xen对VM的称呼:
Xen对VM统称为Domain.
第一台特权VM,在Xen中通常称为: Domain0,简称为Dom0, 别名: Privileged Domain.
其它后续用户级VM,在Xen中称为: Domain1,Domain2,...., 它们有一个统称为DomU,别名:Unprivileged Domain.
1.3 Xen对CPU和内存的虚拟化过程：
Xen在给VM提供CPU的虚拟化时,它采用的也是在Xen hypervisor层启动一个线程,并将这些线程映射到某个物理核心上,当然通过DomU的配置文件中的cpus可以指定将这些模拟CPU的线程绑定到某几个物理核心上；而内存的虚拟化则是内存页的映射,将物理内存上多个连续或不连续的内存页映射给VM,让VM看来这就是一个完整的连续的内存空间.
1.4 Xen对IO设备的虚拟化过程：
当启动一个用户VM(DomU)时, 该VM所需的CPU和内存都有Xen Hypervisor提供,而它若需要使用IO设备时,则向特权VM发起请求,特权VM(Dom0)会为该用户VM创建一个模拟的硬件设备线程,并运行于特权VM的用户空间,当用户VM向该IO硬件发起调用时,特权VM上相应的模拟设备接收请求并将其转化为特权VM对IO硬件的操作,交给特权VM的内核来代为完成其操作。这里需注意这些虚拟IO硬件需要由Qemu来模拟,Xen本身并没有提供相应的模拟功能。(注：特权VM的CPU和内存也是有Xen Hypervisor提供.)
Qemu模拟IO设备(完全虚拟化方式): 假如用户VM向特权VM请求磁盘,特权VM可以将一个分区、文件等,通过Qemu将其模拟成一个磁盘设备,就拿文件来说,特权VM先创建一个映像文件,再通过Qemu为该文件模拟一个磁盘控制器芯片,然后,将其映射到用户VM上,当然模拟的这个磁盘控制器芯片一定是一个最常见的,用户VM的Kernel一定支持的,但需注意: 模拟的磁盘可能会与实际的物理磁盘不同,因为要尽可能兼容。这样一来用户VM假如要写数据到磁盘的过程如下：
用户VM-APP--->用户VM-Kernel调用虚拟磁盘的驱动进行写数据前的准备(如:数据写入到磁盘中的扇区位置/数据编码等)--->
用户VM-Kernel将编码后的信息发给特权VM的模拟磁盘进程--->
特权VM的模拟磁盘进程再将编号信息还原后发给特权VM-kernel--->
特权VM-kernel调用真实物理磁盘的驱动对数据进行写前准备--->最后磁盘驱动调度磁盘完成写入.
摘录补充:（http://my.oschina.net/davehe/blog/94039?fromerr=mOuCyx6W）
Xen向Domain提供了一个抽象层，其中包含了管理和虚拟硬件的API。Domain 0内部包含了真实的设备驱动（原生设备驱动），可直接访问物理硬件，Xen 提供的管理 API 可与其交互，并通过用户模式下的管理工具(如：xm/xend、xl等)来管理 Xen 的虚拟机环境。
半虚拟化的IO设备：它与模拟最大不同是DomU知道自己是运行在虚拟化环境中的,并且知道这个磁盘不是真正的磁盘它只是Xen模拟的一个磁盘前端驱动(Disk Frontend),它要写数据时，直接将数据交给Disk Frontend,而不再去调用磁盘驱动进行数据编码,当特权VM端的Disk backend收到来自DomU的数据时,也是直接转给特权VM-Kernel,由其直接调用物理磁盘驱动来对这些原始数据进行处理并写入磁盘。
摘录补充：
Xen2.0之后，引入了分离设备驱动模式。该模式在每个用户域中建立前端（front end）设备，在特权域(Dom0)中建立后端(back end)设备。所有的用户域操作系统像使用普通设备一样向前端设备发送请求，而前端设备通过IO请求描述符(IO descripror ring)和设备通道（device channel）将这些请求以及用户域的身份信息发送到处于特权域中的后端设备。这种体系将控制信息传递和数据传递分开处理。
半虚拟化客户机（Domain U PV）的PV Block Driver接收到要向本地磁盘写入数据的请求，然后通过Xen Hypervisor将自己与Domain 0共享的本地内存中的数据写入到本地磁盘中。在Domain 0 和半虚拟化Domain U之间存在事件通道(我的理解:Device Channel包含Event Channel)，这个通道允许它们之间通过存在于Xen Hypervisor内的异步中断来进行通信。Domain 0将会接收到一个来自于Xen Hypervisor的系统中断，并触发Domain 0中的Block Backend驱动程序去访问本地系统内容，并从自己与半虚拟化客户机的共享内存中读取适合的数据块后，随即被写入到本地磁盘的指定位置中。
但无论采用模拟或半虚拟化最终都是对物理磁盘的操作,假如当前只有一个物理磁盘,众多用户VM都在进行大量的读写请求,此时,为了避免用户VM无限制的向特权VM发起请求,特权VM中采用一个环状缓存区,每到一个IO请求,就先将其塞入这个环状缓冲区的槽位中,若缓冲区满了,就会告诉用户VM IO设备繁忙。当然其它各种IO设备大致都采用这种机制来控制。
1.5 Linux Kernel对Xen的支持:
》Linux2.6.37 : kernel开始对Xen进行支持,并加其加入到Kernel中。
》Linux3.0 ：Kernel开始对Xen的关键部分进行优化.
RHEL对Xen的支持概况:
Redhat系列对Xen的支持情况:
RHEL5.7 ~ 及以前版本: 默认的企业虚拟化技术为Xen.
但Redhat提供了两种内核:
kernel-... :这是仅允许RHEL系统的内核，不能运行在DomU中。
kernel-xen.. :这是需要部署XenServer时,使用的Kernel版本.
RHEL6 ~ 及以后版本: 默认支持KVM(收购自以色列的一款虚拟化工具),并且不在对Xen做任何支持，但允许自己运行在DomU中.
1.6 Xen版本发布简史:
10年4月Xen4.0.0发布,改进后Xen的DomU最大可支持虚拟CPU 64颗,Xen主机可支持1TB内存和128颗物理CPU,磁盘可支持快照和克隆; HVM客户机支持虚拟内存页共享;
11年4月发布的Xen4.1版后,xm/xend开始被提示废弃,xl这个更轻量级的Xen VM管理工具逐渐成为主流.
15年为止已经发布Xen4.5版本.目前yum源可用的最新版Xen是4.6.1版的(http://mirrors.skyshe.cn/centos/6.7/virt/x86_64/xen-46/).
1.7 Xen的工具栈：
xend : 这是Xen Hypervisor的Dom0上运行的服务,此服务用来监控xm命令发来的指令,并完成相应的动作。
xm : Xen Management,用来管理VM的创建、删除、启动、快照、删除、停止等的管理工具。
xl : 这是一个基于libxenlight库的一个轻量级VM管理工具，它从Xen4.1开始出现,从4.3以后,它被作为主要的VM管理工具,而xm这个重量级管理工具开始被提示废弃.以下为xm、xl的对比图:
xl 和 xm都需要调用libxenlight，但xl不需要运行任何服务,它可直接调用libxenlight完成相关操作。
xe/XAPI，是xend的一个API管理接口,通常用于Xen Cloud环境中：Xen Server, XCP
virsh/ libvirt : 这是Redhat发起开发的一套用于管理众多不同类别的VM的管理工具。
virsh : 这是一个命令行工具
libvirt: 则是一个lib库, libvirtd守护进程用于监听virsh命令操作,并调用lbvirt完成相关操作.
1.8 XenStore:
为各Domain之间提供共享信息存储的空间,同时它也是一个有着层级结构的名称空间数据库；它运行于Dom0上,由Dom0直接管理,它支持事务和原子操作。XenStore通常用来控制DomU中设备的机制,并通过多种方式对其进行访问。
摘录补充(http://blog.chinaunix.net/uid-26299858-id-3134495.html)：
XenStore是Xen提供的一个域间共享的存储系统，它以字符串形式存放了管理程序和前、后端驱动程序的配置信息。Dom0管理所有的数据，而DomU通过共享内存，向Dom0请求与自己相关的键值，以此实现域间通信。Xen提供了多种接口用来操作XenStore：命令行的xenstore-*命令、用户空间的xs_系列函数、内核的XenBus接口，都可以用来方便地操作XenStore的数据。
1.9 虚拟化中的四种网络模型
在虚拟化环境中虚拟网络是十分重要但又比较难,需要特别注意;
在Linux中实现虚拟网络的方法中比较常用的工具有两个：bridge-utils 和 openvswitch，它们创建的虚拟网络设备是不能相互使用的，比如：bridge-utils创建的桥设备，openvswitch是无法识别的。
用下图来做简单说明
1.10 Xen的安全问题导读
补充见附件：
2. Xen的安装及配置文件说明
2.1.1 在CentOS6.6上运行Xen的条件:
方式一:
(1) 编译3.0以上版本的内核,启动对Dom0的支持.
(2) 编译xen程序
方式二：
使用相关Xen运行环境快速部署的项目：
(1) xen4contos : 这是Xen官方提供的开源项目。
xen环境部署的RPM包镜像站: http://mirrors.aliyun.com/centos/6.7/xen4/x86_64/
(2) xen made easy
2.1.2 Xen的配置：
(1) 修改grub.conf
# Xen是直接运行于硬件层之上的,因此必须修改grub.conf,手动添加以下参数:
title Xen Server Linux 3.7.4
root (hd0,0)
kernel /xen.gz dom0_mem=1024M cpufreq=xen dom0_max_vcpus=2 dom0_vcpus_pin
module /vmlinuz-3.7.4-1.el6xen.x86_64 ro root=/dev/mapper/vg0-root rd_NO_LUNKS LANG=en_US.UTF-8
rd_LVM_LV=vg0/swap rd_NO_MDSYSFONT=latarcyrheb-sun16 crashkernel=auto rd_NO_DM
KEYBOARDTYPE=pc KEYTABLE=us rd_LVM_LV=vg0/root rhgb quiet
module /initramfs-3.7.4-1.el6xen.x86_64.img
注: kernel 必须指定xen*.gz为启动的内核, dom0_mem:设定Dom0启动后可以使用的内存大小,
cpufreq: 设定由Xen来管理CPU, dom0_max_vcpus: 设定Dom0可以使用多少颗CPU,
dom0_vcpus_pin: 将Dom0固定在系统启动后,分配给它的CPU上,以避免它去抢占其它物理CPU核心,这样其它物理核心就可以分配给DomU来使用了。
详细参数查看:
http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html
2.2.1 Xen 启动DomU的配置文件说明
xl list : #首先需要了解的第一个命令.
xen VM的常见状态:
r : running
b: block(阻塞)
p: pause(暂停)： 类似与睡眠.
s: stop
c: crash(崩溃)
d: dying， 正在关闭的过程中.
2.2.1.1 如何创建一个Xen PV模式的VM:
1. Kernel 和 initrd或initramfs ：这些LinuxKernel文件必须要有,但可以不在DomU上,它们可以在Dom0上.
2. DomU内核模块(即:/lib/modules/`uname -r`): 这些就需要在DomU根文件系统中存储了。
3. 根文件系统
4. swap设备: 若条件充足也可以提供.
以上四步的内容必须定义在DomU的配置文件中.
注: xl 和 xm启动DomU的配置文件是存在一些不同的.
对于xl命令创建VM所需的配置文件说明可查看:
man xl.cfg
# 注: man xl.conf #这是对xl命令所使用的配置文件.
xl.cfg的配置文件参数说明：
name : 域的唯一名.
builder: 指明VM的类型,generic：创建PV类型的VM; HVM：创建HVM类型的VM
vcpus： 指定CPU个数.
maxvcpus：指定最大可使用CPU的个数,这些CPU可在需要是手动启动。
cpus: 指定VM的vcpu线程可以运行在哪些物理核心列表上.
#如：cpus="0-3,5,^1" 这表示:VCPU可运行在0,2,3,5上,但不能运行在1上.
#建议将vCPU绑定到固定的物理核心上,这样可减少vCPU线程在多个物理核心上切换.
memory: 指定DomU启动时预分配的内存大小[单位:M]
maxmem: 指定最大给DomU分配的内存大小. [单位:M]
on_poweroff: 指定DomU关机时,实际采用的动作.
destroy: 直接将DomU断电关机.
restart: 重启
rename-restart: 改名后重启
preserve: 将这个DomU保存,以便下次再启动。
coredump-destroy: 将DomU的运行中的内核数据备份出来后,再关机。
coredump-restart: 先备份内核数据，再重启.
on_reboot: 重启DomU时实际采用的动作。
on_crash: 当DomU崩溃后，实际采用的动作。
uuid: DomU的UUID,非必须.
disk:指定DomU的磁盘列表
如: disk=[ "/img/disk/DomU1.img" , "/dev/sda3" , ...]
vif : 指定DomU的网卡列表
如: vif=[ "NET_SPEC_STRING" , "NET_SPEC_STRING" , ...]
vfb: 指定DomU的显示器, vfb:virtual frame buffer(虚拟帧缓冲)
如: vfb=[ "VFB_SPEC_STRING" , "VFB_SPEC_STRING" ,...]
pci :指定DomU的PCI设备列表.
如:pci=[ "PCI_SPEC_STRING" , "PCI_SPEC_STRING" ,...]
PV模型的专用指令:
kernel : 指定内核文件路径,此路径为Dom0的路径.
ramdisk: 指定initrd或initramfs文件的路径.
root: 指定根文件系统. 此参数仅与kernel和ramdisk一起使用,因为,kernel和ramdisk都是在
Dom0上的,并没有grub.conf来告诉kernel根文件系统在哪里，因此这里需要指定。
extra: 与root参数类似,它是指定kernel启动时的其它参数的.
# 以上4个参数用于kernel文件在Dom0上, 下面固定格式用于DomU有自身的Kernel文件.
bootloader="pygrub": 若DomU使用自己的kernel和ramdisk，则此时需要一个Dom0中的
应用程序来实现其bootloader功能。这个不用指定root,因为,DomU的启动所需的
所有文件都在自己的镜像文件中,它可以从grub.conf中指定根文件系统的位置.
注：
# 让DomU通过网络之间安装操作系统,需要注意:
# kernel 和 ramdisk所需要的文件必须是：安装光盘目录下/isolinux/{vmlinuz,initrd.img}
kernel="/images/kernel/vmlinuz"
ramdisk="/images/kernel/initrd.img"
extra="ks=http://1.1.1.1/centos6.6_x86_64.ks" #注:给内核传递的ks文件。
另注:
cloud-init*.rpm工具包可以将安装的OS中的特有信息(如:MAC, 磁盘信息等)删除,并且可以在下次启动时，
自动生成这些信息.是制作云模板OS镜像的工具。
磁盘参数的指定方式：
xl方式创建VM时,磁盘指定格式: http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt
[<target>, [<format>,[<vdev>,[<access>]]]]
target: 表示磁盘映像文件或设备文件路径:
如: /images/xen/linux.img
/dev/vg-xen/lv-linux
format: 表示磁盘的格式:
如: raw、qcow2..等,具体格式可查看: qemu-img --help |grep 'Supported formats'
vdev: 指定添加的虚拟磁盘被DomU识别为何种类型的磁盘; 支持:hd, sd, xvd(xen-vritual-disk)
注: 指定是需要写成: sda 或 sdb等,即要指定这是第几块磁盘.
access: 访问权限,除CDROM为'r'只读外，其它都为'rw'
示例:
disk=["/images/xen/linux.img,qcow2,xvda,rw", "/iso/CentOS6.7.iso,,hdc,devtype=cdrom"]
# 使用Dom0中物理磁盘分区做为DomU的存储空间
disk=['/dev/vg-data/lv-bbox,raw,xvda,rw']
创建虚拟磁盘文件:
#注qemu-img创建的磁盘映像文件是采用稀疏磁盘格式创建的.因此用:du -sh linux.img 可看到其大小为0.
qemu-img create -f raw -o size=2G /images/xen/linux.img
创建虚拟网络接口:
#虚拟网卡的创建直接在配置文件中使用vif指定即可。
#格式: vif=[ "NET_SPEC_STRING" , "NET_SPEC_STRING" , ...]
NET_SPEC_STRING:的格式如下：
key=value
#key包含以下几个:
》mac :指定网卡的MAC地址,注:MAC地址必须以:00:16:3e 开头,这是IANA分配给Xen的MAC厂商前缀.
》bridge: 指定此网卡要桥接到Dom0上的那个桥设备上.
》model: 指定模拟网卡的芯片类型:[rtl8139 |e1000]
》vifname:指定在Dom0中显示的接口名, 注: 在DomU中显示还是eth0...
》script: DomU在创建网络接口时,预先执行的脚本.注: 此脚本的路径也是Dom0上的路径.
》ip：指定要注入DomU中的IP地址。
》rate: 指定网卡的设备速率.
如: rate=10Mb/s
rate=1MB/s@20ms #20毫秒内只能传输1M/0.02s=20000字节/20ms
图形窗口的启用:
可直接修改DomU的启动配置文件,并在其中添加:
(1) vfb=['sdl=1'] #这是直接在本地启动一个VNC窗口来输出DomU的图形桌面,且只能本地连接.
(2)Dom0上启动一个VNC进程,并监听在5900端口上,可通过密码连接.
vfb=['vnc=1,vnclisten=0.0.0.0,vncpasswd=123456,vncunused=1,vncdisplay=:1']
#注: vncunused: 为非0值,则表示vncserver监听在大于5900的第一个没被占用的端口上.
# vncdisplay: VNC显示号,默认为当前域的ID,当前域的VNC服务器将监听在5900+此显示号的端口上.
vfb=[ 'sdl=1,xauthority=/home/bozo/.Xauthority,display=:1' ]
#注:xauthority:表示认证密码文件。
# display:
3. 使用libvirt实现Xen虚拟机的图形管理
#需要安装的包
yum install libvirt libvirt-deamon-xen virt-manager python-virtinst libvirt-client
注： virt-manager: 是图形管理VM的接口界面,类似与VMware，可创建、启动、停止等
python-virtinst: 此工具提供了virt-install命令行管理VM的接口.
libvirt-client: 提供了一个virsh命令来管理VM。
service libvirtd start #要使用libvirt工具集，此服务必须首先启动.
virsh dumpxml busybox #将busybox的信息输出为virsh的可用的xml配置文件,可修改此文件做模板来创建新VM实例.
4. PV DomU的根文件系统可以以多种不同的方式安置:
(1) 虚拟磁盘映像文件
(a)方便制作成通用模板
当用qemu-img创建好一个虚拟磁盘映像文件,并向其中安装好OS后,可以使用cloud-init这种工具对其进行修改,去除其中OS的唯一性的数据信息(如:MAC地址等),需要注意的是,磁盘映像文件实际上是由标准格式的并且在其上创建完文件系统后,就可以通过FS的API接口在不挂载的情况下对其中的文件进行修改.
(b)方便实现实时迁移
1. 将模板映像文件放置于FTP/NFS/Samba等共享存储上,且有多台Xen Hypervisor:
场景一: 需要快速创建一台VM.
假如当前业务中MySQL的从库读压力过大,需要扩容,此时就可以直接通过自行开发的脚本工具来判断
当前那个Xen Hypervisor更空闲,然后,直接下载从共享存储上下载一个模板磁盘映像,直接就可以启动起来.
并且这是配置好的从库模板,启动后它可以直接连接到主库等等.
场景二: 快速迁移
假如当前某台Xen Hypervisor的CPU、Memory或其他资源突然升高,此时,可直接将该Xen Hypervisor上
某些VM的内存数据导出到共享存储上,然后直接在另一台比较宽裕的Xen Hypervisor上，下载模板映像文
件并直接将该共享存储上导出的内存数据与模板映像文件关联,就可恢复到此Xen Hypervisor上实现快速迁移。
2.分布式文件系统上存储磁盘映像文件，且有多台Xen Hypervisor:
场景一: 故障快速恢复
假如当前Xen Hypervisor上运行了多台VM,但Xen Hypervisor所在物理机突然故障,这时,我们完全可以直接
将分布式存储系统上的磁盘映像文件直接让正常的Xen Hypervisor接管,已实现快速迁移.
场景二：快速迁移
如上面场景二类似,但此处我们无需在下模板磁盘映像文件,直接dump出运行中VM的内存数据到共享存储上
就可以直接在另一台Xen Hypervisor上启动起来。
(2) 使用Dom0上空闲的物理磁盘分区
(3) 使用Dom0上空闲的逻辑卷
(4) 使用iSCSI设备提供的块级别网络文件系统 或 分布式文件系统。
(5) 网络文件系统,如: NFS, Samba