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