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