Xen安裝部署和基本原理
Refer to : http://www.178linux.com/14764php
目錄：
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的根文件系統能夠以多種不一樣的方式安置html
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等平臺，並正在向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.node
<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.
python
1.3 Xen對CPU和內存的虛擬化過程【注: 關於虛擬化中CPU和內存的虛擬化在附件加入了一些補充.】：
Xen在給VM提供CPU的虛擬化時,它採用的也是在Xen hypervisor層啓動一個線程,並將這些線程映射到某個物理核心上,
固然經過DomU的配置文件中的cpus能夠指定將這些模擬CPU的線程綁定到某幾個物理核心上；而內存的虛擬化
則是內存頁的映射,將物理內存上多個連續或不連續的內存頁映射給VM,讓VM看來這就是一個完整的連續的內存空間.linux
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驅動程序去訪問本地系統內容，並從本身與半虛擬化客戶機的共享內存中讀取適合的數據塊後，隨即被寫入到本地磁盤的指定位置中。shell
但不管採用模擬或半虛擬化最終都是對物理磁盤的操做,假如當前只有一個物理磁盤,衆多用戶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/).vim
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>, [<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的安裝:
# 配置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
# 安裝Xen [root@centos6 ~]# yum install xen
# 配置啓動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存儲目錄
[root@centos6 ~]# mkdir -pv /images/xen/ [root@centos6 ~]# cp cirros-0.3.4-x86_64-disk.img /images/xen/cirros.img
(3) 建立Xen DomU的啓動配置文件:
[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) 建立橋接口
#注: 在建立橋接口前，須要先注意禁止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) 測試啓動
# 注：測試啓動後,請注意網卡的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的控制檯
基本命令使用說明
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虛擬機登陸後:
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的其它經常使用命令:
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) 測試打開本地圖形窗口:
[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) 測試動態添加和拆除磁盤
[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) 測試動態添加網卡
[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當前的內存數據到指定位置.
# 注:默認掛起後,會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狀態
[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：
[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中的鏈接克隆.
#注: 經過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的基本配置文件
[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.
#注:個人筆記本內存只有8G,分配給Xen VM 4G,但安裝WinXP依然巨慢,安裝了一個晚上才基本裝好. vncviewer 127.0.0.1:5900
(d)克隆WinXP的映像文件
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的實時遷移
# 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的分析說明:
#注: 此腳本存在一個小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的簡單說明:
列目錄
xenstore-ls :遞歸方式列出xenstored中全部的鍵值對. xenstore-list :僅顯示當前目錄中內容. 如: [root@node1 xen]# xenstore-list -s / #列出xenstored根目錄樹中的內容. tool : 暫時沒有數據. local ：存放了活動虛擬機配置和驅動信息 vm :存放虛擬機管理信息 libxl :這是一個空文件。用途不詳.
讀寫
xenstore-read : 可用來讀取xenstored中文件的內容. xenstore-write : 可用來修改xenstored中的內容。
創建/刪除目錄
xenstore-mkdir xenstore-rm
監視
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」效果相同。
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是磁盤鏡像文件的名稱（包括路徑）。
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格式的鏡像文件（非稀疏文件格式），鏡像轉換還能夠起到將鏡像文件轉化爲更小的鏡像，由於它能夠將空的扇區刪除使之在生成的輸出文件中並不存在。
qemu-img convert /tmp/my-vmware.vmdk /tmp/my-kvm.img
◇ info：顯示指定磁盤映像的信息；
注: 若是文件是使用稀疏文件的存儲方式，也會顯示出它的原本分配的大小以及實際已佔用的磁盤空間大小。若是文件中存放有客戶機快照，快照的信息也會被顯示出來。
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命令時須要當心（最好作好備份），若是失敗的話，可能會致使鏡像文件沒法正常使用而形成數據丟失。
qemu-img resize /tmp/rhel6u3-a.img +2G
附件3：
1.1 建立一個Busybox虛擬機示例:
(1) 建立一個虛擬磁盤映像文件:
qemu-img create -f raw -o size=2G /images/xen/busybox.img
(2) 將其格式化並掛載:
cd /images/xen mkfs.ext2 busybox.img mount -o loop /images/xen/busybox.img /mnt
(3) 編譯busybox
# 下載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測試:
chroot /mnt
(5) 在Dom0上建立橋設備
# 注: 添加橋,並配置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測試系統提供網卡驅動
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的配置文件:
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虛擬機登陸後:
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格式是沒有問題的.】
qemu-img create -f qcow2 -o size=5G,preallocation=metadata /images/xen/busybox3.img
(2) 對該映像文件進行分區
# 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> 掛載分區到/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的啓動配置文件
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. Xen安裝部署
- 3. Xen基本原理
- 4. kafka安裝部署和基本指令
- 5. Kerberos基本原理、安裝部署及用法
- 6. 簡要分析ZooKeeper基本原理及安裝部署
- 7. 16120九、簡要分析ZooKeeper基本原理及安裝部署
- 8. Xen虛擬化基本原理詳解
- 9. Mysql原理，安裝和基本使用
- 10. WAF基本原理與部署方式
- 更多相關文章...
- • Redis基本安裝和使用 - Redis教程
- • Maven 自動化部署 - Maven教程
- • Composer 安裝與使用
- • Kotlin學習（二）基本類型
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Xen安裝部署和基本原理
- 2. Xen安裝部署
- 3. Xen基本原理
- 4. kafka安裝部署和基本指令
- 5. Kerberos基本原理、安裝部署及用法
- 6. 簡要分析ZooKeeper基本原理及安裝部署
- 7. 16120九、簡要分析ZooKeeper基本原理及安裝部署
- 8. Xen虛擬化基本原理詳解
- 9. Mysql原理，安裝和基本使用
- 10. WAF基本原理與部署方式