虚拟化因其对IT的关键、变革性的技术理念，日益深入人心，也必将影响深远。IT虚拟化这一激动人心的架构可以创建容量无限的动态资源池，从而帮助用户实现对资源的随时随地访问。对于转型中的电信运营商来说，IT系统不仅是提高效率的工具，更会成为拓展新业务的利器，有关虚拟化技术的讨论在电信业渐趋热烈。
　　近年来，虚拟化已经成为IT业界的焦点话题，尽管多数专家对于这一方向确信不移，但是对于IT系统日益庞大的电信运营商来说，应用尚不广泛。这一革命性的技术究竟会对电信IT系统带来哪些影响？尤其是对于运营商降低成本和提高收益有何帮助？上海电信在虚拟化领域的一些探索带给我们很好的启示。
　　启示一挑战
　　在上海电信近年的业务拓展中，现有的IT架构在一定程度上制约了业务的发展，尤其是在虚拟主机业务和虚拟独立服务器（VPS）业务方面，面临着一系列挑战。
　　——易用性。目前所用的软件为Xen，易用性较差，功能上有限制，在虚拟主机业务上应用较为合适，但是并不能很好地支撑更为灵活的VPS业务需求。
　　——可管理性。当前所用的虚拟化软件，兼容性和可管理性不是非常理想，对技术人员的要求也较高，另外诸如主机迁移、HA等功能也亟待实现。
　　——能源损耗。一方面，电信内部IT系统越来越庞大，机架资源、电力资源显得日趋紧张。而另一方面，设备硬件资源并未得到充分利用，很多系统空闲率非常高，资源浪费情况严重。而对于IDC机房这样的服务器集中程度高、密度大的地方，电力资源匮乏的问题更加突出。
　　——商业竞争。目前的虚拟主机业务资费和同行对比，优势不断缩小，需要进行自我改善，寻求新的商业竞争优势。
　　所以，从IDC增值业务角度出发，上海电信需要有更好的IT解决方案，优化内部IT管理，进一步与业务需求相结合，不断提升商业竞争优势。而虚拟化在资源整合以及节能减排等方面的应用，是上海电信在优化IT架构中关注的重点。
　　随着机构重组的进行，现有业务结构变更，一些新的业务也不断拓展，我们不难看出，原有IT架构在业务灵活性、系统扩展性、应用兼容性以及管理成本方面，难以满足新环境下的需求，上海电信信网部决定引入微软虚拟化技术，对现有IT架构实施优化和调整，以期进一步加强IT与业务紧密性，并降低IT总体拥有成本。经过评估，上海电信认为，利用虚拟化技术构建IT虚拟化基础架构，能够对现有的各种应用及业务系统服务器进行整合，对服务器资源进行更灵活、更合理的配置，极大程度地利用硬件投资，在提升IT服务的灵活性和高可用性的同时，极大降低IT管理成本。
启示二评估
　　虚拟化技术不应被看成是孤立的、战术性的工具，相反，虚拟化技术将对整个企业IT系统产生深远的影响，从数据中心到桌面，企业应确信其为基础架构战略的一部分。上海电信与微软合作，针对应用需求现状，综合虚拟化解决方案特性，制定了虚拟化技术应用解决方案。上海电信对虚拟化技术的各个方面进行了评估，认为应用虚拟化技术，能够帮助上海电信提升IT系统灵活性及对外服务能力，并且有效降低运维成本。
　　在对虚拟化技术的评估过程中，上海电信根据自身的发展需求，着重评估了微软虚拟化解决方案的易用性、可管理性以及测试其对应用系统的支持和虚拟化的效果。主要测试项目包括以下方面：产品安装配置,构建虚拟化基础架构环境；虚拟机部署，使用SCVMM进行虚拟机部署，能够支持Xen等异构系统，并利用SCVMM的模板化部署以及PowerShell，实现虚拟机的高度自动化部署；物理迁移，利用SCVMM的快速迁移功能，在物理服务器直接快速迁移虚拟机，并可将物理服务器直接转换为虚拟机；高可用性，通过在物理服务器群集构建故障转移群集，并配合Hyper-V双重保障虚拟机的高可用性；监控，利用SCOM集中化，全面地监控虚拟化环境中各种服务机应用的运作；备份，利用DPM实现虚拟机的备份及集中化管理，并能够自动、快速创建还原点；安全管理，利用活动目录的安全特性，并配合SCVMM的安全模版化管理，对物理和虚拟化环境实施安全统一配置机管理；资源管理，利用SCVMM能够很好地管理虚拟资源中的CPU、内存以及存储，并且能够实时动态进行资源调配。SCVM配合SCOM能够实时监控物理机和虚拟机资源分配的状况以及压力状态，从而实施自动化调整动作。
　　这一虚拟化解决方案，能够实现新的虚拟化IT架构，从而更加灵活地适应新的业务需求。
　　下一步，上海电信将考虑利用微软虚拟化解决方案，整合服务器资源，提高现有硬件资源利用率，同时对其他业务系统应用微软虚拟化高可用性架构。
　　启示三成效
　　上海电信信网部IT人员认为，物理到虚拟机的快速迁移，非常具有特色，能够实现从物理环境到虚拟化的转移。因此，虚拟化技术，能够为上海电信带来显著的收益，这些收益包括以下方面。
　　——极大提高服务器利用率。服务器整合是所有虚拟技术中重要的部分，是将操作系统和其上层运行的应用程序打包后，以虚拟机的形式运行在基于Hypervisor（一个瘦软件层，提供硬件的基本接口）的物理服务器上。单个物理服务器可运行多个虚拟机，同时提供隔离和安全防护，每个虚拟机都像在自己的硬件上运行一样。通过在进程和内存消耗方面匹配及互补工作负荷，上海电信可以降低支持业务操作的物理服务器数量。
　　——提升对外服务的灵活性和高可用性。由于电信行业的特殊性，上海电信能够利用微软服务器虚拟化解决方案，通过针对虚拟机资源占用的动态分配，为新上线、用户访问量大的后台服务器分配较多的资源用以支撑该项服务，为用户提供良好的使用体验。此外，全面的监控及管理，包括安全更新、性能及应用健康监控、运维配置管理、虚拟机映像及数据库文件备份等手段，可以使服务器长期处于高可用状态，减少停机维护时间，达到较高的用户满意度。面对复杂的IT环境，上海电信的IT专业人员，每天都需要面对大量的服务器运行维护与最终用户支持工作。通过将业务应用迁移至虚拟服务器，IT人员只需维护少量的硬件服务器即可实现业务系统的正常运行。同时，虚拟化解决方案所提供的管理工具，可以简化和加速虚拟环境的设置过程。如果新的业务系统需要更多IT资源，那么添加资源的过程也是非常简单而且实时的，工作负载完全可以实现自动适应，以形成更动态的资源分配。
　　——极大降低总体拥有成本。上海电信在不断对服务器硬件设备进行投资的同时，也注意到单个服务器的利用率问题。同时，受席卷全球的经济危机的影响，用于购买新的硬件设备的预算将会被削减，于是怎样提高服务器的利用率就变成一个电信公司所关心的问题。微软虚拟化技术就是一种应对这种挑战的技术。微软虚拟化技术，既节省了硬件开销，又减少了硬件设备的维护数量，IT人员的人力成本也随之大大降低。上海电信可以有效地控制IT系统的成本，公司可以将更多的资金用于企业的业务发展。

