背景

Xen Project，曾經作為唯一的開源虛擬化項目，一直活躍了10幾年，但是隨著可能是最大的Xen使用者AWS正式宣布下一代C5實例將使用KVM, 這基本也算是正式宣布了Xen的正式落幕。其實，國內的阿里雲、華為雲、作為比較早的雲服務提供商，也都大量的使用了Xen, 大概在3、4年前，大家就紛紛開始動手將Xen替換成KVM。目前在國內，它們新的雲伺服器都已經是KVM虛擬化了，AWS的歷史包袱更大，要徹底完成Xen向KVM的替換，估計還需要很長一段時間。

為什麼Xen會死掉？

我記得大概是從Citrix收購Xen不久，RedHat就正式宣布放棄Xen採用KVM。隨後， Intel也全面支持 KVM，很多新技術比如著名的DPDK根本就不支持Xen，即使拋開複雜的商業生態，簡單的從技術上看，Xen的架構在Intel推出vt硬體虛擬化技術后，確實顯得非常複雜，主要表現在以下兩點：

Domain0 這是Xen在初期引入的一個特權Dom，Xen Hypervisor在收到IO請求后，需要先把請求投遞到Domain0，完成調度處理后，通過grant copy或者grant map轉發到對應的虛擬機，相比KVM, 整個IO處理路徑幾乎被拉長了一倍。其次, x86_64的ring模型相比早期的x86_32也發生了較大變換，從而導致ring壓縮，進一步惡化了中斷處理的性能。

必須重複造輪子：

最新10年來，CPU已經從單核逐步走向了雙核、四核、甚至是幾十核心。NUMA技術，TB級內存也基本成為現代伺服器的標配，眾多廠商和Linux社區在內存和CPU調度和管理上做了大量的工作，而Xen Hypervisor採用獨立的CPU和內存調度管理、核心實現還停留在Linux 2.4時代。經過了10年的發展后，根本無力去同步這麼多的更新，我們今天會發現Xen已經落後的太多了，比如：

1. hugepage：Xen只能提供2M物理頁面，而DPDK需要1G的連續物理內存，這是DPDK不能支持Xen的最主要原因。

2. KSM：透明頁面共享。

3. 多核(>128 CPU)調度: 雖然宣稱能支持最大192+ core, 但是實際我們發現如果在128 core的4P伺服器上創建大規格虛擬機並在其中使用高精度時鐘，導致虛擬機頻繁陷入陷出調度cpu，Xen就會出現嚴重問題，這顯然是Xen沒有經過大規模商業實踐的表現。

對於Citrix這樣以傳統Windows桌面為主要業務的公司，這些高IO，高吞吐，大規格的場景其實並不是他們關心的技術方向。相比之下，VMware也有類似的技術問題，但是在2008年左右，VMware就果斷的放棄了基於Domain 0架構的ESX, 轉向ESXi。

我們再來看看數據中心的情況，AWS這一代的C5已經進入25GE核心交換時代了。Xen其實在處理10GE轉發的時候就已經慘不忍睹，而且更重要的是，沒有進一步的技術優化空間，Xen社區其實10年前就知道相關問題了，一直都在做些不痛不癢的優化，不去從根本上解決問題，一副好牌在手，最終卻出局了......

雲谷計算 原創出品