背景

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年前就知道相关问题了，一直都在做些不痛不痒的优化，不去从根本上解决问题，一副好牌在手，最终却出局了……

云谷计算 原创出品