对电信运营商的不同企业应用，如ERP、邮件、OA以及计费系统、CRM等，如何评估和选择实施或不实施虚拟化技术？
刘宏程：评估实施或者不实施虚拟化技术我们觉得不能一概而论，虚拟化的实施其实是一个复杂的过程，我们建议用户遵循规划、部署和迁移、运行维护的步骤实施虚拟化。
评估属于规划第一步。从服务器硬件角度考虑，原有服务器如果需要升级到新的高性能系统，或者新系统平均使用率低于40%，那么从应用角度考虑，不需要特殊硬件支持的应用，如ERP、邮件、OA和CRM等均适合虚拟化。
需要指出的是，这个评估过程需要一套完善的数据收集和分析等过程，包括收集客户原有配置及服务器性能数据、确认被虚拟化的对象、推荐虚拟化采用的平台、确认在虚拟机里运行的应用及分配等，建议用户选具有丰富经验的IT合作伙伴进行专业虚拟化评估服务。
惠普已经推出广泛的产品(软硬件)和服务组合，旨在帮助客户高效地部署虚拟化，实现更为出色的业务成效。惠普致力于虚拟化技术已有很长一段时间，拥有极为丰富的经验，可以根据客户特定环境需求制作专业化的虚拟化建议书，指导用户实施虚拟化。
虚拟化本身存在哪些安全风险，如何解决？
刘宏程：目前，虚拟化的初步应用让许多新用户着实感到兴奋：原来一台服务器只能运行一两个应用，现在通过虚拟化，甚至可以将一台服务器变成十台，同时可以运行很多不同的应用。而且，用户构建一台虚拟机，完全比以前单独采购物理机，重新再装载各种各样的应用会容易得多。
因此，有的用户就会无限制地创建虚拟系统。现在，很多用户碰到了类似的问题，原来的10台机器进行虚拟化之后，变成了100台虚拟机，但并不是虚拟化之后，就不需再进行管理了。100台虚拟机还会碰到与100台物理机同样的问题，比如说分发部署：如何将100台虚拟机快速安装好，以节省管理员的宝贵时间；如何快速地恢复系统，这里面还包括像诸如安全扫描，为漏洞安装补丁等操作。这些操作不管是物理机也好，还是虚拟机也好，只要操作系统有漏洞，肯定会有这方面的管理需求，这是不可避免的。
因此，如何有效地治理企业IT架构环境里数量众多的虚拟机，如何实现物理和虚拟服务器之间的良好运维，成为了亟待解决的问题。
虚拟化的软硬件投资成本如何计算，电信运营商如何分析投资收益？
刘宏程：虚拟化技术最直接的收益是能满足运营商IT应用峰值容量的需求，减少服务器的数量，例如通过采用虚拟化技术，某企业中的1000台服务器可以被85台服务器代替，耗电可节省50%。但虚拟化的投资成本除了软硬件投资成本外，其实还有前期部署成本、员工培训投入等等成本。如果CEO们还是把虚拟化技术简单认为是一项技术工具，而非公司提升业务成效和竞争力的有效手段，那么虚拟化的更大范围普及恐怕依然难以摆脱桎梏。
作为全球领先的虚拟化技术厂商，惠普认为，企业虚拟化战略的重心应该放到如何促进企业业务发展上，而不是在技术应用的后果层面。一旦企业开始从业务成效角度关注虚拟化技术，则其不仅能降低成本、提高效率，而且还能充分体现虚拟化技术的价值。惠普不断推出的基于“业务科技”理念的虚拟化技术相关产品、服务及解决方案正体现了这一核心观点。
虚拟环境对IT管理人员提出了哪些挑战，运营商IT管理人员需要掌握哪些必要的技能？
刘宏程：惠普最新的调查结果显示，缺乏培训和经验是客户实现虚拟化项目成功实施的最大障碍。针对IT管理人员需要掌握的技能，惠普进行了科学的总结，并将这些需要具备的技能通过提供新的培训课程和支持服务弥补这一资源空白，包括为技术团队提供虚拟化专业技术。这些服务进一步扩展了惠普针对整个虚拟化生命周期的广泛服务产品，包括持续的服务改进。比如：惠普虚拟化支持服务中的面向一系列惠普虚拟软件产品的惠普培训课程，包括HP-UX虚拟化工具训练营示范系统和工作负载管理。此外，惠普操作管理服务可以帮助运营商提高员工的技术水平，在各种流程中实施相应变更，并提供适用的ITIL/ITSM和项目管理技术。
案例1　中国移动研究院利用虚拟化降低能耗
在2008年，由于电力供给不足，使得中国移动研究院实验室的电力供应无法满足测试需求，某些测试设备无法加电，从而影响测试进度。其中各专业实验室的服务器每年的电力消耗巨大，因此，降低服务器的能耗意义重大，可以有效解决实验室电力不足的问题。
截至2008年10月，中国移动研究院实验室公用PC服务器共有18台，各专业实验室共有PC服务器52台(四路10台，两路含刀片42台)，各专业应用平台共有PC服务器49台(四路6台，两路43台)；中国移动研究院决定利用服务器虚拟化技术，达到节能的效果。
经过前期工作，目前实验室公用服务器部分已经实施了虚拟化管理，所有服务器的申请将通过维护人员评估，通过VirtualCenter浏览器界面、从服务器摸板库中选择标准环境、签出及部署等操作只要几分钟，然后将IP地址发给申请人员，并到期自动回收，实现了按需分配为虚拟服务器。针对中国移动研究院IT数据中心将采用大量PC服务器，数据中心在设计之初就充分考虑通过虚拟化技术提高服务器资源利用率并简化维护工作量，并通过虚拟化HA提高各应用系统的可靠性，做到服务器物理故障不影响应用运行。
目前，中国移动研究院实验室虚拟化平台共管理物理机18台，具有同时提供30-60台虚拟机的能力，电力和空间的节约达到100%以上，并已将其引入了多项测试中。同时IT数据中心通过四台四路PC服务器提供38台虚拟机作为研究院IT应用和测试环境。通过IT虚拟化技术，不但大大提高了服务器的利用率，加强了对PC服务器的管理，节约了成本，而且有效地降低了能耗，减少了实验室的服务器空间占用，打造了名副其实的“绿色”实验室。
案例2　中国电信上海研究院借虚拟技术优化测试环境
中国电信上海研究院承担了很多大设备产品的测试工作，不仅任务繁重，而且测试环境的变化也十分频繁，这对测试环境的部署提出了非常高的要求：研究院需要搭建快速的测试环境，及时地更换测试环境，以便更好地利用硬件设施；需要重复利用一些测试环境，但是又不能长期将服务器闲置；需要更好地对服务器进行管理，降低维护成本。为了应对这些问题，中国电信上海研究院决定对其IT基础架构实施虚拟化策略。
研究院利用四台DellPowerEdge6850服务器，该型号服务器为基于Intel服务器芯片的四路四核系统，后端连接EMCCX600磁盘阵列，搭建了整个虚拟化应用架构。同时利用VMWareESXSer-ver3.5作为其服务器虚拟化的产品，配合使用其中的P2V功能、VMotion功能和HA高可用性，部署了部分测试用的虚拟环境，在每台物理服务器上部署了5～6个虚拟机，通过VirtualCenter能够进行统一的虚拟机管理和计算资源、存储资源的调度，实现了快速的系统迁移。
研究院通过采用虚拟化方案，利用统一的模板，能够很快部署好新的应用环境。此前搭建测试环境需要数天的时间来准备，现在通过服务器虚拟化模板，只要不到一小时的时间就能够准备完毕，如果是此前的环境重用，只需要数分钟进行虚拟机的启用即可。应用虚拟化方案之后，研究院的服务器利用率从原有的平均10%提升到了现在的70%～80%。此前，如果同时有10多个测试任务的话，由于涉及到多个部门，每个任务都需要多台服务器，必须同时准备几十台服务器，从而导致服务器的资源分配问题。
通过服务器虚拟化技术，在一台硬件能力较强的服务器上进行切分，能够快速地搭建所需要的测试环境，最大化地利用服务器。
与此同时，针对原有的应用测试环境，研究院通过P2V工具很方便地将其迁移到虚拟环境中，这样就能够保证原先已经搭建的虚拟系统能够不中断地迁移到新环境之下，不会对企业的测试造成损失。上线运行以来，系统一直非常稳定，很好地满足了测试需求，并且能够降低人力维护成本和电力运行成本，减少了对物理服务器数量的需求，从而降低了对数据中心空间的占用。基于此次虚拟化实施的成功经验，中国电信上海研究院准备在将来对现有的x86服务器进行进一步的整合，在更大范围内部署服务器虚拟化方案。

