从AWS转向KVM，再看KVM与XEN的技术路线之争！

昨天，一则新闻刷爆IT界朋友圈—云计算带头大哥正式宣布，已经开发一款基于KVM的新型虚拟机管理程序，这意味着其不再依赖多年来沿用的Xen虚拟机管理程序。近年来，业界除了AWS外，各大公有云及私有云甚至虚拟化厂商均纷纷将虚拟化技术路线向KVM进行切换。从此来看，KVM胜出于Xen似乎成了一个必然趋势。为什么会有这种趋势，且看小编通过新华三研发大拿们收集来的观点吧~

Xen 虚拟化技术简介

XEN最初是剑桥大学Xensource的一个开源研究项目，2003年9月发布了首个版本Xen 1.0，2007年Xensource被Citrix公司收购，开源Xen转由继续推进，该组织成员包括个人和公司（如Citrix、Oracle等）。目前该组织在2013年7月发布了最新版本Xen 4.3。

Xen是半虚拟化（Para-Virtualization）技术的典型代表。英文前缀“Para”直译为“侧”、“旁”、“近旁”的意思，“Para-Virtualization”可以理解为“在Guest VM旁边运行着的管理VM”，Xen称这个特别的VM为Dom0（与 Hyper-V的父分区类似），虚拟机Guest OS则被称做DomU（与微软Hyper-V的子分区类似）。

管理VM负责管理整个硬件平台上的所有输入输出设备驱动，也就是说，半虚拟化中的Hypervisor不对I/O设备作模拟，而仅仅对CPU和内存做模拟，这就是“Para-Virtualization”被翻译成“半虚拟化”的原因。半虚拟化还有一个比较普遍的叫法：操作系统辅助虚拟化（OS Assisted Virtualization），这是因为Guest VM自身不带设备驱动，需要向“管理VM”寻求帮助。

图1 Xen半虚拟化系统架构

相对于VMwareESX/ESXi和微软Hyper-V来说，Xen支持更广泛的CPU架构，前两者只支持CISC的X86/X86_64 CPU架构，Xen除此之外还支持RISC CPU架构，如IA64、ARM等。

Xen的Hypervisor是服务器经过BIOS启动之后载入的首个程序，然后启动一个具有特定权限的虚拟机（即Dom 0）。Dom 0的操作系统可以是Linux或Unix，它实现对Hypervisor控制和管理功能。在所承载的虚拟机中，Dom0是唯一可以直接访问物理硬件（如存储和网卡）的虚拟机，它通过本身加载的物理驱动，为其它虚拟机（即DomU）提供访问存储和网卡的桥梁。

半虚拟化架构的最大缺点是需要特定内核的操作系统，Windows操作系统由于其封闭性，不能被Xen的半虚拟化所支持。为了解决这个问题，Xen也支持全虚拟化（FullVirtualization），Xen称其为HVM（Hardware Virtual Machine）。Xen的全虚拟化要求CPU具备硬件辅助虚拟化，它修改的QEMU（Quick Emulator）仿真所有硬件，包括BIOS、IDE控制器、VGA显示卡、USB控制器和网卡等。为了提升I/O性能，全虚拟化特别针对磁盘和网卡采用半虚拟化设备来代替仿真设备，这些设备驱动称之为PV on HVM。为了使PV on HVM有最佳性能，CPU应具备MMU硬件辅助虚拟化。

Xen的Hypervisor层非常精简，少于15万行的代码量，不包含任何物理设备驱动，这一点与Hyper-V是非常类似的，物理设备的驱动均是驻留在Dom 0中，可以重用现有的Linux设备驱动程序。因此，Xen对硬件兼容性也是非常广泛的，Linux支持的，它就支持。

KVM虚拟化技术简介

KVM（Kernel-based Virtual Machine，基于内核的虚拟机）是一个基于Linux环境的开源虚拟化解决方案，最早由Qumranet公司开发，在2006年10月出现在Linux内核的邮件列表上，并于2007年2月被集成到Linux 2.6.20内核中，成为内核的一部分。2008年，Qumranet被RedHat所收购，但KVM本身仍是一个开源项目，由RedHat、IBM等厂商支持。KVM作为Linux内核中的一个模块，与Linux内核一起发布，最新版本为2013年5月发布的3.9.3版本。

与VMwareESX/ESXi、微软Hyper-V和Xen等虚拟化产品不同，KVM的思想是在Linux内核的基础上添加虚拟机管理模块，重用Linux内核中已经完善的进程调度、内存管理、IO管理等代码，使之成为一个可以支持运行虚拟机的Hypervisor。因此，KVM并不是一个完整的模拟器，而只是一个提供了虚拟化功能的内核插件，具体的模拟器工作需要借助QEMU来完成。

