2008年9月，红帽收购了一家名叫Qumranet的以色列小公司，由此入手了一个叫做KVM的虚拟化技术（KVM，全称Kernel-based Virtual Machine，意为基于内核的虚拟机）。当时的虚拟化市场上主要以VMware为主，而KVM只是在Ubuntu等非商用发行版上获得了一些关注。
2009年9月，红帽发布其企业级Linux的5.4版本，在原先的Xen虚拟化机制之上，将KVM添加了进来。
2010年11月，红帽发布其企业级Linux的6.0版，这个版本将默认安装的Xen虚拟化机制彻底去除，仅提供KVM虚拟化机制。
2011年初，红帽的老搭档IBM找上红帽，表示KVM这个东西值得加大力度去做。于是到了5月，IBM和红帽，联合惠普和英特尔一起，成立了开放虚拟化联盟（Open Virtualization Alliance），一起声明要提升KVM的形象，加速KVM投入市场的速度，由此避免VMware一家独大的情况出现。联盟成立之时，红帽的发言人表示，“大家都希望除VMware之外还有一种开源选择。未来的云基础设施一定会基于开源。……我们想要营造一个小厂商们可以轻松加入的生态环境。”
于是，开放虚拟化联盟红红火火的成立了。从5月到8月这短短3个月间，开放虚拟化联盟的成员已经增加到将近300个，联盟发展的速度十分可观。IBM现在全线硬件都对红帽Linux和KVM进行了大量的优化，有60多名开发者专门开发KVM相关的代码。
原本采用Xen技术的红帽，为什么会想要再去搞一个KVM？而在虚拟化方面一直以来和Vmware、思杰、微软都有着紧密合作的IBM，为什么会对红帽的KVM展现出这样大的兴趣？这一切，还需要从整个虚拟化，乃至云计算市场的发展说起……
虚拟化发展简史
虚拟化技术最早出现在大型机时代。上世纪60年代，IBM开始在其CP-40大型机系统中尝试虚拟化的实现，后来在System/360-67中采用，并衍生出VM/CMS到后来的z/VM等产品线。大型机上的虚拟化技术在之后20多年的发展中愈发成熟，但随着小型机以及x86的流行，大型机在新兴的服务器市场中已经失去了影响力。
由于处理器架构的不同，在大型机上已经成熟的虚拟化技术却并不能为小型机及x86所用。直到2001年，VMware发布了第一个针对x86服务器的虚拟化产品。之后的几年间，英国剑桥大学的一位讲师发布了同样针对x86虚拟化的开源虚拟化项目Xen，并成立XenSource公司；惠普发布了针对HP-UX的Integrity虚拟机；Sun跟Solaris 10一同发布了同时支持x86/x64和SPARC架构的Solaris Zone；而微软也终于在2008年发布的Windows Server 2008 R2中加入了Hyper-V。期间，VMware被EMC收购，XenSource则被思杰收购。
之后的几年间，VMware逐渐在企业级市场中被广泛的接受，Xen也逐渐在互联网领域展露头角。在成熟的服务器操作系统当中，Novell SUSE Linux Enterprise 10是第一个采用Xen技术的。当时的Xen还很不成熟，乃至于红帽还为此取笑了Novell一番；不过几个月后，到了RHEL 5.0发布的时候，红帽决定也将Xen加入到自己的默认特性当中——那是2006年，也就是5年之前。一时之间，在Linux服务器领域，Xen似乎成为了VMware之外的最佳虚拟化选择（事实上也没多少其他可选的）。
但是，作为一项Linux平台上的虚拟化技术，Xen在很长一段时间内一直没有被接受到Linux内核的代码当中，这对于Xen的维护者而言，不仅意味着要多做很多工作，还意味着用户在废了半天劲装好Xen之后可能遇到意想不到的问题（注：2011年6月发布的Linux内核3.0中已经加入了对Xen的支持——Xen的工程师们表示这是清理了7年遗留代码、提交了600多个补丁的成果）。而红帽方面，也许是因为当时对这种脱离内核的维护方式很不爽，也许是因为采用Xen的RHEL在企业级虚拟化方面没有赢得太多的市场，也许是因为思杰跟微软走的太近了，种种原因，导致其萌生了放弃Xen的心思。事实上，当时整个Xen的市场表现的确一般，2008年Hyper-V推出的时候，甚至有评论猜测思杰自己都会抛弃Xen而投奔Hyper-V（当然，思杰后来在官方博客上否认了这个猜测，表示自己和微软只是合作的比较亲密而已）。
总之，红帽决定选择了一个新兴的、基于内核的虚拟化技术：KVM。而且在正式采用KVM一年后，就宣布在新的产品线中彻底放弃Xen，集中资源和精力进行KVM的工作。
那么，除了是Linux内核的一部分之外，KVM到底有啥好处？2008年的时候，红帽发言人表示，KVM相比Xen有着更好的可管理性以及更高的性能。性能这一点需要基准测试来说话，不过不同的基准测试会给出不同的结果，所以性能方面孰优孰劣很难一概而论；可管理性方面，红帽在大规模服务器自动化管理方面倒是一直很有一些心得，而且相关的工具大多是免费开源的，这点很不错。具体有哪些工具，可以查询KVM的这个页面，以及Xen的维基页面。
当然，KVM本身也有一些弱点，那就是相比裸金属虚拟化架构的Xen、VMware ESX和Hyper-V，KVM是运行在Linux内核之上的寄居式虚拟化架构，会消耗比较多的计算资源；不过针对这一点，Intel、AMD已经在处理器设计上有专门的VT-x和AMD-V扩展，这种特性在每次硬件更新的时候也会更新，往往每次更新后都对虚拟化性能和速度上有明显的提升，所以长远来看，也不是什么大问题。
图 裸金属虚拟化架构（左）与寄居式虚拟化架构（右）
红帽的思路理清楚了，至于IBM是怎么想的呢？其实也不难理解，因为VMware目前在虚拟化（继而到云计算）领域的发展势头，和上世纪80、90年代那会儿微软Windows在PC领域的情况实在太像了。一个只有VMware的虚拟化市场，绝不是IBM希望看到的结果。
不过，KVM技术到现在也不过发展了三年多的时间，要知道VMware可是发展了十年，这个技术的成熟度，难免令人产生疑问：现在在数据中心里用KVM，靠谱吗？
#p#副标题#e#
IBM高管：KVM在数据中心已经足够成熟
蓝色巨人一直以来似乎对红帽子选择的技术一向都十分看好。从上世纪90年代的Linux商业化，各种Linux on system x/p/i/z，到这次的KVM，IBM跟红帽一直走的很近。从1999年双方建立合作关系开始，IBM的各个硬件产品线都对红帽Linux进行了很多的优化，甚至在各方都认为KVM还不够成熟的时候，就将其采用为IBM Smart Business Enterprise Cloud云计算服务的底层虚拟化机制，并已经发展了一部分公共单位的用户（比如巴西的高速公路管理系统）。IBM系统软件部市场与销售副总裁，同时也是开放虚拟化联盟委员会成员之一的Inna Kuznetsova向51CTO编辑表示，“2010年，如果你问我KVM是否已经足够成熟到在数据中心使用，我还会表示怀疑；但是现在，我可以说KVM已经对数据中心做好了准备。”
IBM系统软件部市场与销售副总裁Inna Kuznetsova
红帽方面就更不用说了。红帽大中华区总裁潘应麟先生对51CTO编辑表示，云计算时代的IT已经从提供解决方案逐渐变成了按需提供服务。中国的虚拟化市场发展的很快，而且企业的规模、需求各自不同，需要更加个性化、更加灵活、交付更加快速的服务，而基于KVM，就可以满足这一点。通过成立联盟，提供技术与市场支持，可以吸引更多的ISV加入到KVM的平台上，形成一个应用生态环境，那么KVM成熟和普及的速度将会越来越快。从RHEL 6仅支持KVM这点，其实也能看出红帽对KVM成熟度的认可。
红帽大中华区总裁潘应麟先生
不过，一线的IT运维们对于这个说法似乎还表示质疑。《大话IT》的负责人之一王文文曾经在做一期节目的时候寻找一个KVM的用户，问了19个运维都在用VMware，直到第20个才找到一位KVM的用户，虽然这一位用户对KVM表示非常支持，但其他19位还都不怎么看好KVM；笔者自己也问过一些一线运维工程师的意见，他们表示在测试环境尝试过KVM（用的系统多是CentOS），不过虚拟机建多了就会感觉很卡，不如Xen和VMware那样稳定。
还有一点也是用户所担心的，那就是红帽在采用Xen的第四年后就宣布放弃了Xen，万一以后又放弃了KVM怎么办？不过关于这点，笔者认为倒是无需太担心。一来RHEL每一个版本的生命周期都有十年，RHEL 5会一直支持到2017年，如果不升级到RHEL 6，就不用担心没有Xen用的问题；二来服务器虚拟化这个领域现在有力的竞争者实在太少，除非红帽学惠普针对webOS的做法，把KVM一扔，向VMware投降了，否则，红帽在几年内放弃KVM是不太可能的事情。
其实作为用户，在进行技术选型的时候难免会担心这担心那的，担心产品不好，担心技术用了之后支持跟不上，担心厂商锁入，担心成本过高。KVM到底足够成熟了吗？我可以用KVM吗？用户有这些疑问都是正常的，选型前做足测试也是应该的。客观来说，现在的KVM肯定没有VMware和Xen那样成熟，Kuznetsova也说了，比如在低延时、高网络I/O方面，KVM做的还不够好。目前能保证的，就是在用户有需求的时候，KVM能够在一台宿主机上创建超过300台虚拟机，并有可能实现理论上的最大可扩展性；而在开放虚拟化联盟，红帽和IBM会提供有关KVM的各种文档，并尽力营造技术社区的支持氛围。
但是，除了上面这些之外，用户们也应该时刻考虑一个问题：我愿意接受一个只有VMware的虚拟化市场吗？正如同Kuznetsova所说的那样：“我们只是希望能够为客户提供另一个选择。”
原文链接：http://os.51cto.com/art/201109/288750.htm