5、虚拟化是什么？
答：欺骗。被调用者对调用者的欺骗。
虚拟化就是由位于下层的软件模块，通过向上一层软件模块提供一个与它原先所期待的运行环境完全一致的接口的方法，抽象出一个虚拟的软件或硬件接口，使得上层软件可以直接运行在虚拟环境上。
6、虚拟化是云计算必须的吗？
答：不是。云计算的两条底层技术路线：分布式和虚拟化。
–分布式计算
•Hadoop
•Hadoop的核心是MapReduce和HDFS
•是计算资源的整合
•阿里巴巴
–虚拟化
•Xen/VMWare
•Server Consolidation
•是计算资源的分割
•Amazon
7、虚拟化分为服务器虚拟化、桌面虚拟化和应用虚拟化，该如何理解各种虚拟化？

摘要：虚拟化已经深入了IT各个领域。面对虚拟化潮流，唯有顺势而为早日做好部署，才能在未来的竞争中获得优势。     当然，在整个IT环境中实施虚拟化部署并不是件容易的事情，通常来说，这其中包括有：
–决定实施虚拟化的设备(全部还是部分)
–决定实施虚拟化平台的软硬件，比如是Hyper-V还是VMware或者Xenapp
–先从小部分服务器和工作站开始搭建平台，并全面测试其工作性能和资源消耗情况
–为冗余/故障设立合理的备份措施，并利用工具进行监视和纠错
从虚拟化角度来说，它的好处有很多，比如减少硬件、集中化管理、节省运营成本甚至有助于环保–低功耗(也可以称之为硬件污染)。执行虚拟化环境所带来的影响是多方面的。但它有没有负面影响呢？
虚拟化平台资源尤其是底层的硬件设备，都是可以实现共享的。主机上的虚拟机并不知道共享同一台主机的客户情况， 否则它们将会造成客户机之间的竞争。总的来说，如果所有资源密集型任务都在同一时间涌向客户机，就可能会影响到主机的性能表现。另一个缺点是，如果虚拟化平台上的主机性能受到影响，那么，它就会既影响到主机本身还会影响到共享同一主机的其他客户。
为此，我们提出在实施虚拟化策略的过程中，不能忽视以下三个关键要点：
1、日益增多的碎片会造成I/O瓶颈和性能下降问题–虚拟化平台中，文件出现碎片或者写入到磁盘的分区过于分散。
2、数据被删除时虚拟磁盘空间不会随之缩减。
3、虚拟机会争夺I/O资源，而且它们使用的时候不能跨平台有效地实施优先级。
这些问题可能会降低虚拟机的性能，也会影响迁移到虚拟平台的实现。不过，避免资源冲突和实现系统优化可以弥补这些不足。删除文件系统中的碎片有助于降低I/O资源消耗。更小的I/O请求将有助于I/O性能和可靠性的持久发挥。
磁盘空间是很宝贵的资源，虚拟环境下任何空间的浪费都不可接受的。对磁盘空间使用状况进行持续监测，特别是动态环境下的空间使用状况的监测，显得更加重要。

摘要：过去10年里，虚拟技术帮助IT工程师实现了整合资源，节约成本，助力企业增长等目标。不过，虚拟化究竟能产生多大影响呢？跟现代服务器技术打交道的工程师应该懂得利用该技术资源，帮助企业增长、扩大。通过在一台物理主机上安装多个虚拟机器，数据中心运行会更流畅，而且硬件设备的数量可以相对减少。新型的惠普ProLiant服务器配置了英特尔8核处理器，可以负载5至6台虚拟机。那么，明明可以实施虚拟化，为什么我们还紧抓住硬件不放呢？
虚拟化变得越来越容易，网络工程师也越发能接受虚拟技术。然而，现在对该技术的运用却出现了下降趋势。最近，许多公司的做法是，买一台服务器，把工作负荷放在存储网络(SAN)，再安装管理程序和虚拟机。尽管这个方法可行，但IT管理员却常常略过影响虚拟服务器性能的某些重要步骤。
了解虚拟化技术
一般来讲，虚拟技术有两种类型：主机架构和裸机架构。主机架构环境下，服务器有预先安装的操作系统，例如WindowsServer2008。管理员会在原操作系统上加载安装虚拟化软件。裸机架构则完全移除原有操作系统，重新安装Linux/Unix-basedkernel作为管理程序。基本上，虚拟技术是直接安装在硬件上的。CitrixSystems的XenServer适用裸机架构，VMware公司两种技术都能提供。
裸机架构的最大优势在于虚拟机不需要其他软件就能直接访问基础硬件资源。不过，裸机架构要求更新型的硬件，譬如机载服务器必须是Intel-VT或是AMD-V。这意味着，升级的旧服务器利用不了这项技术。虽然如此，主机架构管理程序总是可以利用的。
资源利用
无论对于物理主机还是虚拟机，合理的资源分配都是至关重要的。在部署前，必须了解利用这些硬件要达到什么目的。要进行不间断的高端SQL查询？或者公司计划安装一些应用软件满足一部分用户不定期访问的要求？明白了目标是什么，管理员才能进行合理架设，处理相应工作负荷，更重要的是，伴随基础设施的变化，整个架构也能做出相应调整。
谈到物理硬件，有三个主要的升级办法：
1.硬盘驱动器对于升级硬盘驱动器能显著改善虚拟机性能的说法，大家几乎没有异议。如果现有环境不是把存储网络作为工作负荷的中心，可以考虑用多个高速硬盘来实现升级。对于小型公司，由于不需使用集中存储排列，通常是升级物理硬件内置容量。也就是说，通过更新性能更好的驱动来升级RAID排列，整个运行环境会有很大提高，冗余也会增加。
对于已有存储区域网的较大规模环境，考虑利用现有的技术。存储区域网老化了吗？依附在存储区域网上的驱动是否运行得够快，能够快速和无缝地访问一项工作负荷吗？IT工程师考虑这个问题时，经常会跳过更换存储区域网这个想法，而让他们感到疑惑的是尽管有了新服务器和新虚拟化软件，他们的虚拟基础设施为何运行缓慢。
2.CPU虚拟机装到物理机上时，机载处理器利用率更高了。
从IT工程师的角度看，更快的CPU总能提供更快的处理速度。物理主机有空间允许CPU升级甚至是增加。许多机器配置了开放性CPU槽，以备扩容之需。
3.RAM升级RAM可能是挖掘虚拟主机性能最经济有效的办法。通过在主机上升级内存，能够给每台虚拟机分配更多的RAM。任何一台服务器都能承载比平常更多的RAM。增加RAM之后，工程师就能再次检查虚拟机是如何利用资源的。从而，可以根据实际需要，额外分配内存给特定机器以提高效率。