图2 KVM虚拟化系统架构

通过KVM模块的加载将Linux内核转变成Hypervisor，KVM在Linux内核的用户（User）模式和内核（Kernel）模式基础上增加了客户（Guest）模式。Linux本身运行于内核模式，主机进程运行于用户模式，虚拟机则运行于客户模式，使得转变后的Linux内核可以将主机进程和虚拟机进行统一的管理和调度，这也是KVM名称的由来。

KVM利用修改的QEMU提供BIOS、显卡、网络、磁盘控制器等的仿真，但对于I/O设备（主要指网卡和磁盘控制器）来说，则必然带来性能低下的问题。因此，KVM也引入了半虚拟化的设备驱动，通过虚拟机操作系统中的虚拟驱动与主机Linux内核中的物理驱动相配合，提供近似原生设备的性能。从此可以看出，KVM支持的物理设备也即是Linux所支持的物理设备。

KVM是基于硬件辅助虚拟化技术（Intel的VT-x或者AMD-V）的虚拟化解决方案，Guest OS能够不经过修改直接在KVM 的虚拟机中运行，每一台虚拟机能够享有独立的虚拟硬件资源，如网卡、磁盘、图形适配器等。

“基于Linux内核”是KVM在软件实现上不同于其它VMM实现的最重要特点，使得KVM在实现上能获得如下好处：

(1) 充分利用现有硬件的虚拟化功能。KVM虚拟化系统架构的设计目标是最大限度的利用现有的操作系统的各个功能模块和硬件对虚拟化技术支持，以一个内核来加载功能模块的方式实现，并将整个Linux内核转化成一个裸机的Hypervisor。因为KVM的设计是在硬件辅助虚拟化技术成熟之后，所以它没有必要实现当前主流硬件已经实现的虚拟化相关功能。

(2)充分利用现有软件的虚拟化功能。Hypervisor除了要虚拟CPU和内存外还需要其它的核心功能组件，如内存管理器、进程调度程序、I/O控制器、设备驱动、网络控制器等。Linux的内核已经包含了上述的功能模块并且产品化超过15年历史了，KVM正是看到这一点，利用Linux内核已有的成熟功能和基础服务云系统架构KVM，减少不必要的重新开发，如任务调度、物理内存管理、内存空间虚拟化、电源管理等功能。

（3）充分利用现有硬件的软件驱动程序。在KVM的系统构架中，虚拟机以普通Linux的进程的方式来实现，由标准的Linux进程调度器来调度。实际上每个虚拟CPU（vCPU）都是以一个常规的Linux进程呈现的。硬件设备的模拟则是通过一个修改过的QEMU来进行，提供了BIOS，PCI总线，USB总线和其他标准设备（如IDE和SCSI硬盘控制器以及网络控制器等）的模拟。KVM将Linux内核转化为Hypervisor，通常情况下支持Linux的硬件设备就可以被KVM支持。

KVM与Xen的技术介绍到这里，那到底该如何抉择呢？

中国有一句古话：“女怕选错郎，男怕入错行”，其实，商用产品的技术路线选择也是相同的，从来都是一件难以抉择的事情。从功能上相比，两者没有实质性的差别，从出身上来讲，Xen的血统似乎更高贵些，由剑桥大学“亲生”，后来“过继”给了著名的Citrix公司，而最早的KVM版本仅仅是游离于Linux核心边缘的一个不起眼的小模块，刚刚被红帽集成到其企业级版本中。到底选择哪个技术路线，的确是个艰难的抉择？ Xen发展的时间相对较长，理论上应该更成熟，但受限于Citrix未知的战略和其半虚拟化架构；KVM起步的时间相对较晚，但具有后发优势，比如天生支持硬件辅助虚拟化等。

在技术路线的选择问题上，需要考虑选型的三大原则：第一，平台，开源是未来软件行业发展的必然趋势，需要选择的是一个更具开放特质的开源平台，谁的开放性更好就选择谁；第二，架构，架构设计的优劣决定后续开发与维护的难度，更决定了性能的优劣；第三，性能，虚拟化是承载客户业务系统的底层平台，没有性能的保障就没有业务虚拟化的可能性。

基于这三条选型原则， KVM应该是更佳的虚拟化软件开发的平台。自从Citrix公司将其虚拟化战略重心转移到桌面之后，Xen开源社区的活跃程度迅速降低，而KVM作为Linux内核的一部分，长期享受着Linux内核技术不断成熟与进步带来的好处，这一优势也促使越来越多的虚拟化与云计算玩家向KVM转型，而业界包括各大公有云及私有云甚至虚拟化厂商均将技术路线向KVM进行切换更是说明了这一点。

（编辑：云计算网_宿迁站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!