Refer to : http://www.178linux.com/14764
目录:
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和内存的虚拟化过程【注: 关于虚拟化中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是无法识别的。
用下图来做简单说明
注: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: 表示磁盘映像文件或设备文件路径:
如: /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 |
|
1 2 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
创建一台cirros虚拟机:
(1) 下载Cirros: http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
(2) 创建image存储目录
1 2 |
|
(3) 创建Xen DomU的启动配置文件:
1 2 3 4 5 6 7 8 9 10 |
|
(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 |
|
(5) 测试启动
1 2 3 4 5 6 7 |
|
基本命令使用说明
1 2 3 4 5 6 7 8 9 |
|
启动cirros虚拟机登录后:
1 2 3 4 5 6 7 8 |
|
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 |
|
基本功能测试部分:
(6) 测试打开本地图形窗口:
1 2 3 4 5 6 7 8 9 10 11 |
|
(7) 测试动态添加和拆除磁盘
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
(8) 测试动态添加网卡
1 2 3 4 5 6 7 |
|
(9) 保存DomU当前的内存数据到指定位置.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
(10) 恢复保存的DomU状态
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
(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 |
|
(12) 测试创建克隆DomU.
1) 类似VMware中的连接克隆.
1 2 3 4 5 |
|
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 |
|
(c)启动WinXP后,连接VNC开始从CDROM安装WinXP.
1 2 |
|
(d)克隆WinXP的映像文件
1 |
|
(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 |
|
(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 |
|
(15) Xenstore的简单说明:
列目录
1 2 3 4 5 6 7 8 |
|
读写
1 2 |
|
建立/删除目录
1 2 |
|
监视
1 |
|
附件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 |
|
◇ 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 |
|
◇ 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文件格式(且默认使用稀疏文件的方式存储以节省存储空间)。另外如果使用qcow2、qcow、cow等作为输出文件格式来转换raw格式的镜像文件(非稀疏文件格式),镜像转换还可以起到将镜像文件转化为更小的镜像,因为它可以将空的扇区删除使之在生成的输出文件中并不存在。
1 |
|
◇ info:显示指定磁盘映像的信息;
注: 如果文件是使用稀疏文件的存储方式,也会显示出它的本来分配的大小以及实际已占用的磁盘空间大小。如果文件中存放有客户机快照,快照的信息也会被显示出来。
1 |
|
◇ 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 |
|
附件3:
1.1 创建一个Busybox虚拟机示例:
(1) 创建一个虚拟磁盘映像文件:
1 |
|
(2) 将其格式化并挂载:
1 2 3 |
|
(3) 编译busybox
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
(4) chroot测试:
1 |
|
(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 |
|
(6) 为busybox测试系统提供网卡驱动
1 2 3 4 5 6 7 8 |
|
(7) 创建启动DomU的配置文件:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
(8) 启动busybox虚拟机登录后:
1 2 3 4 5 6 7 8 |
|
1.2 创建自有Kernel和initramfs文件的busybox DomU
(1) 提供磁盘映像文件【注: Xen的VM对qcow2格式的磁盘可能无法识别,因此,这里建议自行测试,raw格式是没有问题的.】
1 |
|
(2) 对该映像文件进行分区
1 2 3 4 5 6 7 8 9 10 11 |
|
(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 |
|
(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 |
|
附件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/2、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
分类: Virtualization
Copyright © Newbie wang