OpenStack的架构
1. OpenStack是什么
OpenStack既是一个社区，也是一个项目和一个开源软件，它提供了一个部署云的操作平台或工具集。其宗旨在于，帮助组织运行为虚拟计算或存储服务的云，为公有云、私有云，也为大云、小云提供可扩展的、灵活的云计算。
OpenStack旗下包含了一组由社区维护的开源项目，他们分别是OpenStack Compute（Nova），OpenStack Object Storage（Swift），以及OpenStack Image Service（Glance）。
OpenStack Compute[1]，为云组织的控制器，它提供一个工具来部署云，包括运行实例、管理网络以及控制用户和其他项目对云的访问（the cloud through users and projects）。它底层的开源项目名称是Nova，其提供的软件能控制IaaS云计算平台，类似于Amazon EC2和Rackspace Cloud Servers。实际上它定义的是，与运行在主机操作系统上潜在的虚拟化机制交互的驱动，暴露基于Web API的功能。
OpenStack Object Storage[2]，是一个可扩展的对象存储系统。对象存储支持多种应用，比如复制和存档数据，图像或视频服务，存储次级静态数据，开发数据存储整合的新应用，存储容量难以估计的数据，为Web应用创建基于云的弹性存储。
OpenStack Image Service[1]，是一个虚拟机镜像的存储、查询和检索系统，服务包括的RESTful API允许用户通过HTTP请求查询VM镜像元数据，以及检索实际的镜像。VM镜像有四种配置方式：简单的文件系统，类似OpenStack Object Storage的对象存储系统，直接用Amazon’s Simple Storage Solution (S3) 存储，用带有Object Store的S3间接访问S3。
三个项目的基本关系如下图1-1所示：
1-1 OpenStack三个组件的关系
2.云服务提供商的概念架构
OpenStack能帮我们建立自己的IaaS，提供类似Amazon Web Service的服务给客户。为实现这一点，我们需要提供几个高级特性：
a)允许应用拥有者注册云服务，查看运用和计费情况；
b)允许Developers/DevOps folks创建和存储他们应用的自定义镜像；
c)允许他们启动、监控和终止实例；
d)允许Cloud Operator配置和操作基础架构
这四点都直击提供IaaS的核心，现在假设你同意了这四个特性，现在就可以将它们放进如下所示的概念架构2-1中。
2-1 OpenStack 概念架构
在此模型中，作者假设了需要与云交互的四个用户集：developers, devops, owners and operators，并为每类用户划分了他们所需要的功能。该架构采用的是非常普通的分层方法（presentation, logic and resources），它带有两个正交区域。
展示层，组件与用户交互，接受和呈现信息。Web portals为非开发者提供图形界面，为开发者提供API端点。如果是更复杂的结构，负载均衡，控制代理，安全和名称服务也都会在这层。
逻辑层为云提供逻辑（intelligence）和控制功能。这层包括部署（复杂任务的工作流），调度（作业到资源的映射），策略（配额等等），镜像注册image registry (实例镜像的元数据)，日志 (事件和计量) 。
假设绝大多数服务提供者已经有客户身份和计费系统。任何云架构都需要整合这些系统。
在任何复杂的环境下，我们都将需要一个management层来操作这个环境。它应该包括一个API访问云管理特性以及一些监控形式（forms）。很可能，监控功能将以整合的形式加入一个已存在的工具中。当前的架构中已经为我们虚拟的服务提供商加入了monitoring和admin API，在更完全的架构中，你将见到一系列的支持功能，比如provisioning和 configuration management。
最后，资源层。既然这是一个compute云，我们就需要实际的compute、network 和 storage资源，以供应给我们的客户。该层提供这些服务，无论他们是服务器，网络交换机，NAS（network attached storage）还是其他的一些资源。
3. OpenStack Compute架构
3.1OpenStack Compute逻辑架构
OpenStack Compute逻辑架构中，组件中的绝大多数可分为两种自定义编写的Python守护进程（custom written python daemons）。
a)接收和协调API调用的WSGI应用（nova-api, glance-api, etc）
b)执行部署任务的Worker守护进程（nova-compute, nova-network, nova-schedule, etc.）
然而，逻辑架构中有两个重要的部分，既不是自定义编写，也不是基于Python，它们是消息队列和数据库。二者简化了复杂任务（通过消息传递和信息共享的任务）的异步部署。
逻辑架构图3-1如下所示：
3-1 OpenStack Compute逻辑架构
从图中，我们可以总结出三点：
a)终端用户（DevOps, Developers 和其他的 OpenStack 组件）通过和nova-api对话来与OpenStack Compute交互。
b)OpenStack Compute守护进程之间通过队列（行为）和数据库（信息）来交换信息，以执行API请求。
c)OpenStack Glance基本上是独立的基础架构，OpenStack Compute通过Glance API来和它交互。
其各个组件的情况如下：
a)nova-api守护进程是OpenStack Compute的中心。它为所有API查询（OpenStack API 或 EC2 API）提供端点，初始化绝大多数部署活动（比如运行实例），以及实施一些策略（绝大多数的配额检查）。
b)nova-compute进程主要是一个创建和终止虚拟机实例的Worker守护进程。其过程相当复杂，但是基本原理很简单：从队列中接收行为，然后在更新数据库的状态时，执行一系列的系统命令执行他们。
c)nova-volume管理映射到计算机实例的卷的创建、附加和取消。这些卷可以来自很多提供商，比如，ISCSI和AoE。
d)Nova-network worker守护进程类似于nova-compute和nova-volume。它从队列中接收网络任务，然后执行任务以操控网络，比如创建bridging interfaces或改变iptables rules。
e)Queue提供中心hub，为守护进程传递消息。当前用RabbitMQ实现。但是理论上能是python ampqlib支持的任何AMPQ消息队列。
f)SQL database存储云基础架构中的绝大多数编译时和运行时状态。这包括了可用的实例类型，在用的实例，可用的网络和项目。理论上，OpenStack Compute能支持SQL-Alchemy支持的任何数据库，但是当前广泛使用的数据库是sqlite3（仅适合测试和开发工作），MySQL和PostgreSQL。
g)OpenStack Glance，是一个单独的项目，它是一个compute架构中可选的部分，分为三个部分：glance-api, glance-registry and the image store. 其中，glance-api接受API调用，glance-registry负责存储和检索镜像的元数据，实际的Image Blob存储在Image Store中。Image Store可以是多种不同的Object Store，包括OpenStack Object Storage (Swift)
h)最后，user dashboard是另一个可选的项目。OpenStack Dashboard提供了一个OpenStack Compute界面来给应用开发者和devops staff类似API的功能。当前它是作为Django web Application来实现的。当然，也有其他可用的Web前端。
3.2概念映射
将逻辑架构映射到概念架构中（如3-2所示），可以看见我们还缺少什么。
3-2 逻辑架构到概念架构的映射
这种覆盖方式并不是唯一的，这里的只是作者的理解。通过覆盖OpenStack Compute 逻辑组件，Glance和Dashboard，来表示功能范围。对于每一个覆盖，都有相应的提供该功能的逻辑组件的名称。
a)在这种覆盖范围中，最大的差距是logging和billing。此刻，OpenStack Compute没有能协调logging事件、记录日志以及创建/呈现bills的Billing组件。真正的焦点是logging和Billing的整合。这能通过以下方式来补救。比如代码扩充，商业产品或者服务或者自定义日志解析的整合。
b)Identity也是未来可能要补充的一点。
c)customer portal也是一个整合点。user dashboard（见运行的实例，启动新的实例）没有提供一个界面，来允许应用拥有者签署服务，跟踪它们的费用以及声明有问题的票据（lodge trouble tickets）。而且，这很可能对我们设想的服务提供商来说是合适的。
d)理想的情况是，Admin API会复制我们能通过命令行接口做的所有功能。在带有Admin API work的Diablo 发布中会更好。
e)云监控和操作将是服务提供商关注的重点。好操作方法的关键是好的工具。当前，OpenStack Compute 提供 nova-instancemonitor，它跟踪计算结点使用情况。未来我们还需要三方工具来监控。
f)Policy是极其重要的方面，但是会与供应商很相关。从quotas到QoS，到隐私控制都在其管辖内。当前图上有部分覆盖，但是这取决于供应商的复杂需求。为准确起见，OpenStack Compute 为实例，浮点IP地址以及元数据提供配额。
g)当前，OpenStack Compute内的Scheduling对于大的安装来说是相当初步的。调度器是以插件的方式设计的，目前支持chance(随机主机分配)，simple(最少负载)和zone（在一个可用区域里的随机结点。）分布式的调度器和理解异构主机的调度器正在开发之中。
如你所见，OpenStack Compute为我们想象的服务提供商，提供了一个不错的基础，只要服务提供商愿意做一些整合。
3.3OpenStack Compute系统架构
OpenStack Compute由一些主要组件组成。“Cloud controller”包含很多组件，它表示全局状态，以及与其他组件交互。实际上，它提供的是Nova-api服务。它的功能是：为所有API查询提供一个端点，初始化绝大多数的部署活动，以及实施一些策略。API 服务器起cloud controller web Service前端的作用。Compute controller 提供compute服务资源，典型包含compute service，Object Store component可选地提供存储服务。Auth manager提供认证和授权服务，Volume controller为compute servers提供快速和持久的块级别存储。Network controller提供虚拟网络使compute servers彼此交互以及与公网进行交互。Scheduler选择最合适的compute controller来管理（host）一个实例。
OpenStack Compute建立在无共享、基于消息的架构上。Cloud controller通过HTTP与internal object store交互，通过AMQP和scheduler、network controller、 和volume controller 来进行通信。为了避免在等待接收时阻塞每个组件，OpenStack Compute用异步调用的方式。
为了获得带有一个组件多个备份的无共享属性，OpenStack Compute将所有的云系统状态保持在分布式的数据存储中。对系统状态的更新会写到这个存储中，必要时用质子事务。
对系统状态的请求会从store中读出。在少数情况下，控制器也会短时间缓存读取结果。
3.4OpenStack Compute物理架构
OpenStack Compute采用无共享、基于消息的架构，非常灵活，我们能安装每个nova- service在单独的服务器上，这意味着安装OpenStack Compute有多种可能的方法。可能多结点部署唯一的联合依赖性，是Dashboard必须被安装在nova-api服务器。几种部署架构如下：
a)单结点：一台服务器运行所有的nova- services，同时也驱动虚拟实例。这种配置只为尝试OpenStack Compute，或者为了开发目的；
b)双结点：一个cloud controller 结点运行除nova-compute外的所有nova-services，compute结点运行nova-compute。一台客户计算机很可能需要打包镜像，以及和服务器进行交互，但是并不是必要的。这种配置主要用于概念和开发环境的证明。
c)多结点：通过简单部署nova-compute在一台额外的服务器以及拷贝nova.conf文件到这个新增的结点，你能在两结点的基础上，添加更多的compute结点，形成多结点部署。在较为复杂的多结点部署中，还能增加一个volume controller 和一个network controller作为额外的结点。对于运行多个需要大量处理能力的虚拟机实例，至少是4个结点是最好的。
一个可能的Openstack Compute多服务器部署（集群中联网的虚拟服务器可能会改变）如下3-3所示：
3-3 OpenStack Compute物理架构一
如果你注意到消息队列中大量的复制引发了性能问题，一种可选的架构是增加更多的Messaging服务器。在这种情形下，除了可以扩展数据库服务器外，还可以增加一台额外的RabbitMQ服务器。部署中可以在任意服务器上运行任意nova-service，只要nova.conf中配置为指向RabbitMQ服务器，并且这些服务器能发送消息到它。
下图3-4是另外一种多结点的部署架构。
3-4 多结点的部署架构二
3.5 OpenStack Compute服务架构
因为Compute有多个服务，也可能有多种配置，下图3-5显示了总体的服务架构，以及服务之间的通信系统。
3-5 OpenStack Compute服务架构
4.OpenStack Image Service
OpenStack Image Service包括两个主要的部分，分别是API server和Registry server(s)。
OpenStack Image Service的设计，尽可能适合各种后端仓储和注册数据库方案。API Server（运行“glance api”程序）起通信hub的作用。比如各种各样的客户程序，镜像元数据的注册，实际包含虚拟机镜像数据的存储系统，都是通过它来进行通信的。API server转发客户端的请求到镜像元数据注册处和它的后端仓储。OpenStack Image Service就是通过这些机制来实际保存进来的虚拟机镜像的。
OpenStack Image Service支持的后端仓储有：
a)OpenStack Object Storage。它是OpenStack中高可用的对象存储项目。
b)FileSystem。OpenStack Image Service存储虚拟机镜像的默认后端是后端文件系统。这个简单的后端会把镜像文件写到本地文件系统。
c)S3。该后端允许OpenStack Image Service存储虚拟机镜像在Amazon S3服务中。
d)HTTP。OpenStack Image Service能通过HTTP在Internet上读取可用的虚拟机镜像。这种存储方式是只读的。
OpenStack Image Service registry servers是遵守OpenStack Image Service Registry API的服务器。
根据安装手册，这两个服务安装在同一个服务器上。镜像本身则可存储在OpenStack Object Storage， Amazon’s S3 infrastructure，fileSystem。如果你只需要只读访问，可以存储在一台Web服务器上。
5.OpenStack Object Storage
5.1 关键概念
a)Accounts和 Account Servers
OpenStack Object Storage系统被设计来供许多不同的存储消费者或客户使用。每个用户必须通过认证系统来识别自己。为此，OpenStack Object Storage提供了一个授权系统（swauth）。
运行Account服务的结点与个体账户是不同的概念。Account服务器是存储系统的部分，必须和Container服务器和Object服务器配置在一起。
b)Authentication 和 Access Permissions
你必须通过认证服务来认证，以接收OpenStack Object Storage连接参数和认证令牌。令牌必须为所有后面的container/object操作而传递。典型的，特定语言的API处理认证，令牌传递和HTTPS request/response 通信。
通过运用X-Container-Read: accountname和 X-Container-Write: accountname:username，你能为用户或者账户对对象执行访问控制。比如，这个设置就允许来自accountname账户的的任意用户来读，但是只允许accountname账户里的用户username来写。你也能给OpenStack Object Storage中存储的对象授予公共访问的权限，而且可以通过Referer头部阻止像热链接这种基于站点的内容盗窃，来限制公共访问。公共的container设置被用作访问控制列表之上的默认授权。比如，X-Container-Read: referer: any 这个设置，允许任何人能从container中读，而不管其他的授权设置。
一般来说，每个用户能完全访问自己的存储账户。用户必须用他们的证书来认证，一旦被认证，他们就能创建或删除container，以及账户之类的对象。一个用户能访问另一个账户的内容的唯一方式是，他们享有一个API访问key或你的认证系统提供的会话令牌。
c)Containers and Objects
一个Container是一个存储隔间，为你提供一种组织属于属于你的数据的方式。它比较类似于文件夹或目录。Container和其他文件系统概念的主要差异是containers不能嵌套。然而，你可以在你的账户内创建无数的containers。但是你必须在你的账户上有一个container，因为数据必须存在Container中。
Container取名上的限制是，它们不能包含“/”，而且长度上少于256字节。长度的限制也适用于经过URL编码后的名字。比如，Course Docs的Container名经过URL编码后是“Course%20Docs”，因此此时的长度是13字节而非11字节。
一个对象是基本的存储实体，和表示你存储在OpenStack Object Storage系统中文件的任何可选的元数据。当你上传数据到OpenStack Object Storage，它原样存储，由一个位置（container），对象名，以及key/value对组成的任何元数据。比如，你可选择存储你数字照片的副本，把它们组织为一个影集。在这种情况下，每个对象可以用元数据Album :
Caribbean Cruise 或Album : Aspen Ski Trip来标记。
对象名上唯一的限制是，在经过URL编码后，它们的长度要少于1024个字节。
上传的存储对象的允许的最大大小5GB，最小是0字节。你能用内嵌的大对象支持和St工具来检索5GB以上的对象。对于元数据，每个对象不应该超过90个key/value对，所有key/value对的总字节长度不应该超过4KB。
d)Operations
Operations是你在OpenStack Object Storage系统上执行的行为，比如创建或删除containers，上传或下载objects等等。Operations的完全清单可以在开发文档上找到。Operations能通过ReST web service API或特定语言的API来执行。值得强调的是，所有操作必须包括一个来自你授权系统的有效的授权令牌。
e)特定语言的API绑定
一些流行语言支持的API 绑定，在RackSpace云文件产品中是可用的。这些绑定在基础ReST API上提供了一层抽象，允许变成人员直接与container和object模型打交道，而不是HTTP请求和响应。这些绑定可免费下载，使用和修改。它们遵循MIT许可协议。对于OpenStack Object Storage，当前支持的API绑定是：PHP，Python，Java，C#/.NET 和Ruby。
5.2 Object Storage如何工作
a)Ring
Ring 代表磁盘上存储的实体的名称和它们的物理位置的映射。accounts, containers, and objects都有单独的Ring。其他组件要在这三者之一进行任何操作，他们都需要合相应的Ring进行交互以确定它在集群中的位置。
Ring用zones，devices，partitions，和replicas来维护映射，在Ring中的每个分区都会在集群中默认有三个副本。分区的位置存储在Ring维护的映射中。Ring也负责确定失败场景中接替的设备。（这点类似HDFS副本的复制）。分区的副本要保证存储在不同的zone。Ring的分区分布在OpenStack Object Storage installation所有设备中。分区需要移动的时候，Ring确保一次移动最少的分区，一次仅有一个分区的副本被移动。
权重能用来平衡分区在磁盘驱动上的分布。Ring在代理服务器和一些背景进程中使用。
b)Proxy Server
代理服务器负责将OpenStack Object Storage架构中其他部分结合在一起。对于每次请求，它都查询在Ring中查询account, container, or object的位置，并以此转发请求。公有APIs也是通过代理服务器来暴露的。
大量的失败也是由代理服务器来进行处理。比如一个服务器不可用，它就会要求Ring来为它找下一个接替的服务器，并把请求转发到那里。
当对象流进或流出object server时，它们都通过代理服务器来流给用户，或者通过它从用户获取。代理服务器不会缓冲它们。
Proxy服务器的功能可以总结为：查询位置，处理失败，中转对象。
c)Object Server
Object Server，是非常简单的blob存储服务器，能存储、检索和删除本地磁盘上的对象，它以二进制文件形式存放在文件系统中，元数据以文件的扩展属性存放。
对象以源于对象名的hash和操作的时间戳的路径来存放。上一次写总会成功，确保最新的版本将被使用。删除也视作文件的一个版本：这确保删除的文件也被正确复制，更旧的把本不会因为失败情形离奇消失。
d)Container Server
其主要工作是处理对象列表，它不知道对象在哪里，只是知道哪些对象在一个特定的container。列表被存储为sqlite 数据库文件，类似对象的方式在集群中复制。也进行了跟踪统计，包括对象的总数，以及container中使用的总存储量。
e)Account Server
它是类似于Container Server，除了它是负责containers的列表而非对象。
f)Replication
设计副本的目的是，在面临网络中断或驱动失败等临时错误条件时，保持系统在一致的状态。
副本进程会比较本地的数据和每个远处的副本，以确保他们所有都包含最新的版本。对象副本用一个Hash列表来快速比较每个分区的片段，而containe和 account replication 用的是Hash和共享的高水印结合的方法。
副本的更新，是基于推送的。对于对象副本，更新是远程同步文件到Peer。Account和container replication通过HTTP or rsync把整个数据库文件推送遗失的记录。
副本也通过tombstone设置最新版本的方式，确保数据从系统中清除。
g)更新器（Updaters）
有时，container 或 account数据不能被立即更新，这通常是发生在失败的情形或高负载时期。如果一个更新失败，该更新会在文件系统上本地排队，更新器将处理这些失败的更新。事件一致性窗口（eventual consistency window）最可能来起作用。比如，假设一个container服务器正处于载入之中，一个新对象正被放进系统，代理服务器一响应客户端成功，该对象就立即可读了。然而，container服务器没有更新Object列表，所以更新就进入队列，以等待稍后的更新。Container列表，因此可能还不会立即包含这个对象。
实际上，一致性窗口只是与updater运行的频率一样大，当代理服务器将转发清单请求到响应的第一个container服务器中，也许甚至还不会被注意。在载入之下的服务器可能还不是服务后续清单请求的那个。另外两个副本中的一个可能处理这个清单。
h)Auditors
Auditors会检查objects, containers, 和 accounts的完整性。如果发先损坏的文件，它将被隔离，好的副本将会取代这个坏的文件。如果发现其他的错误，它们会记入到日志中。
5.3 OpenStack Object Storage物理架构
Proxy Services 偏向于CPU和network I/O 密集型，而 Object Services， Container Services， Account Services 偏向于disk and networkI/O 密集型。
可以在每一服务器上安装所有的服务，在Rackspace内部， 他们将Proxy Services放在他们自己的服务器上，而所有存储服务则放在同一服务器上。这允许我们发送10G的网络给代理，1G给存储服务器，从而保持对代理服务器的负载平衡更好管理。我们能通过增加更多代理来扩展整个API吞吐量。如果需要获得Account或 Container Services更大的吞吐量，它们也可以部署到自己的服务器上。
在部署OpenStack Object Storage时，可以单结点安装，但是它只适用于开发和测试目的。也可以多服务器的安装，它能获得分布式对象存储系统需要的高可用性和冗余。
有这样一个样本部署架构，如图5-1所示。一个Proxy 结点，运行代理服务，一个Auth 结点，运行认证服务，五个Storage结点，运行Account，Container和Object服务。
5-1 五个Storage结点的OpenStack Object Storage物理架构
参考文献
[1] OpenStack Compute Administration Manual.
http://docs.openstack.org/cactus/openstack-compute/admin/content.
[2] OpenStack Object Storage Developer Guide.http://docs.openstack.org/.

