xen
录：
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的根文件系统能够以多种不一样的方式安置php
1. Xen的简介
Xen是一个开源的可直接运行于硬件层之上的虚拟化软件,它可在传统虚拟技术极度不友好的X86架构上也有上佳的表现
它是英国剑桥大学开发的开源虚拟化软件,它的初衷是在一台物理机上运行上百台虚拟机;
Xen的设计十分精巧,它属于虚拟化type-I ,由于Xen实际是一个简化版的Hypervisor层;相对于Type-II类型的基于Host的
虚拟化(如:VMware Workstattion),其性能相对会较好;Xen仅对CPU和Memory直接接管，而其它IO硬件驱动则由其上运行的
第一个虚拟机来提供支持.这样作的缘由是: Xen没法为众多IO设备开发驱动,而硬件设备的开发商也不会专为Xen提供驱动,
所以Xen采用了这样一种特别的设计方式。html
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等平台，并正在向IA6四、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.
node
1.3 Xen对CPU和内存的虚拟化过程【注: 关于虚拟化中CPU和内存的虚拟化在附件加入了一些补充.】：
Xen在给VM提供CPU的虚拟化时,它采用的也是在Xen hypervisor层启动一个线程,并将这些线程映射到某个物理核心上,
固然经过DomU的配置文件中的cpus能够指定将这些模拟CPU的线程绑定到某几个物理核心上；而内存的虚拟化
则是内存页的映射,将物理内存上多个连续或不连续的内存页映射给VM,让VM看来这就是一个完整的连续的内存空间.python
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 的虚拟机环境。linux
半虚拟化的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中.shell
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的对比图:vim
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是没法识别的。
用下图来作简单说明
注：lo1: 为loopback接口,但实际测试时，发现loopback接口没法桥接到虚拟网桥上。
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.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 的子命令简介详见附件】
qemu-img create -f raw -o size=2G /images/xen/linux.img
或 qemu-img create -f raw /images/xen/linux.img 2G
若想知道当前指定的磁盘格式支持哪些额外参数:
qemu-img create -f qcow2 -o ? /images/xen/linux.img
size : 指定qcow2格式的虚拟磁盘大小。
backing_file: 指定其后端存储快照信息的映像文件位置.
backing_fmt: 指定后端映像文件的格式。
encryption: 是否对建立的映像文件加密
cluster_size: 指定qcow2格式的簇大小.
preallocation: 指定建立qcow2格式的磁盘映像文件时,须要预先作些什么:
> off : 什么也不作,建立一个空磁盘.
> metadata: 预先建立qcow2的元数据信息,建议设置.
> full: 直接填充成指定大小的磁盘文件,它包含了metadata.
建立虚拟网络接口:
#虚拟网卡的建立直接在配置文件中使用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+此显示号的端口上.
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
实验目录:
1. 环境说明
2. Xen的安装和配置
3. 未解决的问题
1.在DomU的配置中添加sdl=1，启动报错,改成vnc=1,正常.
2.配置文件中指定IP,但启动DomU后，IP并无自动配置上.
3.不能动态调整vCPU的个数.
4.以上问题如有高手知道，很是愿意交流。
4. 建立第一台Xen DomU
4.1 建立并启动DomU
4.2 基本功能测试
1. 测试启动DomU的图形窗口(仅本地可连的VNC(sdl=1) 和 可远程链接的VNC(vnc=1)).
2. 测试动态添加和移除磁盘
3. 测试动态添加和移除网卡
4. 测试挂起DomU(即:将DomU的内存数据导出到文件.)
5. 测试恢复DomU.
6. 测试动态增长内存和CPU
7. 测试建立克隆DomU.
1) 相似VMware中的链接克隆
2) 直接复制HVM DomU的img映像文件来克隆DomU.
8. 测试迁移DomU
9. Xen的提供的批量操做DomU的脚本简单分析: xendomains
10. xenstore的简单操做说明.
以上测试因本人对Xen的理解实在有限,不能更深刻测试,如下测试仅本人亲自测试所做,如有错误或遗漏,还望多多指出,仅作抛砖引玉。
测试环境:
Dom0：CentOS 6.7（Kernel:2.6.32）
Xen安装源: http://mirrors.aliyun.com/centos/6.7/xen4/x86_64/
Xen环境:
Kernel： 3.18.21-16.el6.x86_64
Xen： xen-4.4.3-3.el6.gz
Xen的安装:
|
1
2
3
4
5
6
7
|
# 配置yum源:
[root@centos6 ~]
# cat /etc/yum.repos.d/xen.repo
[Aliyun]
name=aliyun-xen-mirrors
baseurl=http:
//mirrors
.aliyun.com
/centos/6
.7
/xen4/x86_64/
enabled=1
gpgcheck=0
|
|
1
2
|
# 安装Xen
[root@centos6 ~]
# yum install xen
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
# 配置启动Xen:
[root@centos6 ~]
# cat /boot/grub/grub.conf
default=0
timeout=5
splashimage=(hd0,0)
/grub/splash
.xpm.gz
hiddenmenu
title Xen-Dom0-CentOS (3.18.21-16.el6.x86_64)
root (hd0,0)
kernel
/xen
.gz dom0_mem=1024M cpufreq=xen dom0_max_vcpus=2 dom0_vcpus_pin
module
/vmlinuz-3
.18.21-16.el6.x86_64 ro root=UUID=11753f30-71af-4c50-8f64-32ddbed68711
nomodeset rd_NO_LUKS KEYBOARDTYPE=pc KEYTABLE=us.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16
crashkernel=auto rd_NO_LVM rd_NO_DM rhgb quiet
module
/initramfs-3
.18.21-16.el6.x86_64.img
title CentOS 6 (2.6.32-573.el6.x86_64)
root (hd0,0)
kernel
/vmlinuz-2
.6.32-573.el6.x86_64 ro root=UUID=11753f30-71af-4c50-8f64-32ddbed68711 nomodeset
rd_NO_LUKS KEYBOARDTYPE=pc KEYTABLE=us.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto
rd_NO_LVM rd_NO_DM rhgb quiet
initrd
/initramfs-2
.6.32-573.el6.x86_64.img
|
建立一台cirros虚拟机:
(1) 下载Cirros: http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
(2) 建立image存储目录
|
1
2
|
[root@centos6 ~]
# mkdir -pv /images/xen/
[root@centos6 ~]
# cp cirros-0.3.4-x86_64-disk.img /images/xen/cirros.img
|
(3) 建立Xen DomU的启动配置文件:
|
1
2
3
4
5
6
7
8
9
10
|
[root@centos6 ~]
# cd /etc/xen
[root@centos6 ~]
# cp xlexample.pvlinux cirros
# 修改cirros后配置以下:
[root@centos6 ~]
# grep -Ev '^$|^#' cirros
name =
"cirros-001"
bootloader=
"pygrub"
memory = 512
vcpus = 2
vif = [
'bridge=xenbr0'
]
disk = [
'/images/xen/cirros.img,qcow2,xvda,rw'
]
|
(4) 建立桥接口
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
#注: 在建立桥接口前，须要先注意禁止NetworkManager服务启动.
# service NetworkManager stop && chkconfig NetworkManager off
#桥接口的做用:
# DomU启动后,它若须要与Dom0或外网通讯就须要经过Dom0来实现,而Dom0实现的方式就是
# 建立桥接口,桥接后,系统会将Dom0的物理网卡模拟成一个二层交换机,而后,建立一个虚接口代替
# ethX, 这样当物理网卡收到目的MAC是本身的数据包时,就转发到虚接口上.若不是则转发给后端DomU.
[root@centos6 ~]
# cat ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
ONBOOT=
yes
NM_CONTROLLED=no
BOOTPROTO=none
BRIDGE=xenbr0
USERCTL=no
[root@centos6 ~]
# cat ifcfg-xenbr0
DEVICE=xenbr0
TYPE=Bridge
ONBOOT=
yes
NM_CONTROLLED=no
BOOTPROTO=none
IPADDR=192.168.137.132
NETMASK=255.255.255.0
GATEWAY=192.168.137.1
DNS1=114.114.114.114
USERCTL=no
DELAY=0
|
(5) 测试启动
|
1
2
3
4
5
6
7
|
# 注：测试启动后,请注意网卡的MAC地址. 因为上面配置文件中没有指定MAC地址,所以每次启动后,
# 其MAC地址会被Xen自动从新分配.
# -c : 启动的同时进入控制台.
# -n : 检查配置文件,非真正启动.
[root@centos6 ~]
# xl create cirros -c #启动并登陆DomU的终端后,若要退回的Dom0,按: Ctrl+],
# 若退回到Dom0后, Xshell 等链接工具不能正常显示:可输入reset来重置.
[root@centos6 ~]
# xl console cirros-001 #手动登陆cirros的控制台
|
基本命令使用说明
|
1
2
3
4
5
6
7
8
9
|
xl help create
#查看建立DomU的帮助
xl -
v
create
/etc/xen/cirros
-n
#测试配置文件是否符合需求.
xl create
/etc/xen/cirros
-c
#建立并启动成功后,马上链接到其控制台上.
xl -
v
create
/etc/xen/cirros
#启动cirros虚拟机
xl list
#查看当前运行的VM状况
xl console cirros-001
#链接到刚刚启动的cirros虚拟机的控制台.
ctrl + ]
#退回到Dom0.
exit
#拆除cirros,即销毁cirros.
xl destroy cirros-001
#关机并销毁cirros, 注:销毁后,下次再用配置文件启动DomU时,就是一个新的DomU了.
|
启动cirros虚拟机登陆后:
|
1
2
3
4
5
6
7
8
|
ifconfig
-a
#是看不到任何接口的.
insmod
/lib/modules/xen-netfront
.ko
#安装网卡接口驱动模块
ifconfig
-a
ifconfig
eth0 192.168.1.20 up
ctrl + ]
# 回到到Dom0,查看网络接口状态.
Dom0:
ifconfig
-a
#将能够看到一个新接口.vif#.@
# "#": 表示DomU的ID ； @:表示Dom0上建立的桥ID.
Dom0: brctl show
#将看到新接口已经被桥接到Dom0的桥设备上了。
|
xl的其它经常使用命令:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
xl
shutdown
DomU_Name
xl reboot DomU_Name
xl pause DomU_Name
#暂停DomU
xl unpause DomU_Name
xl save DomU_Name
/path/to/save_name
.img
/etc/xen/ConfigFile
#将DomU挂起。
xl restore
/etc/xen/ConfigFile
/path/to/save_name
.img
#恢复DomU到运行态，无需指定DomU_Name.
xl help
cd
-insert
#插入光驱,仅适用于HVM模式
xl help
cd
-
eject
#拔出光驱
xl vcpu-list DomU_Name
#显示DomU上有几颗真正使用的虚拟CPU.
#CPU Affinity：表示该虚拟CPU线程能够运行在哪些物理核心上.
xl vcpu-pin DomU_ID 0 3
#将DomU的0号VCPU绑定到物理核心3上.
xl vcpu-
set
DomU_Name 1
#设置DomU当前只能使用1颗VCPU.若当前它有多颗VCPU,则其它CPU将被暂停.
#注: 若在配置文件中指定了maxvcpus ,则此命令可动态添加VCPU数量.
# 不然只能在当前VCPU总数的基础上减小。
xl pci-list DomU_Name
#显示当前DomU上的PCI设备.
xl pci-attach DomU_Name
#给运行时的DomU添加一块PCI设备.
xl pci-detach DomU_Name
#将运行的DomU中的PCI设备直接移除。
xl info
#查看当前Xen Hypervisor的摘要描述信息
-- nr_cpus
#物理核心总数
-- max_cpu_id
#最大支持的VCPU个数
#更详细的信息参见：http://smilejay.com/2012/03/xl-info_xm-info/
xl demsg DomU_Name
#查看DomU启动时信息.
xl
top
#查看DomU的资源使用状况.
xl network-list DomU_Name
#查看DomU的网络接口列表
xl network-attach DomU_Name bridge=
"xenbr1"
#给运行中DomU添加一块虚拟网卡.
xl network-detach DomU_Name 1
#拆除网卡编号为1的网卡.
qemu-img create -f qcow2 -o size=3G,preallocation=metadata
/images/xen/busybox
.2.img
xl block-list DomU_Name
#查看当前DomU_Name的磁盘列表.
xl block-attach DomU_Name
'/images/xen/busybox.2.img,qcow2,xvdb,rw'
#给DomU添加一个磁盘设备.
xl block-detach DomU_Name DevID
#移除一块磁盘.block-list中Vdev项就是DevID.
xl uptime DomU_Name
#查看DomU的运行时长.
|
基本功能测试部分:
(6) 测试打开本地图形窗口:
|
1
2
3
4
5
6
7
8
9
10
11
|
[root@centos6 ~]
# echo "vfb='['sdl=1']'" >> /etc/xen/cirros #开启仅本机访问的VNC窗口.
# 测试失败,报一下错误:
# Parsing config from cirros
# libxl: notice: libxl_numa.c:494:libxl__get_numa_candidate: NUMA placement failed, performance might be affected
# libxl: error: libxl_dm.c:1401:device_model_spawn_outcome: domain 1 device model: spawn failed (rc=-3)
# libxl: error: libxl_create.c:1189:domcreate_devmodel_started: device model did not start: -3
# libxl: error: libxl_dm.c:1505:kill_device_model: Device Model already exited
# 测试使用VNC远程链接打开.
# 开启可远程链接的VNC服务.
[root@centos6 ~]
# echo "vfb=['vnc=1,vnclisten=0.0.0.0,vncpasswd=123456']" >> /etc/xen/cirros
|
(7) 测试动态添加和拆除磁盘
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
[root@centos6 ~]
# qemu-img create -f raw -o size=1G /images/xen/cirros-01.img
[root@centos6 ~]
# xl block-attach cirros-001 '/images/xen/cirros-01.img,raw,xvdb,rw'
[root@centos6 ~]
# xl console cirros-001
[root@centos6 ~]
# fdisk -l |grep 'Disk /dev'
Disk
/dev/xvda
: 41 MB, 41126400 bytes
Disk
/dev/xvdb
: 1073 MB, 1073741824 bytes
#能够看到已经添加成功.
[root@centos6 ~]
# xl block-list cirros-001
Vdev BE handle state evt-ch ring-ref BE-path
51728 0 2 4 17 793
/local/domain/0/backend/vbd/2/51728
#必定注意:新加的磁盘不必定是显示在末行.
51712 0 2 4 15 8
/local/domain/0/backend/qdisk/2/51712
[root@centos6 ~]
# xl block-detach cirros-001 51728 #拆除磁盘.
DEBUG libxl__device_destroy_tapdisk 105
type
=aio:
/images/xen/cirros-01
.img disk=:
/images/xen/cirros-01
.img
[root@centos6 ~]
# xl -v block-list cirros-001
Vdev BE handle state evt-ch ring-ref BE-path
51712 0 2 4 15 8
/local/domain/0/backend/qdisk/2/51712
|
(8) 测试动态添加网卡
|
1
2
3
4
5
6
7
|
[root@centos6 ~]
# xl network-attach cirros-001 #不加参数也能够添加虚拟网卡.
[root@centos6 ~]
# xl network-attach cirros-001 'ip=1.1.1.2,bridge=xenbr1' #添加参数，但IP参数没有生效.不知为什么？
[root@centos6 ~]
# xl network-list cirros-001
Idx BE Mac Addr. handle state evt-ch tx-
/rx-ring-ref
BE-path
0 0 00:16:3e:0e:ae:e1 0 4 16 775
/774
/local/domain/0/backend/vif/1/0
1 0 00:16:3e:68:3e:4f 1 4 17 1280
/1281
/local/domain/0/backend/vif/1/1
2 0 00:16:3e:77:0b:eb 2 4 18 1792
/1793
/local/domain/0/backend/vif/1/2
|
(9) 保存DomU当前的内存数据到指定位置.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
# 注:默认挂起后,会destroy DomU.
# -p : 保存当前时刻的内存状态后，将DomU暂停在内存中.
# -c : 保存当前时间的内存状态后, DomU继续运行.
[root@centos6 ~]
# xl save -p cirros-001 /tmp/cirros-04070526.img /etc/xen/cirros
Saving to
/tmp/cirros-04070526
.img new xl
format
(info 0x0
/0x0/1307
)
xc: Saving memory: iter 0 (last sent 0 skipped 0): 131072
/131072
100%
[root@centos6 ~]
# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1024 2 r----- 610.2
cirros-001 2 512 2 --p--- 1.5
[root@centos6 ~]
# xl console cirros-001
[10489.060379] Freezing user space processes ... (elapsed 0.01 seconds)
done
.
[root@centos6 ~]
# xl save -c cirros-001 /tmp/cirros-04070538.img /etc/xen/cirros
Saving to
/tmp/cirros-04070538
.img new xl
format
(info 0x0
/0x0/1307
)
xc: Saving memory: iter 0 (last sent 0 skipped 0): 131072
/131072
100%
[root@centos6 ~]
# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1024 2 r----- 682.5
cirros-001 2 512 2 -b---- 2.1
|
(10) 恢复保存的DomU状态
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
[root@centos6 ~]
# xl restore /etc/xen/cirros /tmp/cirros-04070538.img
Loading new save
file
/tmp/cirros-04070538
.img (new xl
fmt
info 0x0
/0x0/1307
)
Savefile contains xl domain config
Parsing config from
/etc/xen/cirros
libxl: notice: libxl_numa.c:494:libxl__get_numa_candidate: NUMA placement failed, performance might be affected
xc: Reloading memory pages: 131072
/131072
100%
# 注: 在保存内存数据前,我事先为cirros添加了一块磁盘 和 一块网卡.
# 请注意: 恢复DomU后，动态关联的网卡和磁盘都已经被去除了。
[root@centos6 ~]
# xl network-list cirros-001
Idx BE Mac Addr. handle state evt-ch tx-
/rx-ring-ref
BE-path
0 0 00:16:3e:48:55:6d 0 4 16 775
/774
/local/domain/0/backend/vif/5/0
[root@centos6 ~]
# xl block-list cirros-001
Vdev BE handle state evt-ch ring-ref BE-path
51712 0 5 4 15 8
/local/domain/0/backend/qdisk/5/51712
|
(11) 测试动态增长内存和CPU：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
[root@centos6 xen]
# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1024 2 r----- 932.5
cirros-001 6 512 1 -b---- 4.3
busybox-001 7 256 1 -b---- 10.0
[root@centos6 xen]
# grep -Ev '^$|^#' cirros
name =
"cirros-001"
bootloader=
"pygrub"
memory = 512
maxmem = 1024
vcpus = 1
maxvcpus = 3
cpus =
"0-2"
#将CPU绑定到0,1,2这三颗物理核心上.
vif = [
'ip=10.1.0.10,bridge=xenbr0'
]
# IP参数设置后,测试发现老是不生效,不知缘由为什么？
disk = [
'/images/xen/cirros.img,qcow2,xvda,rw'
]
vfb = [
'vnc=1,vncpasswd=123456,vnclisten=0.0.0.0'
]
[root@centos6 xen]
# grep -Ev '^$|^#' busybox
name =
"busybox-001"
kernel =
"/boot/vmlinuz"
ramdisk =
"/boot/initramfs.img"
extra =
"selinux=0 init=/bin/sh "
root =
"/dev/xvda ro"
memory = 256
vcpus = 1
vif = [
'ip=10.1.0.11,bridge=xenbr1'
]
disk = [
'/images/xen/busybox.img,raw,xvda,rw'
]
[root@centos6 xen]
# xl mem-set cirros-001 600m
[root@centos6 xen]
# xl mem-set busybox-001 300m
libxl: error: libxl.c:4106:libxl_set_memory_target: memory_dynamic_max must be
less
than or equal to memory_static_max
[root@centos6 xen]
# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1024 2 r----- 945.7
busybox-001 7 256 1 -b---- 10.2
cirros-001 8 600 1 -b---- 2.8
# 上面测试结果显示: 必须在配置文件中启动最大内存(maxmem)参数,才能使用命令来动态调整Memory.
# 可否使用mem-max动态增长最大内存那？
[root@centos6 xen]
# xl mem-max busybox-001 512m
[root@centos6 xen]
# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1024 2 r----- 947.4
busybox-001 7 256 1 -b---- 10.2
cirros-001 8 600 1 -b---- 2.9
[root@centos6 xen]
# xl mem-set busybox-001 300m
libxl: error: libxl.c:4106:libxl_set_memory_target: memory_dynamic_max must be
less
than or equal to memory_static_max
[root@centos6 xen]
# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1024 2 r----- 947.7
busybox-001 7 256 1 -b---- 10.2
#测试结果: 必须修改配置文件.
cirros-001 8 600 1 -b---- 2.9
[root@centos6 xen]
# xl vcpu-set cirros-001 3
[root@centos6 xen]
# xl vcpu-list cirros-001
Name ID VCPU CPU State Time(s) CPU Affinity
cirros-001 8 0 0 -b- 2.7 all
#注: 动态调整VCPU个数后,并无动态激活更多的VCPU.
cirros-001 8 1 - --p 0.1 all
# 问题缘由,目前还不清楚...
cirros-001 8 2 - --p 0.1 all
# 在DomU中查看 cat /proc/cpuinfo,也只有一颗.
|
(12) 测试建立克隆DomU.
1) 相似VMware中的链接克隆.
|
1
2
3
4
5
|
#注: 经过qemu-img来建立一个关联后端文件的img镜像文件.
# 来测试链接克隆,但测试结果是失败的。
# 尝试发现: 将链接镜像文件作为磁盘启动后,再里面所作的修改,在关机后会同步到后端镜像文件中。
# 另注: 我的认为链接克隆不适合线上操做, 仅我的使用时节省空间是比较好的选择。所以,可没必要深究.
qemu-img create -f qcow2 -o backing_file=
/images/xen/cirros
.img
/images/xen/cirros
.link.img
|
2) 直接复制HVM DomU的img映像文件来克隆DomU.
# Linux测试没有发现太多异常,除了MAC会在每次create时从新生成外,相互访问正常,水平有限,望高手勿喷。
# Windows的测试,此处采用WinXP来测试,WinXP仅支持HVM模式(彻底虚拟化)下测试.
(a) 个人CPU支持VT-x,所以在VMware中开启了VT-x输出给VM的功能:
(b) 提供WinXP的基本配置文件
|
1
2
3
4
5
6
7
8
|
[root@centos6 xen]
# grep -Ev '^$|^#' winxp
builder =
"hvm"
name =
"WinXP-001"
memory = 1024
vcpus = 2
vif = [
'bridge=xenbr0'
]
disk = [
'/images/xen/winxp.img,qcow2,xvda,rw'
,
'/mnt/win7/windows/WinXPSP3-Vol.iso,,hdc,cdrom'
]
vnc = 1
|
(c)启动WinXP后,链接VNC开始从CDROM安装WinXP.
|
1
2
|
#注:个人笔记本内存只有8G,分配给Xen VM 4G,但安装WinXP依然巨慢,安装了一个晚上才基本装好.
vncviewer 127.0.0.1:5900
|
(d)克隆WinXP的映像文件
|
1
|
cp
-a
/images/xen/winxp
.img
/images/xen/winxp-2
.img
|
(e)测试结果:
> WinXP能够启动,MAC地址能够在配置文件中指定来保障其不是每次重启后都改变.
> 但查询Windows的SID时, 直接复制的映像文件与原有的映像文件的SID是相同的.
这也是应该是必然,Xen还不太可能每次create时去修改Windows的SID.
注:
Windows查看当前用户的SID:
开始–>运行–>regedit–>HKEY_USERS 下面两个就是当前用户的SID.
如: S-1-5-21-861567501-1326574676-682003330-1003
Windows SID的重要性: http://www.cnblogs.com/mq0036/p/3518542.html
SID = Security Identifiers，安全标识符，是标识用户、组和计算机账户的惟一的号码。
若是两台电脑的SID相同，在一个局域网里就会发生冲突，好比本身GHOST了系统，而后还原到其它电脑上，
这时候的SID是相同的，就会产生冲突。另外A和B两台PC机的管理员SID相同,则A上仅管理员可访问的共享,
B上的管理员也将可访问,固然A也能访问B.
(13) Xen的实时迁移
|
1
2
3
4
5
6
7
8
9
10
11
|
# xl 命令作迁移比较简单,直接使用如下命令便可实现:
# -C : 指定DomU的配置文件,非必须.
# 192.168.137.151: 目标Xen Hypervisor的IP.
# 注: 迁移的条件:
# (1) busybox-001的磁盘映像文件，在目标Xen Hypervisor上必须能访问到.
# (2) 两边的/etc/hosts文件最好一致.由于,xl 的迁移其实是采用ssh隧道来完成的.
# 另注: 因为测试时,启动两台Xen Hypervisor后,老是会致使其中一台在不肯定的时间挂掉.
# 致使没能作的太详细,我在迁移时,先是将busybox-001的磁盘映像文件拷贝到目标机上后,
# 在执行如下命令就成功了。但要注意目录必须与busybox配置文件中一致.
# 固然,最好是先用iSCSI或NFS，Samba等将磁盘映像文件共享,在作如下操做会更真实.
xl migrate -C
/etc/xen/busybox
busybox-001 192.168.137.151
|
(14) 关于Xen提供的批量启动、中止或迁移DomU的脚本—-xendomains的分析说明:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
|
#注: 此脚本存在一个小Bug,须要小小的修改下.
# 下面分析仅仅对start 和 stop函数作简略说明，其它部分可自行参看: /etc/init.d/xendomains
# xendomains: 会读取/etc/sysconfig/xendomains这个默认参数配置文件.
parseln()
{
if
[[
"$1"
=~
'(domain'
]] || [[
"$1"
=
"{"
]];
then
name=;
id
=
elif
[[
"$1"
=~
'(name'
]];
then
name=$(
echo
$1 |
sed
-e
's/^.*(name \(.*\))$/\1/'
)
elif
[[
"$1"
=~
'(domid'
]];
then
id
=$(
echo
$1 |
sed
-e
's/^.*(domid \(.*\))$/\1/'
)
elif
[[
"$1"
=~
'"name":'
]];
then
name=$(
echo
$1 |
sed
-e
's/^.*"name": "\(.*\)",$/\1/'
)
elif
[[
"$1"
=~
'"domid":'
]];
then
id
=$(
echo
$1 |
sed
-e
's/^.*"domid": \(.*\),$/\1/'
)
fi
# 此处即上上面所说的小Bug:
#此处是手动添加的,由于,parseln函数是用来统一获取DomU的name、id的,
#但从脚本中看,做者是但愿从这里获取DomU的运行状态的,但彷佛忘记写了.
state=$(xl list |
awk
-
v
DomUname=$name
'$1==DomUname{print $5}'
)
[ -n
"$name"
-a -n
"$id"
] &&
return
0 ||
return
1
}
stop()
{
exec
3>&2 2>
/dev/null
#此句是将当前进程的文件描述符 绑定到系统标准错误输出.
# Collect list of domains to shut down
if
test
"$XENDOMAINS_AUTO_ONLY"
=
"true"
;
then
rdnames;
fi
echo
-n
"Shutting down Xen domains:"
name=;
id
=
while
read
LN;
do
parseln
"$LN"
||
continue
if
test
$
id
= 0;
then
continue
;
fi
echo
-n
" $name"
# XENDOMAINS_AUTO=/etc/xen/auto/
# XENDOMAINS_AUTO_ONLY='true' 此为默认值.
# 自动关闭/etc/xen/auto/目录下全部的DomU. 此目录下放置DomU的配置文件.
# 但此处的并无真正实现自动关闭。
# NAMES: 是rdnames函数定义的变量.它保存了/etc/xen/auto中全部DomU的名字,
# NAMES="DomU1|DomU2|DomU3|...."
if
test
"$XENDOMAINS_AUTO_ONLY"
=
"true"
;
then
#这里本来是关闭:/etc/xen/auto/目录下全部打算自动启动的DomU.
#但stop函数中并无实际去关闭,而是留空了.
fi
# XENDOMAINS_SYSRQ chould be something like just "s"
# or "s e i u" or even "s e s i u o"
# for the latter, you should set XENDOMAINS_USLEEP to 1200000 or so
# /etc/sysconfig/xendomains中对XENDOMAINS_SYSRQ的注解:
# The xendomains script can send SysRq requests to domains on shutdown.
# If you don't want to MIGRATE, SAVE, or SHUTDOWN, this may be a possibility
# to do a quick and dirty shutdown ("s e i u o") or at least sync the disks
# of the domains ("s").
# SysRq:的含义我没有弄明白.如有知情着,还望赐教.
if
test
-n
"$XENDOMAINS_SYSRQ"
;
then
for
sysrq
in
$XENDOMAINS_SYSRQ;
do
echo
-n
"(SR-$sysrq)"
# CMD=/usr/sbin/xl
XMR=`$CMD sysrq $
id
$sysrq 2>&1 1>
/dev/null
`
if
test
$? -
ne
0;
then
echo
-e
"\nAn error occurred while doing sysrq on domain:\n$XMR\n"
rc_failed $?
echo
-n
'!'
fi
# usleep just ignores empty arg
usleep $XENDOMAINS_USLEEP
done
fi
# 这里是判断是否存在僵尸DomU, 须要注意: state变量并未定义,此多是个Bug.
# 可自行修复下,在parseln函数中添加"state=$($CMD list |awk -v DomUName=$name '$1==DomUName{print $5}')"
if
test
"$state"
=
"-b---d"
-o
"$state"
=
"-----d"
;
then
echo
-n
"(zomb)"
continue
fi
#这里是用来判断MigrateServer是否指定了,若指定了,则开始批量迁移DomU到指定的XenHypervisor.
#指定XENDOMAINS_MIGRATE,可直接修改/etc/sysconfig/xendomains。
if
test
-n
"$XENDOMAINS_MIGRATE"
;
then
echo
-n
"(migr)"
#启动一个监视迁移的线程.默认若在300秒内没有迁移完成,则监控线程将认为迁移超时,
#而强制kill掉迁移线程.
watchdog_xencmd migrate &
#获取监视迁移线程的PID,若在300秒内迁移完成,则kill掉监视迁移的线程.
WDOG_PID=$!
# CMD=/usr/sbin/xl
#启动DomU迁移.
XMR=`$CMD migrate $
id
$XENDOMAINS_MIGRATE 2>&1 1>
/dev/null
`
if
test
$? -
ne
0;
then
echo
-e
"\nAn error occurred while migrating domain:\n$XMR\n"
rc_failed $?
echo
-e
'!'
kill
$WDOG_PID >
/dev/null
2>&1
else
kill
$WDOG_PID >
/dev/null
2>&1
echo
-e .
usleep 1000
#若迁移被设置了,则全部即将被关闭的DomU都将被迁移到指定Xen Hypervisor上.
#下面的save 和 shutdown就不会被执行了。
continue
fi
fi
if
test
-n
"$XENDOMAINS_SAVE"
;
then
echo
-n
"(save)"
# 将Shell函数放到后台运行.
watchdog_xencmd save &
# 获取这个后台执行的函数线程的PID.
WDOG_PID=$!
# Default：XENDOMAINS_SAVE=/var/lib/xen/save
mkdir
-p
"$XENDOMAINS_SAVE"
# 这里开始对DomU进行挂起,挂起操做的默认超时时间是300秒,watchdog_xencmd负责监控下面命令执行是否超时.
# 若超时,watchdog_xencmd会将其自动强制结束.
XMR=`$CMD save $
id
$XENDOMAINS_SAVE/$name 2>&1 1>
/dev/null
`
# 若以上命令执行成功,则强制将watchdog_xencmd线程结束掉.
if
test
$? -
ne
0;
then
echo
-e
"\nAn error occurred while saving domain:\n$XMR\n"
rc_failed $?
echo
-e
'!'
kill
$WDOG_PID >
/dev/null
2>&1
else
kill
$WDOG_PID >
/dev/null
2>&1
echo
-e .
usleep 1000
continue
fi
fi
# XENDOMAINS_SHUTDOWN=--wait
if
test
-n
"$XENDOMAINS_SHUTDOWN"
;
then
# XENDOMAINS_SHUTDOWN should be "--wait"
echo
-n
"(shut)"
watchdog_xencmd
shutdown
&
WDOG_PID=$!
XMR=`$CMD
shutdown
$XENDOMAINS_SHUTDOWN $
id
2>&1 1>
/dev/null
`
if
test
$? -
ne
0;
then
echo
-e
"\nAn error occurred while shutting down domain:\n$XMR\n"
rc_failed $?
echo
-e
'!'
fi
kill
$WDOG_PID >
/dev/null
2>&1
fi
done
< <($CMD list -l |
grep
"$LIST_GREP"
)
# NB. this shuts down ALL Xen domains (politely), not just the ones in
# AUTODIR/*
# This is because it's easier to do "；-)" but arguably if this script is run
# on system shutdown then it's also the right thing to do.
# all_zombies返回0,表示没有找到僵尸DomU,返回1,表示找到僵尸DomU.
if
! all_zombies &&
test
-n
"$XENDOMAINS_SHUTDOWN_ALL"
;
then
# XENDOMAINS_SHUTDOWN_ALL="--all --wait"
echo
-n
" SHUTDOWN_ALL "
watchdog_xencmd
shutdown
1
false
&
WDOG_PID=$!
XMR=`$CMD
shutdown
$XENDOMAINS_SHUTDOWN_ALL 2>&1 1>
/dev/null
`
if
test
$? -
ne
0;
then
echo
-e
"\nAn error occurred while shutting down all domains: $XMR\n"
rc_failed $?
echo
-e
'!'
fi
kill
$WDOG_PID >
/dev/null
2>&1
fi
# Unconditionally delete lock file
rm
-f $LOCKFILE
}
start()
{
# LOCKFILE=/var/lock/subsys/xendomains
if
[ -f $LOCKFILE ];
then
echo
-e
"xendomains already running (lockfile exists)"
return
;
fi
saved_domains=
" "
# XENDOMAINS_RESTORE=true
# XENDOMAINS_SAVE=/var/lib/xen/save
# contains_something :检查指定目录下是否有文件,有则返回0,无则返回1
if
[
"$XENDOMAINS_RESTORE"
=
"true"
] &&
contains_something
"$XENDOMAINS_SAVE"
then
# $(dirname "$LOCKFILE") = /var/lock/subsys
mkdir
-p $(
dirname
"$LOCKFILE"
)
touch
$LOCKFILE
echo
-n
"Restoring Xen domains:"
saved_domains=`
ls
$XENDOMAINS_SAVE`
#这里是用来恢复全部调用stop函数被挂起(save)的DomU。
for
dom
in
$XENDOMAINS_SAVE/*;
do
if
[ -f $dom ] ;
then
HEADER=`
head
-c 16 $dom |
head
-n 1 2>
/dev/null
`
#HEADCOMP="LinuxGuestRecord" : 这是xm save DomU后,其保存文件中头部16个字符.
#HEADCOMP="Xen saved domain" : 这是xl save DomU后,其保存文件中头部16个字符.
if
[
"$HEADER"
=
"$HEADCOMP"
];
then
echo
-n
" ${dom##*/}"
# CMD=/usr/sbin/xl
XMR=`$CMD restore $dom 2>&1 1>
/dev/null
`
#$CMD restore $dom
if
[ $? -
ne
0 ];
then
echo
-e
"\nAn error occurred while restoring domain ${dom##*/}:\n$XMR"
rc_failed $?
echo
-e
'!'
else
# mv $dom ${dom%/*}/.${dom##*/}
# 若恢复成功则删除XENDOMAINS_SAVE中相应的DomU保存的镜像.
rm
$dom
fi
fi
fi
done
echo
-e
fi
# contains_something :检查指定目录下是否有文件,有则返回0,无则返回1
if
contains_something
"$XENDOMAINS_AUTO"
then
touch
$LOCKFILE
echo
-n
"Starting auto Xen domains:"
# We expect config scripts for auto starting domains to be in
# XENDOMAINS_AUTO - they could just be symlinks to files elsewhere
# Create all domains with config files in XENDOMAINS_AUTO.
# TODO: We should record which domain name belongs
# so we have the option to selectively shut down / migrate later
# If a domain statefile from $XENDOMAINS_SAVE matches a domain name
# in $XENDOMAINS_AUTO, do not try to start that domain; if it didn't
# restore correctly it requires administrative attention.
# XENDOMAINS_AUTO=/etc/xen/auto
# 这是自动列出/etc/xen/auto/下全部DomU的配置文件,并启动.
for
dom
in
$XENDOMAINS_AUTO/*;
do
# dom=/etc/xen/auto/busybox-001
# ${dom##*/} = busybox-001
echo
-n
" ${dom##*/}"
# $(echo $dom | sed -n 's/^.*\/\(.*\)$/\1/p') = busybox-001
shortdom=$(
echo
$dom |
sed
-n
's/^.*\/\(.*\)$/\1/p'
)
# grep -w :表示单词匹配模式
echo
$saved_domains |
grep
-w $shortdom >
/dev/null
#is_running:判断提供的DomU是否正在运行.0表示正在运行.
if
[ $? -
eq
0 ] || is_running $dom;
then
echo
-n
"(skip)"
else
XMC=`$CMD create --quiet --defconfig $dom`
if
[ $? -
ne
0 ];
then
echo
-e
"\nAn error occurred while creating domain ${dom##*/}: $XMC\n"
rc_failed $?
echo
-e
'!'
else
# usleep函数是延时函数.
# XENDOMAINS_CREATE_USLEEP=5000000
# usleep延时计算方法:sleep $1/1000000
usleep $XENDOMAINS_CREATE_USLEEP
fi
fi
done
fi
}
|
(15) Xenstore的简单说明:
列目录
|
1
2
3
4
5
6
7
8
|
xenstore-
ls
:递归方式列出xenstored中全部的键值对.
xenstore-list :仅显示当前目录中内容.
如:
[root@node1 xen]
# xenstore-list -s / #列出xenstored根目录树中的内容.
tool : 暂时没有数据.
local
：存放了活动虚拟机配置和驱动信息
vm :存放虚拟机管理信息
libxl :这是一个空文件。用途不详.
|
读写
|
1
2
|
xenstore-
read
: 可用来读取xenstored中文件的内容.
xenstore-write : 可用来修改xenstored中的内容。
|
创建/删除目录
|
1
2
|
xenstore-
mkdir
xenstore-
rm
|
监视
|
1
|
xenstore-
watch
|
附件1：
Xen已解决的安全问题【原文:http://www.51ou.com/browse/xen/50466.html】
（1）Xen的访问控制
Xen经过本身的访问控制模块ACM。能有效解决诸多访问不当形成的安全问题。
ACM实现了两种策略机制，分别是中国墙（Chinesewall）策略和简单类型强制（simple type enforcement：STE）策略。其中，中围墙策略定义了一组中国墙类型，并所以定义冲突集，而后根据类型定义标签。该策略根据标签来进行判断，若两个虚拟机的标签处在同一个冲突集中。则不能同时在相同的系统上运行。所以该机制主要用于虚拟机之间的信息流控制。STE策略亦定义了一组类型（该类型针对的是域所拥有的资源），而后根据类型定义标签，要求当上体拥有客体标签时。主体才能访问客体。以此来控制资源共享。除此之外，Xen的Domain 0用户能够根据本身的需求制定安全策略。当虚拟机请求与别的虚拟机进行通讯或访问资源时。ACM模块能根据用户定义的策略判断,以此达到对虚拟机的资源进行控制以及对虚拟机之间的信息流进行控制的目的。
（2）Xen的可信计算
可信计算技术是一种新兴的信息安全手段，其安全措施是经过构建信任链来防护攻击。经过传递机制，在系统启动时可将B10S中最早启动的代码BIOS boot loader做为整个信任链的起点，依次逐级向上传递系统控制权并构建信任链，直到应用层。可信计算能够有效弥补传统安全防议没法提供的有关通讯终点节点完整性与可信性差的问题。
可信计算平台是可以提供可信计算服务的计算机软硬件实体。它可以提供系统的可靠性、可用性以及信息和行为的安全性。所以，创建可信平台是应对云计算安全的一种重要手段。而可信平台模块（TPM）是可信计算的基石。
TPM其实是一个含有密码运算部件和存储部件的系统级芯片，是云计算平台重要的防篡改组件，这能有效保证平台的安全。相对于传统物理平台，可信平台在Xen等虚拟化平台上实现TPM，有必定的优越性。平时计算机装了太多软件，这使得构建信任链变得很复杂。相对而言，使用虚拟机（VM）配合虚拟可信平台模块（vTPM）组成虚拟终端可信平台要方便得多。这是由于虚拟终端可信平台一般只为处理某种特定任务而产生，可由用户自定义其所需功能，因此功能相对简单，更容易构建信任链。此平台能够来处理须要安全保障的在线服务或敏感数据的访问。
如今，Xen 3.0以上的版本都能支持vTPM的实现。vTPM能实现虚拟计算系统中虚拟机的安全可靠。vTPM可使平台上的每一个虚拟机利用其功能。让每一个须要TPM功能的虚拟机都感受是在访问本身私有的TPM同样。在平台搭建中,能够建立多个虚拟TPM，这样每个如实地效仿硬件TPM的功能，可有效维护各个虚拟机的安全。从而使Xen搭建的云计算平台处于较稳定状态。
Xen的现有问题及解决策略
目前的Xen的安全性还有较多的安全问题。好比，Domain 0是一个安全瓶颈，其功能较其余域强，因此容易被敌手发起蠕虫、病毒、DoS等各类攻击，若是Domain 0瘫痪或者被敌手攻破，那么将破坏整个虚拟机系统。Xen的隐通道问题没有解决。在Xen上就不可能运行高安全等级的操做系统。虚拟机共享同一套硬件设备，一些网络安全协议可能更加容易遭到恶意破坏和恶意实施。Xen提供了方便的保存和恢复机制。使得操做系统数据的回滚和重放很是容易，但这些将影响操做自己的密码特性。除此以外，在Xen中，因为安全机制作在Guest OS中，因此不能保证VMM的安全。Xen只能限制页表一级的内存I/O地址空间。而中断和I/0端口地址空间的粒度要比页表小得多。若是不一样虚拟机中的驱动不幸被分配到同一个页表空间，那么它们就能够访问对方的内存地址空间，形成安全问题。
针对Domain 0的问题。可削弱它的功能。将其功能分解到其余域。这将会适当减小Domain 0的瓶颈做用。对于敏感数据要进行屡次擦除防止再恢复。另外，Xen的ACM模块不能彻底解决设备隔离和资源隔离问题，将Xen和LaGrande技术结合是一个不错的选择。LaGrande是lnfel将要实施的一种硬件技术，它是一组通用的硬件安全加强组件。用来防止敏感的信息被恶意软件攻击。其安全功能将被整合处处理器和芯片集中。能有效加强设备隔离，实现I/O保护、内存越界保护、键盘、显示的隔离保护等。
业界对虚拟化安全的努力
针对传统安全防火墙技术不能有效监控虚拟机流量的问题，mtor Networks公司使用VMware的API来开发虚拟安全分析器，以检测虚拟交换机流量——在虚拟层之上的网络层流量。该公司也开发了虚拟网络防火墙，该防火墙基于虚拟机管理器，可认证有状态的虚拟防火墙，检查全部经过虚拟机的数据分组，组织全部未经批准的链接和容许对数据分组进行更深层次的检查，确保了虚拟机间通讯的安全。针对虚拟环境的安全问题，目前Resolution Enterprise公司提出要对虚拟化环境采起深层防御战略。
除此之外。开源Xen管理程序社区Xen.org已经开始实施Xen云平台（XCP）计划。目的是在云环境中利用领先的Xen管理程序。为将来的云服务提供安全的、通过验证的开源基础设施乎台。目前。已经发布了XCPl.0及其修正版，并将慢慢发布更加稳定的版本。
Citrix
Citrix系统公司是全球领先的应用服务器软件方案供应商。Citrix凭借其卓越的技术方案和业务成就，赢得了业界与用户的普遍赞誉。收购XenSource以后，Ctrix在虚拟化领域的能力进一步提升，具备了足够的技术储备应对云计算挑战。Citrix与其它云端服务供货商的最大不一样在于，提供端对端的产品服务：包含Dazzle、XenDesktop、XenApp、NetScaler、XenServer与即将推出的XenClient，以及透过遵循开放标准等方式，与储存设备、服务器业者结盟、推广云端服务产品
附件2：
qemu-img是qemu用来实现磁盘映像管理的工具组件，其有许多子命令，分别用于实现不一样的管理功能，而每个子命令也都有一系列不一样的选项。其使用语法格式为“qemu-img subcommand [options]”，支持的子命令以下。
◇ create：建立一个新的磁盘映像文件；
格式: qemu-img -f DISK_FORMAT -o ? /tmp/test.img #查看指定的DISK_FORMAT所支持的额外特性参数.
注: 若是“-o”选项中使用了backing_file这个选项来指定其后端镜像文件，那么这个建立的镜像文件仅记录与后端镜像文件的差别部分，后端镜像文件不会被修改，除非在QEMU monitor中使用“commit”命令或者使用“qemu-img commit”命令去手动提交这些改动; 这种状况下，size参数不是必须需的，其值默认为后端镜像文件的大小。另外，直接使用“-b backfile”参数也与“-o backing_file=backfile”效果相同。
|
1
2
3
4
5
6
7
|
qemu-img create -f qcow2 -b
/tmp/rhel6u3
.img
/tmp/rhel6u3
.qcow2
# 或
qemu-img create -f qcow2 -o backing_file=
/tmp/rhel6u3
.img
/tmp/rhel6u3
.qcow2
# 注: rhel6u3.qcow2 能够做为镜像文件启动, 有点相似VMware的链接克隆VM,
# 但须要注意: 这并不是是VMware的链接克隆,由于,当你启动rhel6u3.qcow2的VM后,
# 你在该VM中建立的文件、目录等会在关闭该VM后，自动同步到rhel6u3.img中.
# 若你启动了rhel6u3.img这个VM,可能会形成rhel6u3.qcow2镜像出现错误.
|
◇ check：检查磁盘映像文件中的错误；
对磁盘镜像文件进行一致性检查，查找镜像文件中的错误，目前仅支持对“qcow2”、“qed”、“vdi”格式文件的检查。
(1) qcow2: QEMU 0.8.3版本引入的镜像文件格式，也是目前使用最普遍的格式。
(2) qed（QEMU enhanced disk）: 从QEMU 0.14版开始加入的加强磁盘文件格式,
它是为了不qcow2格式的一些缺点,同时提升性能而引入,目前还不够成熟。
(3) vdi（Virtual Disk Image）: Oracle的VirtualBox虚拟机中的存储格式。
-f fmt： 指定文件的格式，若是不指定格式qemu-img会自动检测，filename是磁盘镜像文件的名称（包括路径）。
|
1
|
qemu-img check -f qcow2
/tmp/rhel6u3
.qcow2
|
◇ convert：转换磁盘映像的格式；
格式：qemu-img convert [-c] [-f fmt] [-O output_fmt] [-o options] filename [filename2 […]] output_filename
-c :对输出的镜像文件进行压缩,仅支持qcow2和qcow格式,且此压缩是只读的,若压缩的扇区被重写,则会被重写为未压缩的数据。
-f : 指定源磁盘映像文件的格式.
-O : 指定输出磁盘映像文件的格式.
-o : 指定输出磁盘映像文件的其它选项:如:后端镜像、文件大小、是否加密等等
注: 使用backing_file选项来指定后端镜像，让生成的文件是copy-on-write的增量文件，
这时必须让转换命令中指定的后端镜像与输入文件的后端镜像的内容是相同的，
尽管它们各自后端镜像的目录、格式可能不一样。
注: 通常来讲，输入文件格式fmt由qemu-img工具自动检测到，而输出文件格式output_fmt根据本身须要来指定，默认会被转换为raw文件格式（且默认使用稀疏文件的方式存储以节省存储空间）。另外若是使用qcow二、qcow、cow等做为输出文件格式来转换raw格式的镜像文件（非稀疏文件格式），镜像转换还能够起到将镜像文件转化为更小的镜像，由于它能够将空的扇区删除使之在生成的输出文件中并不存在。
|
1
|
qemu-img convert
/tmp/my-vmware
.vmdk
/tmp/my-kvm
.img
|
◇ info：显示指定磁盘映像的信息；
注: 若是文件是使用稀疏文件的存储方式，也会显示出它的原本分配的大小以及实际已占用的磁盘空间大小。若是文件中存放有客户机快照，快照的信息也会被显示出来。
|
1
|
qemu-img info
/tmp/rhel6u3
.img
|
◇ snapshot：管理磁盘映像的快照；
格式: qemu-img snapshot [-l | -a snapshot | -c snapshot | -d snapshot] filename
-l： 选项是查询并列出镜像文件中的全部快照
-a snapshot ： 是让镜像文件使用某个快照
-c snapshot ： 是建立一个快照
-d snapshot ： 是删除一个快照。
◇ commit：提交filename文件中的更改到后端支持镜像文件（建立时经过backing_file指定的）中去；
格式: qemu-img commit [-f fmt] filename
◇ rbase：改变镜像文件的后端镜像文件，只有qcow2和qed格式支持rebase命令；
格式: qemu-img rebase [-f fmt] [-t cache] [-p] [-u] -b backing_file [-F backing_fmt] filename
-b backing_file：指定做为后端磁盘映像的文件
-F backing_fmt：指定将后端映像文件转换为什么种磁盘映像格式。
注：rbase操做可工做于两种模式下，安全模式（Safe Mode）【默认模式】和 非安全模式【Unsafe Mode】
在安全模式下qemu-img会去比较原来的后端镜像与如今的后端镜像的不一样进行合并处理；
-u 可指定非安全模式（Unsafe Mode），此模式主要用于将后端镜像进行了重命名或移动位置以后对前端镜像文件的修复处理,由用户去保证后端镜像的一致性。
◇ resize：增大或缩减磁盘映像文件的大小；
格式: qemu-img resize filename [+ | -]size
+ : 增长
– ：减小
size： 单位支持:K/M/G/T
缩小镜像的大小前，需保证客户机里面的文件系统有空余空间，不然会数据丢失，
另外，qcow2格式文件不支持缩小镜像的操做。在增长了镜像文件大小后，也需启动客户机到
里面去使用“fdisk”、“parted”等分区工具进行相应的操做才能真正让客户机使用到增长后的镜像空间。
不过使用resize命令时须要当心（最好作好备份），若是失败的话，可能会致使镜像文件没法正常使用而形成数据丢失。
|
1
|
qemu-img resize
/tmp/rhel6u3-a
.img +2G
|
附件3：
1.1 建立一个Busybox虚拟机示例:
(1) 建立一个虚拟磁盘映像文件:
|
1
|
qemu-img create -f raw -o size=2G
/images/xen/busybox
.img
|
(2) 将其格式化并挂载:
|
1
2
3
|
cd
/images/xen
mkfs.ext2 busybox.img
mount
-o loop
/images/xen/busybox
.img
/mnt
|
(3) 编译busybox
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
# 下载busybox:
tar
xvjf busybox-*.
tar
.bz2
cd
busybox*
make
menuconfig
# 注:若busybox须要进行静态编译则须要安装: yum install glibc-static ；
# 此RPM包能够支持静态编译,使编译的应用程序可直接包含所须要的外部库,而非链接载入外部库.
busybox Settings-->Build Optons-->Build BusyBox as a static binary(no shared libs)
|-->Installation Options（”
make
install
" behavior)
make
make
install
#注:安装后,busybox会文件安装到当前编译目录下的_install目录中.
cd
_install
cp
-a *
/mnt
#将busybox的全部文件copy到busybox.img中,做为一个模拟的根文件系统.
# 提供如下目录,也是十分重要的:
mkdir
-pv
/mnt/
{proc, var, sys, etc, dev, usr, tmp, home, root, opt}
|
(4) chroot测试:
|
1
|
chroot
/mnt
|
(5) 在Dom0上建立桥设备
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
# 注: 添加桥,并配置DomU启动时,自动桥接到Dom0上建立的桥设备.
# 这里存在一个Kernel-Bug: 若使用kernel-3.6.10-6八、3.6.18都存在将物理网卡桥到桥设备后,Kernel无响应的问题.
# 建议: 作桥实验时,采用kernel-3.6.7版本的。
yum
install
bridge-utils
vim
/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
NM_CONTROLLED=no
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=
yes
USERCTL=no
BRIDGE=xenbr0
vim
/etc/sysconfig/network-scripts/ifcfg-xenbr0
DEVICE=xenbr0
NM_CONTROLLED=no
TYPE=Bridge
BOOTPROTO=none
IPADDR=192.168.1.10
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
DNS1=8.8.8.8
ONBOOT=
yes
USERCTL=no
DELAY=0
service NetworkManager stop
chkconfig NetworkManager off
#NetworkManager会致使桥建立失败.
service network restart
|
(6) 为busybox测试系统提供网卡驱动
|
1
2
3
4
5
6
7
8
|
cd
/mnt/lib/modules/
`
uname
-r`
/kernel/drivers/net/
modinfo xen-netfront.ko
#PV模式下,DomU应该使用网卡的前半段;所以这个驱动须要.
# 查看xen-netfront.ko 有没有依赖其余模块,即"depends"段是否有依赖模块.
modinfo 8139too.ko
modinfo mii.ko
#8139依赖与mii模块.
mkdir
-pv
/mnt/lib/modules
cp
xen-netfront.ko 8139too.ko mii.ko
/mnt/lib/modules/
umount
/mnt
#卸载busybox的映像文件.
|
(7) 建立启动DomU的配置文件:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
ls
/etc/xen
xl.conf
#此配置文件为xl命令的全局通用配置文件.
xlexample.hvm
#这是一个HVM模式运行的DomU的示例配置文件.
xlexample.pvlinux
#这是PV模式运行的DomU配置文件示例.
cp
xlexample.pvlinux busybox
vim busybox
【
name=
"busybox-001"
kernel=
"/boot/vmlinuz"
#注:这是Dom0的/boot下的vmlinuz,此为DomU启动时的Kernel文件.
ramdisk=
"/boot/initramfs.img"
#它也是Dom0上的initramfs.img.
extra=
"selinux=0 init=/bin/sh"
#指定传递给kernel的额外参数,关闭selinux,系统启动后第一个执行的程序为/bin/sh
root=
"/dev/xvda ro"
#指定根文件系统的位置; 这里须要注意: 由于busybox.img建立后,并无分区,就直接被格式化了.
# 所以就一个分区,不存在其它分区,因此这里直接写成/dev/xvda而不是/dev/xvda1.
# 另外 系统在启动初期是以只读方式挂载的.这样须要注意.
memory=256
#指定内存大小为256M
#maxmem = 512 #若启用最大内存参数,则能够在DomU运行时,经过如下命令来动态调整DomU的内存.
# xl mem-max 和 xl mem-set
vcpus=2
disk=[
'/images/xen/busybox.img,raw,xvda,rw'
]
vif=[
'mac=00:16:3e:00:00:01,bridge=xenbr0'
]
# bridge:是关键参数,其它参数都是可选参数。
】
|
(8) 启动busybox虚拟机登陆后:
|
1
2
3
4
5
6
7
8
|
ifconfig
-a
#是看不到任何接口的.
insmod
/lib/modules/xen-netfront
.ko
#安装网卡接口驱动模块
ifconfig
-a
ifconfig
eth0 192.168.1.20 up
ctrl + ]
# 回到到Dom0,查看网络接口状态.
Dom0:
ifconfig
-a
#将能够看到一个新接口.vif#.@
# "#": 表示DomU的ID ； @:表示Dom0上建立的桥ID.
Dom0: brctl show
#将看到新接口已经被桥接到Dom0的桥设备上了。
|
1.2 建立自有Kernel和initramfs文件的busybox DomU
(1) 提供磁盘映像文件【注: Xen的VM对qcow2格式的磁盘可能没法识别,所以,这里建议自行测试,raw格式是没有问题的.】
|
1
|
qemu-img create -f qcow2 -o size=5G,preallocation=metadata
/images/xen/busybox3
.img
|
(2) 对该映像文件进行分区
|
1
2
3
4
5
6
7
8
9
10
11
|
# losetup ：这是一个将loop设备文件关联到/dev/loop*的命令,只有关联到/dev/loop设备后,才能对loop设备文件分区格式化.
losetup -a
#查看当前已经被关联的loop设备状况.
losetup -f
#列出当前可用的第一个空闲loop设备.
# 注:ls /dev/loop* 可用看到系统中已经存在的loop设备.
losetup
/dev/loop0
/images/xen/busybox3
.img
#将busybox3.img关联到loop0设备,接着就能够对其作分区格式化了.
#mount -o loop是先作关联,而后就直接挂载loop设备到挂载点了。
fdisk
/dev/loop0
kpartx -av
/dev/loop0
#刷新loop0的分区信息,并建立分区映射到/dev/mapper中.
ls
/dev/mapper
#分区刷新完成后,可在这里看到loop0的分区文件
mkfs.ext3
/dev/mapper/loop0p1
mkfs.ext3
/dev/mapper/loop0p2
#对loop0p2进行格式化.
|
(3)向 /images/xen/busybox3.img 中boot分区和root分区提供数据文件.:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
# <1> 挂载分区到/mnt
mkdir
/mnt/
{boot, sysroot}
mount
/dev/mapper/loop0p1
/mnt/boot
mount
/dev/mapper/loop0p2
/mnt/sysroot
# <2>提供boot分区文件
cp
/boot/vmlinuz-2
.6.*
/mnt/boot/
cp
/boot/initramfs-2
.6.*
/mnt/boot/initramfs
.img
#安装bootloader到/dev/loop0,复制启动文件到/mnt/boot/grub。
grub-
install
--root-directory=
/mnt
/dev/loop0
vim
/mnt/boot/grub/grub
.conf
【
default=0
timeout=3
title Busybox (Linux-2.6.32)
root (hd0,0)
kernel
/vmlinuz
root=
/dev/xvda1
ro selinux=0 init=
/bin/bash
initrd
/initramfs
.img
】
# <3>提供root分区文件
cp
-a $BUSYBOX
/_install/
*
/mnt/sysroot/
mkdir
-pv
/mnt/sysroot/
{proc, var, dev, lib
/modules
, tmp, etc, home, root}
cp
/lib/modules/
`
uname
-r`
/kernel/drivers/net/xen-netfront
.ko
/mnt/sysroot/lib/modules/
# <4>手动拆除loop设备
losetup -a
#查看当前已经关联的loop设备
umount
/mnt/boot
umount
/mnt/sysroot
kpartx -d
/dev/loop0
#删除loop0中分区的映射.
|
(4) 提供busybox3的启动配置文件
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
vim
/etc/xen/busybox3
【
name=
"busybox-003"
# 下面参数都去掉,由于busybox3已经有本身的grub.conf和kernel、initramfs了.
#kernel="/boot/vmlinuz" #注:这是Dom0的/boot下的vmlinuz,此为DomU启动时的Kernel文件.
#ramdisk="/boot/initramfs.img" #它也是Dom0上的initramfs.img.
#extra="selinux=0 init=/bin/sh" #指定传递给kernel的额外参数,关闭selinux,系统启动后第一个执行的程序为/bin/sh
#root="/dev/xvda ro" #指定根文件系统的位置; 这里须要注意: 由于busybox.img建立后,并无分区,就直接被格式化了.
# 所以就一个分区,不存在其它分区,因此这里直接写成/dev/xvda而不是/dev/xvda1.
# 另外 系统在启动初期是以只读方式挂载的.这样须要注意.
memory=256
#指定内存大小为256M
#maxmem = 512
vcpus=2
disk=[
'/images/xen/busybox3.img,qcow2,xvda,rw'
]
vif=[
'mac=00:16:3e:00:00:02,bridge=xenbr0'
]
# bridge:是关键参数,其它参数都是可选参数。
bootloader=
"/usr/bin/pygrub"
#此pygrub是用python研发的工具,它能够向DomU提供启动引导,
#并自动找到busybox3.img中第一个分区并启动kernel.
# 注: 关于根文件系统(Root Filesystem):它包含了应用程序、系统组件及配置文件等运行DomU的各类所需文件的
# 文件系统,其并不是必须包含Kernel及initramfs.img,它们彻底能够放在Dom0中; 事实上,用于DomU的内核文件必须
# 要可以容许Dom0访问到,由于其运行时须要与Xen Hypervisor通讯,所以这些组件必须位于Dom0可以访问到的
# 任何文件系统上; 然而目前基于pygrub的方式,容许DomU的内核文件直接放置于DomU的虚拟磁盘映像文件中,
# 但pygrub实际上只是一种让Dom0能够访问到DomU虚拟磁盘映像文件中的kernel文件的工具.
】
|
附件4：
虚拟化面临的重要问题：CPU、RAM、I/O的模拟。
CPU模拟:
(1) 全部OS设计时都认为Kernel是能够控制全部硬件,并可运行CPU的特权指令,即Kernel运行于CPU的Ring0上。
(2) 多个OS没法同时直接运行于硬件层之上,它们必须运行在Hypervisor层(下文称:Host)上；就如同不安装操做系统，就不能安装VMware,没有VMware就没法让虚拟机(下文称:Guest)运行起来同样。那问题来了,若Guest必须运行在CPU的Ring0上,Host运行在哪里？
(3) OS设计时它认为本身是能够控制全部硬件资源的,那GuestOS之间不就能够相互影响了吗？Guest1要关机,若
它直接执行CPU的特权指令关机,那它应该能够关闭整个物理机器,这不是虚拟化所但愿的。
这些问题给CPU虚拟化带来了诸多问题, 但实际上Host必定是真正能执行CPU的特权指令的,Guest运行起来后,它实际控制的CPU是经过软件模拟的CPU,实际上任何物理硬件都是经过集成电路进行运算,经过微代码向外提供输出结果的接口,只有经过软件模拟出这些接口就能够模拟硬件.
BT技术: BinaryTranslation(二进制翻译)技术,它可让Guest在发起特权指令时,直接将其翻译为Host的系统调用,以便加速Guest的执行性能.BT技术出现是由于Guest用户空间的APP要进行特权操做时,Guest上的APP须要先将请求发给Guest的Kernel,Guest的Kernel经翻译转换发给模拟CPU,模拟CPU在将其转换为Host的系统调用,再发给Host的Kernel再进行翻译转换后给物理CPU执行.最后返回,这使得GuestOS的执行性能不高.
<> 模拟CPU 和 虚拟CPU
》模拟CPU：是完整虚拟,即模拟出CPU的环0,环1,环2,环3；这一般在底层硬件与虚拟环境的硬件不一样时采用模拟CPU的方式。
》虚拟CPU：仅模拟CPU的环0, Guest的用户空间中的APP可直接运行在物理CPU的环3上,仅环0上的特权指令进行翻译.这是Guest的硬件环境与底层硬件环境一致时用。
<> 彻底虚拟化 和 半虚拟化
》彻底虚拟化(Full-Virtulization): 即Guest不知道本身是运行在虚拟化环境中,它一直都认为本身是能够控制所有的硬件资源.
所以须要将GuestOS对特权指令的操做都进行翻译后，由Host带为执行。
VMware的BT技术 和 AMD CPU的AMD-v、Intel的VT-x这两种HVM(硬件虚拟化)技术实际上都是彻底虚拟化，
由于它们都是帮助Host高效完成特权指令翻译的技术。
注:AMD-v 和 VT-x实现了将原先只有4环的CPU扩展为5环,并让Host运行在-1环上,腾出环0给Guest用,这样Guest就
认为本身是运行在环0上,而且可直接执行特权指令,但实际上,Guest调用环0上的特权指令时,CPU会直接将其翻译为
真实的特权指令并激活Host的内核来调用环-1来执行特权指令，这进一步缩短了翻译流程。
Memory虚拟化:
(1) 在物理机中,内存的使用通过虚拟化后，提供给物理机上运行的APP的。
(2) 在物理机中,APP看到的内存是：虚拟线性地址空间,即APP认为本身使用的是所有的物理内存,从0-1024(假设内存为1G)
内核看到的内存是：真实物理地址空间
(3) 因为物理机的内存已经被虚拟化过了, Guest访问物理内存就须要再次被虚拟一层。
注:TLB: 转换后页面缓存
Host上的APP访问内存的流程：
APP–>发送访问线性地址:10page的数据–>CPU–>将10page的线性地址转给MMU–>
查询线性与物理地址映射表–>缓存映射关系到TLB,并读取物理地址中的数据–>返回。
Guest上的APP访问内存的流程：
Shadow Page Table的方式：
注: 假设将Guest的APP访问的虚拟线程地址称为:GVA.
将Guest虚拟机所得到的虚拟物理内存地址称为：GPA
Guest-APP–>发送访问线性地址(GVA):10page的数据–>虚拟CPU–>将其转给虚拟MMU–>
查询并缓存映射到虚拟TLB–>GPA的访问请求被发给Host–>
但GPA并不是Host的虚拟线性地址，又非真实物理地址,所以没法由真实CPU处理–>
Host上不得不采用软件模拟来完成将GPA转换为真实物理内存的物理地址，
此方式叫 Shadow page table(影子页表),并最终得到物理内存中的数据，返回给Guest.
Intel的EPT(Extended Page Table:扩展页表) 和 AMD的NPT(Nested Page Table:嵌入页表)技术 》MMU虚拟化 和 TLB虚拟化 注: TLB虚拟化: 因为GuestA和GuestB都被分配了1G的内存,GuestA和GuestB将具备相同的内存地址, 但GuestA和GuestB它们实际映射到Host上的物理内存的地址段确定是不一样的。但GuestA 访问它的10page的数据若被缓存在TLB中，GuestB到CPU执行时,它恰巧也要访问它的10page的数据 那TLB中缓存的条目确定会对GuestB形成干扰，致使访问错误，所以只能将TLB清空,即GuestB到CPU 上执行时,TLB是空的,所以CPU只能再经过MMU查映射关系,缓存TLB再访问数据。这致使TLB成了摆设 没有起到提升访问物理内存效率的做用。这才出现了TLB的虚拟化, 而TLB的虚拟化将原先的只有两个 字段缓存的TLB改为缓存三个字段: 一个GuestOS标识, 一个GVA，一个HPA(Host中真实物理地址)。 Guest-APP–>发生访问线性地址(GVA): 10page的数据—> 这时访问请求被同时发送了两份,并同时分别走了如下路线 路线1–>虚拟CPU–>虚拟MMU–>虚拟TLB–>完成. 路线2–>EPT/NPT硬件实现的MMU–>EPT/NPT实现的TLB–>获取真实物理地址中的数据–>返回给Guest. 这样作后，即没有改变GuestOS访问内存的过程，同时提升了GuestOS访问内存的效率。 I/O虚拟化： (1) 外存设备虚拟化 磁盘、光驱、U盘 (2) 网络设备虚拟化 网卡 (3) 输入设备 ： 它的虚拟化采用角点当前被谁捕获来模拟的,若当前被虚拟机捕获,则会动态将模拟键盘或鼠标与物理设备关联. ps/二、USB (4) 显示设备 : 它不能被模拟。 VGA I/O虚拟化的三种技术:【注: 这三种技术只针对存储和网络，其I/O设备的模拟不采用这些技术。】 》模拟 ： 如VMware那一个文件作为VM的磁盘,这就是模拟。 》半虚拟化： 模拟的过程：Guest-APP去访问I/O设备,如网卡,Guest-Kernel须要先调用虚拟网卡的驱动–>虚拟网卡驱动将数据 转发给虚拟网卡–>虚拟网卡再转给Hypervisor上模拟的网卡进程–>该网卡进程再将数据放入IO Stack(IO栈)中 等待真实网卡驱动将其转给物理网卡并由其将数据转发出去。 半虚拟化的过程：Guest-APP去访问I/O设备,如网卡,但此时GuestOS明确知道本身不能直接访问到物理网卡,所以, 直接将数据转给前端设备(它相似一个转发器,但对GuestOS中的用户看来它是一个网卡设备)–>前端设备直接与 Hypervisor上的网卡进程通讯–>网卡进程将数据转到IO Stack中–>物理机驱动将其转发给物理网卡。 注: 前端设备(IO frontend)：在Guest端省去了Guest虚拟网卡驱动的步骤。 后端设备(IO backend)：在Hypervisor端从虚拟网卡进程到物理网卡称为后端设备。 》I/O透传： 假如规划中该主机上须要运行4台虚拟机,该主机上安装了6块盘,6块网卡,物理机磁盘和网卡都使用两个， 剩余的都给虚拟机使用,那彻底能够给每一个虚拟机分一个物理磁盘和一个物理网卡,这样其性能可几乎接近于硬件 访问，但这须要Hypervisor来中的设备管理器来分配。 x86平台上DMA(直接内存访问)是集中共享式管理的 假如当前Hypervisor管理着4块网卡,如今GuestA和GuestB要发生数据到网卡上, GuestA和GuestB都须要借助DMA来代其完成,但DMA是共享式管理,它仅仅负责接收 Kernel发来的命令而后,根据指示将指定内存地址中的数据发送到指定IO设备,如网卡, 或将网卡上收到的数据存入到指定的内存地址中。问题是Guest经过复杂的kernel调用 过程完成了DMA代其发送数据包到网卡,但GuestOS并不知道DMA将数据包发到那个网卡 上了，更没有人知道回应的包到网卡后,应该转发给那个GuestOS. 注: DMA:它的做用是帮助Kernel完成一些须要长时间等待的任务,如：写数据到磁盘, 从磁盘中读数据到内存,将网卡上收到的数据读到内存等; 这对提升Kernel的执行 效率是很是有帮助的。 IO设备： 每一个IO设备上都有控制器,而且每一个IO设备的控制器上都有寄存器且都有相应的端口地址。 IOMMU: IO内存地址管理单元 它的做用是自动将IO总线与相应的IO端口关联的设备。 若须要将某块网卡绑定给某GuestOS单独使用,就须要在Hypervisor级别来控制对I/O端口的调用 就只能接受该GuestOS的调用了，而它的实现就须要借助DMA中实现IOMMU来完成。而Intel的VT-d 就是这样一种技术，它在DMA中实现了IOMMU,并自动来完成IO总线与IO端口的映射关联。 IOMMU的映射是完成将物理IO设备绑定给GuestOS的第一步,接着还需完成将物理IO设备的中断信号 也要映射给该GuestOS,要知道物理设备在实现中断映射一般采用中断控制器 或 DMA等方式实现,而采用DMA方式 则须要DMA必须可以访问所有的物理内存,由于DMA须要将IO设备的寄存器中的数据搬到指定的内存地址空间 或反过来；而若将物理硬件绑定给GuestOS,则DMA就须要访问GuestOS的所有物理内存,但实际上GuestOS 的内存是虚拟的,这就须要通过复杂的转换后才能访问到其对应的物理内存地址空间，这也进一步加大了 中断信号与GuestOS的映射；而这仍是完成虚拟机绑定硬件的第二步。最后一步是完成IO设备缓冲区与GuestOS 的映射,这里必须知道缓冲区必定是物理内存中的一段空间,如何让虚拟机的内核知道这是本身所管理的物理IO设备的 IO缓冲区？；而这一切Intel的VT-d都帮咱们实现了。 Intel的VT-d 简单来讲 VT-d 是一种基于北桥的硬件辅助虚拟化技术。 Intel的硬件辅助虚拟化技术： CPU: vt-x， EPT， tagged-TLB IO： vt-d，SR-IOV:单根设备虚拟化协议， VMDq 这些技术详细分为三类： 第一类: 跟处理器相关: VT-x, EPT, tagged-TLB 第二类: 跟芯片相关: vt-d 第三类: 跟IO输入输出相关: VMDq 和 SR-IOV IO虚拟化技术： QEMU(法国天才程序员开发) 、virtio(澳大利亚天才程序员开发) KVM和Xen都须要借助以上两种虚拟化技术实现IO虚拟化。 虚拟化技术分类： (1) 模拟：【特色:虚拟硬件环境与底层硬件环境无关.】 著名的模拟器: PearPC, Bochs, QEMU (2) 彻底虚拟化: 【特色: 虚拟硬件环境与底层硬件环境必须一致。】 在彻底虚拟化中一般采用两种加速技术: BT : 二进制翻译加速技术 HVM: 基于硬件的虚拟化 知名的产品：VMware Workstation, VMware Server, Parallels Disktop(iMac上用), KVM, Xen(HVM) (3) 半虚拟化：【一样要求虚拟硬件环境与底层硬件环境必须保持一致】 知名的开源产品: xen, uml(user-mode linux) (4) OS级别的虚拟化: OpenVZ, LXC(LinuX Container), libcontainer, Virtuozzo, Linux V Servers Solaris Containers FressBSD jails (5) 库虚拟化: wine
- 1. Xen
- 2. KVM xen
- 3. 为 xen server 6.2 建立xen licensing server
- 4. 为 xen server 6.2 创建xen licensing server
- 5. linux xen安装
- 6. Xen的概况
- 7. Xen的使用
- 8. Xen, KVM Compare
- 9. xen 记录
- 10. Xen虚拟化
- 更多相关文章...
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Xen
- 2. KVM xen
- 3. 为 xen server 6.2 建立xen licensing server
- 4. 为 xen server 6.2 创建xen licensing server
- 5. linux xen安装
- 6. Xen的概况
- 7. Xen的使用
- 8. Xen, KVM Compare
- 9. xen 记录
- 10. Xen虚拟化