XEN的漫漫人生路
前沿：我沒考究這文章出的時候，所以可能信息有的已經(jīng)更新，但不失為一篇不錯的框架讀物。
在 Linus 明確表示 Linux Kernel 3.0 只是一個版本號的改變，而非里程碑式的飛躍后，許多人對此表達(dá)了失望，一個沒有重量級功能的新版本似乎配不上這個新的版本號。不過對有些人來說，其中的一個新功能或許可以擔(dān)的上這個重任，那就是 Xen 的 block backend driver。這個功能加上之前在 2.6.37，2.6.38，2.6.39 添加的幾個 Xen 相關(guān)的功能，使得即將發(fā)布的 Kernel 3.0 包含了所有成為 Xen 的 Domain0 所必須的功能，從此為 Xen 漫長的 Kernel 之路劃上了一個句號，也標(biāo)志著 Xen 的發(fā)展掀開了嶄新的一頁。VMWare，Binary Translation 以及 Full Virtualization提起虛擬化，一個不得不提的公司或者產(chǎn)品是 VMWare，如果說虛擬化最早的原型可以追溯到上世紀(jì) 70 年代的 IBM 的 VM 的話，那么當(dāng)前的虛擬化熱潮卻是由 VMWare 引領(lǐng)的。相信有很多人跟我一樣，對虛擬化的認(rèn)知是通過 VMWare 得到的。當(dāng)我初次接觸 VMWare 時，我非常驚訝，居然有這樣的產(chǎn)品實(shí)現(xiàn)了這么 nice 的功能。VMWare 的成功除了契合了時代的變遷所催生出的虛擬化需求外，也得益于自身產(chǎn)品的優(yōu)秀。VMWare 產(chǎn)品的簡單，便捷，易于理解當(dāng)然是其中非常重要的一個優(yōu)勢，但更重要的原因來自于 VMWare 創(chuàng)造性的解決了 x86 平臺內(nèi)在不支持虛擬化的難題。x86 平臺難以虛擬化的本質(zhì)主要來自于 CPU 的虛擬化。眾所周知，x86 處理器的指令有 4 個特權(quán)等級，分別是 Ring 0 ~ 3。正常情況下，application 工作在最低特權(quán)級，即 Ring 3，而 kernel 工作在最高特權(quán)級，也就是 Ring 0，因?yàn)橛性S多硬件操作必須要在該級別下才能完成。在虛擬化的情況下，也就是有多個 OS 同時運(yùn)行的情況下，顯然這多個 OS 不能同時運(yùn)行于 Ring 0，因?yàn)?OS 需要運(yùn)行的某些 Ring 0 特權(quán)指令將互相干擾。因此一般的解決方案是將虛擬化軟件（通常稱作 Virtual Machine Monitor，或 hypervisor）放在 Ring 0，而將運(yùn)行在虛擬機(jī)里的 guest OS 放到 Ring 1 或 Ring 3 中。一個正常的硬件設(shè)計是，當(dāng)這些原本應(yīng)該運(yùn)行在 Ring 0 級別的指令在非 Ring 0 的級別里被執(zhí)行時，處理器報錯，這樣運(yùn)行在 Ring 0 的 hypervisor 就能捕獲該錯誤，從而做相應(yīng)的處理（比如模擬或替換該指令）實(shí)現(xiàn)虛擬化，然而 x86 處理器有一些特權(quán)指令在 Ring 0 及非 Ring 0 下都能執(zhí)行， 并且有不同的含義，這就使得運(yùn)行在 Ring 0 級別里的 hypervisor 無法捕獲該指令，而該指令的運(yùn)行也于原本的意義不同。對此 VMWare 的解決方案是 Binary Translation，也就是 hypervisor 提前掃描 guest OS 待運(yùn)行的指令，發(fā)現(xiàn)有這種無法捕獲或無法虛擬化的特權(quán)指令時，將其替換成相應(yīng)的一系列可捕獲的指令，從而實(shí)現(xiàn) guest OS 的虛擬化。當(dāng)然除了 CPU 的虛擬化外，內(nèi)存，I/O 設(shè)備的虛擬化也不那么容易，不過是 CPU 虛擬化方式的不同決定了各解決方案的不同。VMWare 的這種解決方式最大的優(yōu)點(diǎn)是 guest OS 無需修改就可以運(yùn)行在 VMWare 的虛擬機(jī)上，當(dāng)然這個優(yōu)點(diǎn)是相對于后來出現(xiàn)的 Xen 而言的，這種虛擬化方式也稱作 Full Virtualization。VMWare 的 Full Virtualization 解決方案一個致命的缺點(diǎn)是性能上的瓶頸，因?yàn)?hypervisor 要在運(yùn)行時掃描指令，分析并替換，這個消耗是客觀無法去掉的。當(dāng)然 VMWare 采取了很多方法來彌補(bǔ)這些缺陷，使得虛擬機(jī)的運(yùn)行不至于慢的難以忍受，造成的結(jié)果就是實(shí)現(xiàn)相當(dāng)復(fù)雜。因此在 VMWare 掀起了虛擬化的浪潮之后，許多想投入到這個領(lǐng)域中去的人開始想辦法從其它角度來解決 x86 難以虛擬化的難題。Xen 的出現(xiàn)以及 ParavirtualizationXen 的開發(fā)人員就想出了一個巧妙的辦法。Xen 最初始于劍橋大學(xué)的一個研究項(xiàng)目，他們的出發(fā)點(diǎn)是既然 x86 系統(tǒng)難以虛擬化，那么我就假定 guest OS 運(yùn)行在一個類似 x86 的平臺上，該平臺由 Xen 來提供。具體點(diǎn)說就是 Xen 實(shí)現(xiàn)了一個類似微內(nèi)核這樣的系統(tǒng)，該系統(tǒng)運(yùn)行在物理硬件平臺上（Ring 0 級別），而 guest OS 運(yùn)行在 Xen 上（Ring 1 級別），于 VMWare 不同的是，運(yùn)行在 Xen 上的 guest OS 需要修改，因?yàn)?Xen 提供或虛擬的硬件環(huán)境已不再是 x86 平臺，而是一個類 x86 平臺，當(dāng)然再上面的 application 不需要修改。這種虛擬化的方式稱作 Paravirtualization。這就意味著，guest 原本需要運(yùn)行某些 Ring 0 級別的特權(quán)指令才能完成的任務(wù)，現(xiàn)在要修改為調(diào)用 Xen 提供的相應(yīng)的指令（稱作 hypercall，從實(shí)現(xiàn)方式來說類似于 system call）。顯然開源的易于修改的 Linux 是最好的目標(biāo)，這也是早期的 Xen 無法支持 Windows 系統(tǒng)的原因。然而 Xen 的架構(gòu)還遠(yuǎn)不止與此，由于 Xen 運(yùn)行在物理硬件與客戶機(jī)操作系統(tǒng)之間，因此 Xen 的重要性不言而喻，稍有差錯就可能導(dǎo)致所有的客戶機(jī)崩潰，因此要求 Xen 的代碼盡量簡練，實(shí)際上是越少越好，而一個完整的 guest 運(yùn)行所需要虛擬的硬件除了 CPU 外還有很多，例如內(nèi)存，I/O 設(shè)備等等。顯然如果 Xen 即支持底下的硬件設(shè)備，又要虛擬上面需要的硬件設(shè)備，那么 Xen 的實(shí)現(xiàn)無異于重寫一個 Linux。Xen 的想法是 Xen 只支持最基本的硬件設(shè)備，也就是 CPU，內(nèi)存，中斷等，其它 I/O 設(shè)備由一個專門的 guest OS 來支持，而其余的 guest OS 要想訪問該設(shè)備，需要通過 Xen，然后再傳遞到該特殊的 guest。Xen 為此將 guest 分為兩個級別，一個是有訪問 I/O 設(shè)備特權(quán)的特殊的 guest，稱作 Domain0，其它的稱作 DomainU。因此對 Linux 來說，要想運(yùn)行在 Xen 上，就必須要修改 Kernel 代碼，并且根據(jù) Linux 是運(yùn)行在 Domain0 級別還是 DomainU 級別而修改的代碼也不同。早期的 Xen 采用 Linux Kernel 2.6.18 作為基礎(chǔ)，進(jìn)行修改并實(shí)現(xiàn)了 Domain0 以及 DomainU 的功能。由于 Xen 提供的虛擬化解決方式的性能優(yōu)勢，以及 Xen 的開源的特性，Xen 很快就被炒上了天。當(dāng)初成立該研究項(xiàng)目的大學(xué)教授成立了公司，并獲得了風(fēng)投的青睞，繼而被 Citrix 收購；各大發(fā)行版紛紛搶著支持 Xen 作為自己的虛擬化方案；很多創(chuàng)業(yè)公司也一夜之間冒了出來，研究 Xen 或者利用 Xen，以期望在未來的虛擬化與云計算大潮中能博得一位；Xen 儼然成了虛擬化的未來。硬件虛擬化技術(shù)的進(jìn)步以及 KVM然而技術(shù)的發(fā)展往往非人所料，由于虛擬化浪潮的熱火朝天，以及 x86 平臺難以虛擬化的本質(zhì)，使得 Intel 與 AMD 這兩大芯片商開始思考如何在處理器里添加功能克服原有的缺陷。于是在 2006 年，Intel VT-x 與 AMD-V 出現(xiàn)了。簡單的說這兩個 CPU 擴(kuò)展就是在保持四個 Ring 特權(quán)級別的條件下，分出兩個 forms，分別給客戶機(jī)與 hypervisor 使用，由于每個 form 都有這四個 Ring 級別，因此客戶機(jī)的特權(quán)指令的捕獲就可以輕松實(shí)現(xiàn)了。硬件技術(shù)的出現(xiàn)很快就帶動了軟件技術(shù)的發(fā)展，很快有利用這種硬件虛擬化技術(shù)的軟件出現(xiàn)了，沒錯，就是 KVM。比起 Xen 來，KVM 的實(shí)現(xiàn)更加簡潔而優(yōu)雅，除了利用硬件的支持，KVM 還利用了現(xiàn)有的 Linux Kernel 的 CPU 調(diào)度等機(jī)制，因此 KVM 不需要像 Xen 那樣重新實(shí)現(xiàn)一個復(fù)雜的 guest OS 的調(diào)度機(jī)制，這個任務(wù)交給 Linux Kernel 來完成，此時 guest OS 對 Linux Kernel 所在的 host 來說就是一個進(jìn)程。此外 KVM 的實(shí)現(xiàn)方式也不需要修改 guest OS，因此 KVM 的出現(xiàn)很快引起了 Kernel 社區(qū)開發(fā)人員的興趣，幾乎是在最短的時間內(nèi)，KVM 就進(jìn)入了 Kernel，此時 Xen 仍然按照自己的開發(fā)模式在按部就班的進(jìn)行著。Xen 的問題相對 KVM 來說，Xen 是一個龐大的項(xiàng)目，一個完整的 Xen 的搭建，需要四個組成部分，首先是最底層的 hypervisor，其次是需要修改的 Domain0 與 DomainU Kernel，最后是上層的應(yīng)用管理進(jìn)程。可以看出，hypervisor 與 管理進(jìn)程是獨(dú)立的，可以輕易安裝，然而 Domain0 與 DomainU 卻需要修改后的 Kernel 支持。早期 的 Xen 的源代碼庫里有一個修改后的 2.6.18，可以下載，編譯然后安裝。這個辦法并不是長久之計，Linux Kernel 的發(fā)展是很快的，一勞永逸的辦法是盡快將 Xen 對 Kernel 的修改 merge 到上游 Kernel 中去。然而 Xen 的開發(fā)人員似乎并不熱衷于 merge 對 Kernel 的修改。帶來的問題是，對發(fā)行版來說，他們不得不花大量的精力來維護(hù) Xen 相關(guān)的 Kernel patch，這個問題在 RHEL 5 上達(dá)到了登峰造極式的表現(xiàn)，RHEL 5 的 Kernel SRPM 里與 Xen 相關(guān)的 patch 有上百個。此外一些早期投入到 Xen 中去的小公司在快速開始后，發(fā)現(xiàn)他們不得不面對一些 tricky 的問題，而且很難判斷是 Xen hypervisor 的問題還是 Dom0 或 DomU kernel 的問題，或者有時候在 backport 一些最新的 Kernel bug 修復(fù)到 Dom0/DomU 時困難重重。Xen 成了這些人的夢魘。其實(shí) Xen 的開發(fā)人員也不是沒想過將 Kernel 的修改 merge 到上游去，然而如上面所說，Xen 對 Kernel 的修改是通過類似將 Linux 移植到一個新平臺（x86 的一個子平臺）的方式進(jìn)行的，其中有大量的對 x86 平臺代碼的修改與復(fù)制，對此 Kernel 開發(fā)人員非常抵觸。再加上 Xen 的開發(fā)人員并不熱衷于此，Xen 進(jìn)入 Kernel 之路面臨著一個個障礙，而且一拖就是幾年。在 KVM 逐漸開始成熟起來，而 Xen 又遲遲無法進(jìn)入 Kernel 之際，Red Hat 做出了一個艱難的決定，拋棄 Xen，轉(zhuǎn)投 KVM，并收購了最初開發(fā) KVM 的公司。Red Hat 的決定帶來了巨大的影響，不少發(fā)行版都拋棄了 Xen，很多人開始預(yù)言 Xen 即將滅亡，關(guān)于 Xen 與 KVM 之爭也隨處可見，Red Hat 與 始終支持 Xen 的 Novell 就兩者的優(yōu)劣還吵了一架。同時隨著 KVM 的成熟，Xen 進(jìn)入 Kernel 的阻力更大，許多 Kernel 開發(fā)人員認(rèn)為沒有必要在 Kernel 里同時支持兩個虛擬化框架，有 KVM 就足夠了。而有關(guān)推動 Xen 修改進(jìn)入 Kernel 的努力再次失敗，Linus 明確表示，Xen 的代碼從開發(fā)角度來說就是一個混亂，這樣的代碼進(jìn)入 Kernel 只會給 Kernel 開發(fā)人員帶來維護(hù)上的災(zāi)難，除非 Xen 的開發(fā)人員按照 Kernel 的開發(fā)規(guī)范重寫 Kernel 相關(guān)的功能，否則 Xen 的修改不可能進(jìn)入 Kernel。漫漫人生路在 Linus ?明確對 Xen 的問題表態(tài)后，Xen 的開發(fā)人員開始了漫漫的 Kernel 人生路。此前在 pv_ops 出現(xiàn)后，Xen 的 DomU 部分已經(jīng)進(jìn)入了 Kernel，唯有剩下的 Dom0 部分。Xen 的開發(fā)人員開始一點(diǎn)一點(diǎn)的重寫，提交，被打回，再重新修改提交，經(jīng)過了兩年時間的積累，Xen 對 Kernel 的修改終于在去年 2.6.37 時有了一個質(zhì)的變化，2.6.37 包含了核心的 Dom0 支持，當(dāng)然這還不夠，Dom0 還需要一些 backend driver 來支持從 DomU 過來的設(shè)備訪問請求，不過這些相對來說已不那么困難，輕舟已過萬重山。Xen vs KVM與此同時，在 Red Hat 加入 KVM 后，KVM 的發(fā)展也在日新月異。KVM 雖然利用了 CPU 的虛擬化功能，但對外圍設(shè)備尤其是硬盤與網(wǎng)卡的虛擬還是通過 QEMU，這樣的 Full Virtualization，效率并不高。為了提高效率，就要像 Xen 那樣采用 Paravirtualization 的方式，即 guest 的 Kernel 知道自己訪問的硬盤/網(wǎng)卡并不是真正的硬件設(shè)備，很快 Kernel 內(nèi)部有了 VirtIO 的框架。硬件的發(fā)展同樣迅速，在第一代虛擬化技術(shù)催生了 KVM 這樣的軟件后，第二代的虛擬化技術(shù)致力于在性能上的提高，比如 Intel 的 EPT 以及 VT-d，AMD 的 RVI 以及 IO-MMU。在這些技術(shù)被 KVM 采用后（當(dāng)然也被 Xen 采用），Xen 是否還具有天然的性能上的優(yōu)勢就真不好說了。相反，由于 Xen 的 Dom0 支持遲遲無法進(jìn)入 Kernel，使得很多人在選擇虛擬化技術(shù)時不得不三思。天平已然傾向了 KVM。最后到底 Xen 與 KVM 孰優(yōu)孰劣，尤其是性能，不是一個輕易就可以下結(jié)論的問題。性能上的比試除了產(chǎn)品的架構(gòu)外，更多依賴于任務(wù)本身是 CPU bound 還是 I/O bound，以及在測試過程中對搭建平臺的一步步調(diào)整。不管怎么說，Xen 依然有存在的價值，Xen 也有大量的用戶群。Xen 的 Kernel 部分正式進(jìn)入 Linux Kernel 是一件值得高興的事情，相信很多發(fā)行版將重新開始支持 Xen，至少在虛擬化技術(shù)前，我們又有了一個方便的選擇。對于 Xen 來說，這也意味著它與 KVM 的競爭又站到了同一起跑線上。縱觀 Xen 這短短幾年的發(fā)展，既有巔峰時的人人追捧，也有沒落時的失意。除了虛擬化大環(huán)境技術(shù)上的變遷外，更主要的原因在于 Xen 的開發(fā)策略沒有堅持通常所說的上游優(yōu)先（upstream first），也就是在代碼還沒有進(jìn)入上游的 Kernel 之前，就發(fā)布出去，從而為日后的彎路打下了基礎(chǔ)。這樣的教訓(xùn)令人足戒。Xen 的 Dom0 雖然進(jìn)入了 Kernel，但 Xen 的故事并未結(jié)束，Xen 仍然有一些代碼需要進(jìn)入 Kernel，Xen 本身對硬件虛擬化技術(shù)的利用也有待提高，不管怎么說，Xen 又重新回到了人們的視野，至于 Xen 是否還能回到巔峰，只能拭目以待了。資源嚴(yán)格來說，本文的很多術(shù)語并不完全準(zhǔn)確，所以，如果您有興趣，您可以延伸閱讀：1. 我愛 Wikipedia: Virtualization, Hardware Virtualization, x86 ? ? ? ? ? ? ?Virtualization, Full Virtualization, Paravirtualization, VMWare, Xen, ? ? ?KVM。?2. Intel 的網(wǎng)站上有許多非常棒的關(guān)于 Virtualization 的文章，比如這一篇。?3. VMWare 的網(wǎng)站上有許多非常棒的關(guān)于 Virtualization 的文章，比如這一篇。4. Xen 的著名的論文以及架構(gòu)介紹。?5. KernelTrap 對 KVM 的主要開發(fā)者的專訪。?6. LWN 上 Virtualization 相關(guān)的文章 Xen: finishing the job, Xen again。
在 Linus 明確表示 Linux Kernel 3.0 只是一個版本號的改變，而非里程碑式的飛躍后，許多人對此表達(dá)了失望，一個沒有重量級功能的新版本似乎配不上這個新的版本號。不過對有些人來說，其中的一個新功能或許可以擔(dān)的上這個重任，那就是 Xen 的 block backend driver。這個功能加上之前在 2.6.37，2.6.38，2.6.39 添加的幾個 Xen 相關(guān)的功能，使得即將發(fā)布的 Kernel 3.0 包含了所有成為 Xen 的 Domain0 所必須的功能，從此為 Xen 漫長的 Kernel 之路劃上了一個句號，也標(biāo)志著 Xen 的發(fā)展掀開了嶄新的一頁。VMWare，Binary Translation 以及 Full Virtualization提起虛擬化，一個不得不提的公司或者產(chǎn)品是 VMWare，如果說虛擬化最早的原型可以追溯到上世紀(jì) 70 年代的 IBM 的 VM 的話，那么當(dāng)前的虛擬化熱潮卻是由 VMWare 引領(lǐng)的。相信有很多人跟我一樣，對虛擬化的認(rèn)知是通過 VMWare 得到的。當(dāng)我初次接觸 VMWare 時，我非常驚訝，居然有這樣的產(chǎn)品實(shí)現(xiàn)了這么 nice 的功能。VMWare 的成功除了契合了時代的變遷所催生出的虛擬化需求外，也得益于自身產(chǎn)品的優(yōu)秀。VMWare 產(chǎn)品的簡單，便捷，易于理解當(dāng)然是其中非常重要的一個優(yōu)勢，但更重要的原因來自于 VMWare 創(chuàng)造性的解決了 x86 平臺內(nèi)在不支持虛擬化的難題。x86 平臺難以虛擬化的本質(zhì)主要來自于 CPU 的虛擬化。眾所周知，x86 處理器的指令有 4 個特權(quán)等級，分別是 Ring 0 ~ 3。正常情況下，application 工作在最低特權(quán)級，即 Ring 3，而 kernel 工作在最高特權(quán)級，也就是 Ring 0，因?yàn)橛性S多硬件操作必須要在該級別下才能完成。在虛擬化的情況下，也就是有多個 OS 同時運(yùn)行的情況下，顯然這多個 OS 不能同時運(yùn)行于 Ring 0，因?yàn)?OS 需要運(yùn)行的某些 Ring 0 特權(quán)指令將互相干擾。因此一般的解決方案是將虛擬化軟件（通常稱作 Virtual Machine Monitor，或 hypervisor）放在 Ring 0，而將運(yùn)行在虛擬機(jī)里的 guest OS 放到 Ring 1 或 Ring 3 中。一個正常的硬件設(shè)計是，當(dāng)這些原本應(yīng)該運(yùn)行在 Ring 0 級別的指令在非 Ring 0 的級別里被執(zhí)行時，處理器報錯，這樣運(yùn)行在 Ring 0 的 hypervisor 就能捕獲該錯誤，從而做相應(yīng)的處理（比如模擬或替換該指令）實(shí)現(xiàn)虛擬化，然而 x86 處理器有一些特權(quán)指令在 Ring 0 及非 Ring 0 下都能執(zhí)行， 并且有不同的含義，這就使得運(yùn)行在 Ring 0 級別里的 hypervisor 無法捕獲該指令，而該指令的運(yùn)行也于原本的意義不同。對此 VMWare 的解決方案是 Binary Translation，也就是 hypervisor 提前掃描 guest OS 待運(yùn)行的指令，發(fā)現(xiàn)有這種無法捕獲或無法虛擬化的特權(quán)指令時，將其替換成相應(yīng)的一系列可捕獲的指令，從而實(shí)現(xiàn) guest OS 的虛擬化。當(dāng)然除了 CPU 的虛擬化外，內(nèi)存，I/O 設(shè)備的虛擬化也不那么容易，不過是 CPU 虛擬化方式的不同決定了各解決方案的不同。VMWare 的這種解決方式最大的優(yōu)點(diǎn)是 guest OS 無需修改就可以運(yùn)行在 VMWare 的虛擬機(jī)上，當(dāng)然這個優(yōu)點(diǎn)是相對于后來出現(xiàn)的 Xen 而言的，這種虛擬化方式也稱作 Full Virtualization。VMWare 的 Full Virtualization 解決方案一個致命的缺點(diǎn)是性能上的瓶頸，因?yàn)?hypervisor 要在運(yùn)行時掃描指令，分析并替換，這個消耗是客觀無法去掉的。當(dāng)然 VMWare 采取了很多方法來彌補(bǔ)這些缺陷，使得虛擬機(jī)的運(yùn)行不至于慢的難以忍受，造成的結(jié)果就是實(shí)現(xiàn)相當(dāng)復(fù)雜。因此在 VMWare 掀起了虛擬化的浪潮之后，許多想投入到這個領(lǐng)域中去的人開始想辦法從其它角度來解決 x86 難以虛擬化的難題。Xen 的出現(xiàn)以及 ParavirtualizationXen 的開發(fā)人員就想出了一個巧妙的辦法。Xen 最初始于劍橋大學(xué)的一個研究項(xiàng)目，他們的出發(fā)點(diǎn)是既然 x86 系統(tǒng)難以虛擬化，那么我就假定 guest OS 運(yùn)行在一個類似 x86 的平臺上，該平臺由 Xen 來提供。具體點(diǎn)說就是 Xen 實(shí)現(xiàn)了一個類似微內(nèi)核這樣的系統(tǒng)，該系統(tǒng)運(yùn)行在物理硬件平臺上（Ring 0 級別），而 guest OS 運(yùn)行在 Xen 上（Ring 1 級別），于 VMWare 不同的是，運(yùn)行在 Xen 上的 guest OS 需要修改，因?yàn)?Xen 提供或虛擬的硬件環(huán)境已不再是 x86 平臺，而是一個類 x86 平臺，當(dāng)然再上面的 application 不需要修改。這種虛擬化的方式稱作 Paravirtualization。這就意味著，guest 原本需要運(yùn)行某些 Ring 0 級別的特權(quán)指令才能完成的任務(wù)，現(xiàn)在要修改為調(diào)用 Xen 提供的相應(yīng)的指令（稱作 hypercall，從實(shí)現(xiàn)方式來說類似于 system call）。顯然開源的易于修改的 Linux 是最好的目標(biāo)，這也是早期的 Xen 無法支持 Windows 系統(tǒng)的原因。然而 Xen 的架構(gòu)還遠(yuǎn)不止與此，由于 Xen 運(yùn)行在物理硬件與客戶機(jī)操作系統(tǒng)之間，因此 Xen 的重要性不言而喻，稍有差錯就可能導(dǎo)致所有的客戶機(jī)崩潰，因此要求 Xen 的代碼盡量簡練，實(shí)際上是越少越好，而一個完整的 guest 運(yùn)行所需要虛擬的硬件除了 CPU 外還有很多，例如內(nèi)存，I/O 設(shè)備等等。顯然如果 Xen 即支持底下的硬件設(shè)備，又要虛擬上面需要的硬件設(shè)備，那么 Xen 的實(shí)現(xiàn)無異于重寫一個 Linux。Xen 的想法是 Xen 只支持最基本的硬件設(shè)備，也就是 CPU，內(nèi)存，中斷等，其它 I/O 設(shè)備由一個專門的 guest OS 來支持，而其余的 guest OS 要想訪問該設(shè)備，需要通過 Xen，然后再傳遞到該特殊的 guest。Xen 為此將 guest 分為兩個級別，一個是有訪問 I/O 設(shè)備特權(quán)的特殊的 guest，稱作 Domain0，其它的稱作 DomainU。因此對 Linux 來說，要想運(yùn)行在 Xen 上，就必須要修改 Kernel 代碼，并且根據(jù) Linux 是運(yùn)行在 Domain0 級別還是 DomainU 級別而修改的代碼也不同。早期的 Xen 采用 Linux Kernel 2.6.18 作為基礎(chǔ)，進(jìn)行修改并實(shí)現(xiàn)了 Domain0 以及 DomainU 的功能。由于 Xen 提供的虛擬化解決方式的性能優(yōu)勢，以及 Xen 的開源的特性，Xen 很快就被炒上了天。當(dāng)初成立該研究項(xiàng)目的大學(xué)教授成立了公司，并獲得了風(fēng)投的青睞，繼而被 Citrix 收購；各大發(fā)行版紛紛搶著支持 Xen 作為自己的虛擬化方案；很多創(chuàng)業(yè)公司也一夜之間冒了出來，研究 Xen 或者利用 Xen，以期望在未來的虛擬化與云計算大潮中能博得一位；Xen 儼然成了虛擬化的未來。硬件虛擬化技術(shù)的進(jìn)步以及 KVM然而技術(shù)的發(fā)展往往非人所料，由于虛擬化浪潮的熱火朝天，以及 x86 平臺難以虛擬化的本質(zhì)，使得 Intel 與 AMD 這兩大芯片商開始思考如何在處理器里添加功能克服原有的缺陷。于是在 2006 年，Intel VT-x 與 AMD-V 出現(xiàn)了。簡單的說這兩個 CPU 擴(kuò)展就是在保持四個 Ring 特權(quán)級別的條件下，分出兩個 forms，分別給客戶機(jī)與 hypervisor 使用，由于每個 form 都有這四個 Ring 級別，因此客戶機(jī)的特權(quán)指令的捕獲就可以輕松實(shí)現(xiàn)了。硬件技術(shù)的出現(xiàn)很快就帶動了軟件技術(shù)的發(fā)展，很快有利用這種硬件虛擬化技術(shù)的軟件出現(xiàn)了，沒錯，就是 KVM。比起 Xen 來，KVM 的實(shí)現(xiàn)更加簡潔而優(yōu)雅，除了利用硬件的支持，KVM 還利用了現(xiàn)有的 Linux Kernel 的 CPU 調(diào)度等機(jī)制，因此 KVM 不需要像 Xen 那樣重新實(shí)現(xiàn)一個復(fù)雜的 guest OS 的調(diào)度機(jī)制，這個任務(wù)交給 Linux Kernel 來完成，此時 guest OS 對 Linux Kernel 所在的 host 來說就是一個進(jìn)程。此外 KVM 的實(shí)現(xiàn)方式也不需要修改 guest OS，因此 KVM 的出現(xiàn)很快引起了 Kernel 社區(qū)開發(fā)人員的興趣，幾乎是在最短的時間內(nèi)，KVM 就進(jìn)入了 Kernel，此時 Xen 仍然按照自己的開發(fā)模式在按部就班的進(jìn)行著。Xen 的問題相對 KVM 來說，Xen 是一個龐大的項(xiàng)目，一個完整的 Xen 的搭建，需要四個組成部分，首先是最底層的 hypervisor，其次是需要修改的 Domain0 與 DomainU Kernel，最后是上層的應(yīng)用管理進(jìn)程。可以看出，hypervisor 與 管理進(jìn)程是獨(dú)立的，可以輕易安裝，然而 Domain0 與 DomainU 卻需要修改后的 Kernel 支持。早期 的 Xen 的源代碼庫里有一個修改后的 2.6.18，可以下載，編譯然后安裝。這個辦法并不是長久之計，Linux Kernel 的發(fā)展是很快的，一勞永逸的辦法是盡快將 Xen 對 Kernel 的修改 merge 到上游 Kernel 中去。然而 Xen 的開發(fā)人員似乎并不熱衷于 merge 對 Kernel 的修改。帶來的問題是，對發(fā)行版來說，他們不得不花大量的精力來維護(hù) Xen 相關(guān)的 Kernel patch，這個問題在 RHEL 5 上達(dá)到了登峰造極式的表現(xiàn)，RHEL 5 的 Kernel SRPM 里與 Xen 相關(guān)的 patch 有上百個。此外一些早期投入到 Xen 中去的小公司在快速開始后，發(fā)現(xiàn)他們不得不面對一些 tricky 的問題，而且很難判斷是 Xen hypervisor 的問題還是 Dom0 或 DomU kernel 的問題，或者有時候在 backport 一些最新的 Kernel bug 修復(fù)到 Dom0/DomU 時困難重重。Xen 成了這些人的夢魘。其實(shí) Xen 的開發(fā)人員也不是沒想過將 Kernel 的修改 merge 到上游去，然而如上面所說，Xen 對 Kernel 的修改是通過類似將 Linux 移植到一個新平臺（x86 的一個子平臺）的方式進(jìn)行的，其中有大量的對 x86 平臺代碼的修改與復(fù)制，對此 Kernel 開發(fā)人員非常抵觸。再加上 Xen 的開發(fā)人員并不熱衷于此，Xen 進(jìn)入 Kernel 之路面臨著一個個障礙，而且一拖就是幾年。在 KVM 逐漸開始成熟起來，而 Xen 又遲遲無法進(jìn)入 Kernel 之際，Red Hat 做出了一個艱難的決定，拋棄 Xen，轉(zhuǎn)投 KVM，并收購了最初開發(fā) KVM 的公司。Red Hat 的決定帶來了巨大的影響，不少發(fā)行版都拋棄了 Xen，很多人開始預(yù)言 Xen 即將滅亡，關(guān)于 Xen 與 KVM 之爭也隨處可見，Red Hat 與 始終支持 Xen 的 Novell 就兩者的優(yōu)劣還吵了一架。同時隨著 KVM 的成熟，Xen 進(jìn)入 Kernel 的阻力更大，許多 Kernel 開發(fā)人員認(rèn)為沒有必要在 Kernel 里同時支持兩個虛擬化框架，有 KVM 就足夠了。而有關(guān)推動 Xen 修改進(jìn)入 Kernel 的努力再次失敗，Linus 明確表示，Xen 的代碼從開發(fā)角度來說就是一個混亂，這樣的代碼進(jìn)入 Kernel 只會給 Kernel 開發(fā)人員帶來維護(hù)上的災(zāi)難，除非 Xen 的開發(fā)人員按照 Kernel 的開發(fā)規(guī)范重寫 Kernel 相關(guān)的功能，否則 Xen 的修改不可能進(jìn)入 Kernel。漫漫人生路在 Linus ?明確對 Xen 的問題表態(tài)后，Xen 的開發(fā)人員開始了漫漫的 Kernel 人生路。此前在 pv_ops 出現(xiàn)后，Xen 的 DomU 部分已經(jīng)進(jìn)入了 Kernel，唯有剩下的 Dom0 部分。Xen 的開發(fā)人員開始一點(diǎn)一點(diǎn)的重寫，提交，被打回，再重新修改提交，經(jīng)過了兩年時間的積累，Xen 對 Kernel 的修改終于在去年 2.6.37 時有了一個質(zhì)的變化，2.6.37 包含了核心的 Dom0 支持，當(dāng)然這還不夠，Dom0 還需要一些 backend driver 來支持從 DomU 過來的設(shè)備訪問請求，不過這些相對來說已不那么困難，輕舟已過萬重山。Xen vs KVM與此同時，在 Red Hat 加入 KVM 后，KVM 的發(fā)展也在日新月異。KVM 雖然利用了 CPU 的虛擬化功能，但對外圍設(shè)備尤其是硬盤與網(wǎng)卡的虛擬還是通過 QEMU，這樣的 Full Virtualization，效率并不高。為了提高效率，就要像 Xen 那樣采用 Paravirtualization 的方式，即 guest 的 Kernel 知道自己訪問的硬盤/網(wǎng)卡并不是真正的硬件設(shè)備，很快 Kernel 內(nèi)部有了 VirtIO 的框架。硬件的發(fā)展同樣迅速，在第一代虛擬化技術(shù)催生了 KVM 這樣的軟件后，第二代的虛擬化技術(shù)致力于在性能上的提高，比如 Intel 的 EPT 以及 VT-d，AMD 的 RVI 以及 IO-MMU。在這些技術(shù)被 KVM 采用后（當(dāng)然也被 Xen 采用），Xen 是否還具有天然的性能上的優(yōu)勢就真不好說了。相反，由于 Xen 的 Dom0 支持遲遲無法進(jìn)入 Kernel，使得很多人在選擇虛擬化技術(shù)時不得不三思。天平已然傾向了 KVM。最后到底 Xen 與 KVM 孰優(yōu)孰劣，尤其是性能，不是一個輕易就可以下結(jié)論的問題。性能上的比試除了產(chǎn)品的架構(gòu)外，更多依賴于任務(wù)本身是 CPU bound 還是 I/O bound，以及在測試過程中對搭建平臺的一步步調(diào)整。不管怎么說，Xen 依然有存在的價值，Xen 也有大量的用戶群。Xen 的 Kernel 部分正式進(jìn)入 Linux Kernel 是一件值得高興的事情，相信很多發(fā)行版將重新開始支持 Xen，至少在虛擬化技術(shù)前，我們又有了一個方便的選擇。對于 Xen 來說，這也意味著它與 KVM 的競爭又站到了同一起跑線上。縱觀 Xen 這短短幾年的發(fā)展，既有巔峰時的人人追捧，也有沒落時的失意。除了虛擬化大環(huán)境技術(shù)上的變遷外，更主要的原因在于 Xen 的開發(fā)策略沒有堅持通常所說的上游優(yōu)先（upstream first），也就是在代碼還沒有進(jìn)入上游的 Kernel 之前，就發(fā)布出去，從而為日后的彎路打下了基礎(chǔ)。這樣的教訓(xùn)令人足戒。Xen 的 Dom0 雖然進(jìn)入了 Kernel，但 Xen 的故事并未結(jié)束，Xen 仍然有一些代碼需要進(jìn)入 Kernel，Xen 本身對硬件虛擬化技術(shù)的利用也有待提高，不管怎么說，Xen 又重新回到了人們的視野，至于 Xen 是否還能回到巔峰，只能拭目以待了。資源嚴(yán)格來說，本文的很多術(shù)語并不完全準(zhǔn)確，所以，如果您有興趣，您可以延伸閱讀：1. 我愛 Wikipedia: Virtualization, Hardware Virtualization, x86 ? ? ? ? ? ? ?Virtualization, Full Virtualization, Paravirtualization, VMWare, Xen, ? ? ?KVM。?2. Intel 的網(wǎng)站上有許多非常棒的關(guān)于 Virtualization 的文章，比如這一篇。?3. VMWare 的網(wǎng)站上有許多非常棒的關(guān)于 Virtualization 的文章，比如這一篇。4. Xen 的著名的論文以及架構(gòu)介紹。?5. KernelTrap 對 KVM 的主要開發(fā)者的專訪。?6. LWN 上 Virtualization 相關(guān)的文章 Xen: finishing the job, Xen again。
轉(zhuǎn)載于:https://blog.51cto.com/yunxiaowei/1042954
總結(jié)
- 上一篇： double free or corru
- 下一篇： extern “C”