Hadoop：
Hadoop实战
《Hadoop实战》作为云计算所青睐的分布式架构，Hadoop是一个用Java语言实现的软件框架，在由大量计算机组成的集群中运行海量数据的分布式 计算，是谷歌实现云计算的重要基石。《Hadoop实战》分为3个部分，深入浅出地介绍了Hadoop框架、编写和运行Hadoop数据处理程序所需的实 践技能及Hadoop之外更大的生态系统。
《Hadoop实战》适合需要处理大量离线数据的云计算程序员、架构师和项目经理阅读参考。
Hadoop权威指南
本书是您纵情享用数据之美的得力助手。作为处理 海量数据集的理想工具，Apache Hadoop架构是MapReduce算法的一种开源应用，是Google(谷歌)开创其帝国的重要基石。本书内容丰富，展示了如何使用Hadoop构建 可靠、可伸缩的分布式系统，程序员可从中探索如何分析海量数据集，管理员可以了解如何建立与运行Hadoop集群。.
本书完全通过案例学习来展示如何用Hadoop解决特殊问题，它将帮助您：
使用Hadoop分布式文件系统（HDFS）来存储海量数据集，通过MapReduce对这些数据集运行分布式计算..
熟悉Hadoop的数据和I/O构件，用于压缩、数据集成、序列化和持久处理
洞悉编写MapReduce实际应用程序时常见陷阱和高级特性
设计、构建和管理专用的Hadoop集群或在云上运行Hadoop
使用Pig这种高级的查询语言来处理大规模数据
利用HBase这个Hadoop数据库来处理结构化和半结构化数据
学习Zookeeper，这是一个用于构建分布式系统的协作原语工具箱
如果您拥有海量数据，无论是GB级还是PB级，Hadoop都是完美的选择。本书是这方面最全面的参考。
虚拟化:
 
 

Linux 既有良好的灵活性，在虚拟化方面同样出色。但是最近，随着内核虚拟机（KVM）的出现，Linux 虚拟化的前景发生了变化。KVM 是构成主流 Linux 内核（V2.6.20）一部分的第一个虚拟化解决方案。KVM 支持 Linux 客户操作系统的虚拟化 —— 甚至支持其硬件对虚拟化敏感的 Windows 系统的虚拟化。了解 Linux KVM 的架构并了解它与内核的紧密集成为何会改变您使用 Linux 的方式。
简介
虚拟化 概念很早就已出现。简单来说，虚拟化就是使用某些程序，并使其看起来类似于其他程序的过程。将这个概念应用到计算机系统中可以让不同用户看到不同的单个系 统（例如，一台计算机可以同时运行 Linux 和 Microsoft Windows）。这通常称为全虚拟化（full virtualization）。
虚拟化也可以使用更加复杂的格式，其中单个计算机看上去具有多个架构（对于一个用户 来说，它是一个标准的 x86 平台；对于另外一个用户来说，它是 IBM Power PC 平台）。这种虚拟化形式通常被称为 硬件仿真。
最后，更加简单的一种虚拟化是操作系统虚拟化，其中一台计算机可以运行相同类型的多 个操作系统。这种虚拟化可以将一个操作系统的多个服务器隔离开来（这意味着全都必须使用相同类型和版本的操作系统）。
虚拟化和准虚拟化（para-virtualization）
虚拟化最常使用的两种方法是全虚拟化 和准虚拟化。使用全虚拟化，在虚拟化的操作系统和硬件之间存在一个层，用于决定访问。这个层称为系统管理程序 或虚拟机监视器（VMM）。准虚拟化与之类似，但是系统管理程序会以一种更具协作性的方式进行操作。这是因为每个客户操作系统都了解自己正在虚拟化模式中 运行，因此每个系统都与系统管理程序协作，来实现底层硬件的虚拟化。
全虚拟化的例子包括商业虚拟化解决方案 VMware，以及商业 IBM zSeries 计算机上使用的 IBM System z9 Virtual Machine（z/VM）操作系统。准虚拟化的例子有 Xen 和 User-Mode-Linux (UML)。 KVM 也被认为是一个全虚拟化解决方案，不过我们稍后再介绍这个问题。
虚拟化的工作原理
我们首先简要介绍一下虚拟化技术及其涉及的元素。虚拟化解决方案的底部是要进行虚拟 化的机器。这台机器可能直接支持虚拟化，也可能不会直接支持虚拟化；那 么就需要系统管理程序 层的支持。系统管理程序，或称为 VMM，可以看作是平台硬件和操作系统的抽象化。在某些情况中，这个系统管理程序就是一个操作系统；此时，它就称为主机操作系统，如 图 1 所示。
图 1. 虚拟化的分层抽象
系统管理程序之上是客户机操作系统，也称为虚拟机（VM）。这些 VM 都是一些相互隔离的操作系统，将底层硬件平台视为自己所有。但是实际上，是系统管理程序为它们制造了这种假象。
目前使用虚拟化解决方案的问题是，并非所有硬件都可以很好地支持虚拟化。较老的 x86 处理器根据执行范围对特定指令会产生不同结果。这就产生了一个问题，因为系统管理程序应该只能在一个最受保护的范围中执行。由于这个原因，诸如 VMWare 之类的虚拟化解决方案会提前扫描要执行的代码，从而将这些指令替换为一些陷阱指令（trap instruction），这样系统管理程序就可以正确地处理它们。Xen 可以支持一种协作的虚拟化方法，它不需要任何修改，因为客户机知道自己正在进行虚拟化，并已经进行了修改。KVM 会简单地忽略这个问题，如果您希望进行虚拟化，就强制必须在更新的硬件上运行。
刚开始会觉得这有些不方便，但是考虑到目前上市的较新机器都可以支持虚拟化（例如 Intel VT 和 AMD SVM），用不了多久，这将成为标准方法而不是少数例外情况。
KVM 系统管理程序
考虑到虚拟化技术的发展时间并不长，KVM 实际上还是一种相对来说比较新的技术。目前存在各具功能的开源技术，例如 Xen、Bochs、UML、Linux-VServer 和 coLinux，但是 KVM 目前正在被大量使用。另外，KVM 不再仅仅是一个全虚拟化解决方案，而将成为更大的解决方案的一部分。
KVM 所使用的方法是通过简单地加载内核模块而将 Linux 内核转换为一个系统管理程序。这个内核模块导出了一个名为 /dev/kvm 的设备，它可以启用内核的客户模式（除了传统的内核模式和用户模式）。有了 /dev/kvm 设备，VM 使自己的地址空间独立于内核或运行着的任何其他 VM 的地址空间。设备树（/dev）中的设备对于所有用户空间进程来说都是通用的。但是每个打开 /dev/kvm 的进程看到的是不同的映射（为了支持 VM 间的隔离）。
KVM 然后会简单地将 Linux 内核转换成一个系统管理程序（在安装 kvm 内核模块时）。由于标准 Linux 内核就是一个系统管理程序，因此它会从对标准内核的修改中获益良多（内存支持、调度程序等）。对这些 Linux 组件进行优化（例如 2.6 版本内核中的新 O(1) 调度程序）都可以让系统管理程序（主机操作系统）和 Linux 客户操作系统同时受益。但是 KVM 并不是第一个这样做的程序。UML 很久以前就将 Linux 内核转换成一个系统管理程序了。使用内核作为一个系统管理程序，您就可以启动其他操作系统，例如另一个 Linux 内核或 Windows 系统。
KVM
安装 KVM 之后，您可以在用户空间启动客户操作系统。每个客户操作系统都是主机操作系统（或系统管理程序）的一个单个进程。 图 2 提供了一个使用 KVM 进行虚拟化的视图。底部是能够进行虚拟化的硬件平台（目前指的是 Intel VT 或 AMD-SVM 处理器）。在裸硬件上运行的是系统管理程序（带有 KVM 模块的 Linux 内核）。这个系统管理程序与可以运行其他应用程序的普通 Linux 内核类似。但是这个内核也可以支持通过 kvm 工具加载的客户操作系统。最后，客户操作系统可以支持主机操作系统所支持的相同应用程序。
图 2. 使用 KVM 的虚拟化组件
记住 KVM 只是虚拟化解决方案的一部分。处理器直接提供了虚拟化支持（可以为多个操作系统虚拟化处理器）。内存可以通过 kvm 进行虚拟化（这在下一节中将会讨论）。最后，I/O 通过一个稍加修改的 QEMU 进程（执行每个客户操作系统进程的一个拷贝）进行虚拟化。
KVM 向 Linux 中引入了一种除现有的内核和用户模式之外的新进程模式。这种新模式就称为客户 模式，顾名思义，它用来执行客户操作系统代码（至少是一部分代码）。回想一下内核模式表示代码执行的特权模式，而用户模式则表示非特权模式（用于那些运行 在内核之外的程序）。根据运行内容和目的，执行模式可以针对不同的目的进行定义。客户模式的存在就是为了执行客户操作系统代码，但是只针对那些非 I/O 的代码。在客户模式中有两种标准模式，因此客户操作系统在客户模式中运行可以支持标准的内核，而在用户模式下运行则支持自己的内核和用户空间应用程序。客 户操作系统的用户模式可以用来执行 I/O 操作，这是单独进行管理的。
在客户操作系统上执行 I/O 的功能是由 QEMU 提供的。QEMU 是一个平台虚拟化解决方案，允许对一个完整的 PC 环境进行虚拟化（包括磁盘、图形适配器和网络设备）。客户操作系统所生成的任何 I/O 请求都会被中途截获，并重新发送到 QEMU 进程模拟的用户模式中。
KVM 通过 /dev/kvm 设备提供了内存虚拟化。每个客户操作系统都有自己的地址空间，并且是在实例化客户操作系统时映射的。映射给客户操作系统的物理内存实际上是映射给这个进程 的虚拟内存。为了支持客户物理地址到主机物理地址的转换，系统维护了一组影子页表（shadow page table）。处理器也可以通过在访问未经映射的内存位置时使用系统管理程序（主机内核）来支持内存转换进程。
实例化新客户操作系统
新客户操作系统的实例化是由一个名为 kvm 的工具提供的。这个工具可以与 kvm 模块协同工作，使用 /dev/kvm 来加载客户操作系统，将它与虚拟磁盘（主机操作系统中的一个普通文件）关联起来，然后启动客户操作系统。
通过一组在 /dev/kvm 设备上执行的 ioctls 可以提供控制支持。当第一次打开这个特殊文件时，就会创建一个新的 VM 对象，它与一个虚拟 CPU 关联在一起。您然后可以使用几个 ioctls 来创建一个虚拟 CPU，检查 kvm 版本，创建内存区域，然后启动一个虚拟 CPU。您可以使用 kvm 命令实现这种功能。在接下来的几节中，我们将介绍 kvm 命令，并给出几个受支持的 ioctls 的示例。
使用 KVM
如果硬件支持的话，使用 KVM 实际上非常简单。您需要一个具有虚拟化支持的处理器。通过查看 /proc/cpuinfo 可以知道系统是否支持虚拟化。这个文件指定了是否支持 vmx（Intel）或 svm（AMD）扩展。
接下来，您需要一个启用了 KVM 支持的 Linux 内核。您可以在 Device Drivers > Virtualization 下的内核配置中完成这种配置。还必须启用处理器对环境的支持。另外，还必须具有 kvm 和 qemu 用户空间应用程序。
有了启用了虚拟化支持的引导内核，接下来的一个步骤是为客户操作系统创建一个磁盘映 像。您可以使用 qeumu-img 来完成此操作，如下所示。注意这个映像的大小是 4GB，但是使用 QEMU 的写时复制格式（copy-on-write，qcow）时，整个文件将根据需要增长，而不是完全占据这 4 GB 的空间。 $ qemu-img create -f qcow vm-disk.img 4G
复制代码在创建虚拟磁盘之后，就可以将客户操作系统加载到其上。下面的例子假设客户 操作系统是在 CD-ROM 上。除了使用 CD-ROM ISO 映像来填充虚拟磁盘之外，还必须在结束时启动这个映像。 $ kvm -no-acpi -m 384 -cdrom guestos.iso -hda vm-disk.img -boot d
复制代码Ari Kivity 已经编写了一组测试工具来测试 KVM，而不需要全部的设备模型。下面的代码片断（来自于 kvm-12/user/main.c）从较高的层次上查看了 VM 的启动（请参见 清单 1）。控制特性是由内核中的 ioctls 提供的（具体来说，在 ./linux-2.6.20/drivers/kvm/kvm_main.c 文件中）。
对 kvm_init 的调用会打开 /dev/kvm 设备，检查版本号（由 KVM 内核模块导出），然后分配一个 KVM 上下文对象并填充一些回调函数。kvm_create 函数会建立并映射两个内存区域，然后使用 ioctl（KVM_CREATE_VCPU）创建一个虚拟 CPU（VCPU）。
load_file 函数然后会将映像加载到给定的 VM 的地址空间中，然后调用 kvm_run 执行该 VM（使用 ioctl KVM_RUN）。尽管这个过程非常简单，但是它解释了如何使用 KVM 实例化新客户操作系统。
清单 1. 测试 KVM 系统管理程序的应用程序片断 int main()
{
void *vm_mem;
kvm = kvm_init(&test_callbacks, 0);
if (!kvm) {
fprintf(stderr, “kvm_init failedn”);
return 1;
}
if (kvm_create(kvm, 128 * 1024 * 1024, &vm_mem) < 0) { kvm_finalize(kvm); fprintf(stderr, “kvm_create failedn”); return 1; } if (ac > 1)
if (strcmp(av[1], “-32”) != 0)
load_file(vm_mem + 0xf0000, av[1]);
else
enter_32(kvm);
if (ac > 2)
load_file(vm_mem + 0x100000, av[2]);
kvm_show_regs(kvm, 0);
kvm_run(kvm, 0);
return 0;
}
KVM 是解决虚拟化问题的一个有趣的解决方案，但是由于它是第一个进入内核的虚拟化解决方案，很难想象它会很快用于服务器虚拟化。还有其他一些方法一直在为进入 内核而竞争（例如 UML 和 Xen），但是由于 KVM 需要的修改较少，并且可以将标准内核转换成一个系统管理程序，因此它的优势不言而喻。
KVM 的另外一个优点是它是内核本身的一部分，因此可以利用内核的优化和改进。与其他独立的系统管理程序解决方案相比，这种方法是一种不会过时的技术。KVM 两个最大的缺点是需要较新的能够支持虚拟化的处理器，以及一个用户空间的 QEMU 进程来提供 I/O 虚拟化。但是不论好坏，KVM 位于内核中，这对于现有解决方案来说是一个巨大的飞跃。

KVM:Kernel-based Virtual Machine的简写，是rhel5.4推出的最新虚拟化技术，目前红帽只支持在64位的rhel5.4上运行kvm,同时硬件需要支持VT技术，使用kvm虚拟机的时候需要关闭SELinux;
Red Hat从2009年6月中旬开始在部分企业级用户那里开始了对Red Hat Enterprise Virtualization(RHRV)的beta测试。RHEV是Red Hat去年收购虚拟化厂商Qumranet获得的一项hypervisor技术。Citrix通过收购获得的Xen就是因为Linux hypervisor而被人们所熟知。不过Red Hat的KVM被认为是将成为未来Linux hypervisor的主流。　Red Hat产品和技术总裁Paul Cormier表示：“KVM最大的好处就在于它是与Linux内核集成的。未来几年人们的关注焦点仍然集中在hypervisor上。hypervisor是操作系统的一项功能，自然能够被用户所接受。微软和Red Hat操作系统的不同中间件和管理功能将起到重要的作用。”
从Linux 2.6.20开始内核中已经开始集成KVM。因此，由Fedora社区开发的Fedora也开始支持KVM。Linux 2.6.20之后的Linux发行版本的内核中也都将KVM作为基本的hypervisor。
Red Hat从进行beta测试的Red Hat Enterprise Linux(RHEL)5.4也开始装载了KVM。Red Hat日本营销本部部长中井雅也先生解释说：“为了确保企业用户的稳定性，我们进行了严格的beta测试。这对与开源社区合作的Red Hat来说是很不寻常的。由此看来，这表明Red Hat非常重视KVM基本的虚拟化性能。”
Xen和kvm一样，都是虚拟化开源软件，拥有同样出色的架构设计和性能。Xen和kvm都用于构建IaaS层。