《VMware vSphere设计（原书第2版）》——第2章 ESXi hypervisor

本节书摘来自华章出版社《vmware vsphere设计（原书第2版）》一 书中的第2章，第2.1节，作者：[美] 福布斯·格思里（forbes guthrie）斯科特·罗威（scott lowe）肯德里克·科尔曼（kendrick coleman），更多章节内容可以访问云栖社区“华章计算机”公众号查看。

vsphere 5的 host上运行了一个独立且统一的hypervisor操作系统。hypervisor是一个软件，它虚拟化了host的硬件并提供给guest操作系统使用。vsphere host被称为类型1（type 1）hypervisor或者裸机（bare-metal）hypervisor。与类型2（type2，或者宿主的）hypervisor不同，type 2 hypervisor运行在标准的操作系统（windows或linux）之上。类型1 hypervisor直接运行在物理硬件上，不需要中间的操作系统。这样它就能够直接访问硬件，消除了在中间操作系统上运行的性能开销，且避免了由于在stack上增加一层（中间操作系统）而引起的安全性和稳定性问题。

vmware vsphere hypervisor

“vmware vsphere hypervisor”其实是一个营销用语，特指esxi的单机版。你可以在vmware官网上免费下载。它是hypervisor的受限版本，是不能被vcenter实行管理的。通过api实现的远程连接也是只读的，这就限制了第三方软件（例如备份和克隆工具）的使用。host的内存也被限制在32gb内。vmware vsphere hypervisor是对市场上其他免费hypervisor的直接回应，刚开始研究虚拟化的管理员们将它作为一个跳板。

本书中谈到“vsphere hypervisor”或者“esxi hypervisor”时，指的并不是这个免费版本。而是指有vsphere授权许可的正式“hypervisor”。

vmware在2001年发布了gsx（类型2）和esx（类型1）两个产品。2006年，vmware gsx更名为vmware server，并于2011年停止提供技术支持。它和vmware的其他驻留产品（如workstation、player和fusion）同族。而esx企业级hypervisor一直稳步发展至今，vmware分别在2009年和2010年发布了4.0和4.1版本。

2007年12月发布esx 3.5的时候，vmware还发布了第一个esxi版本esxi 3.5。这是esx模型首个重要分支。自此，vmware开始同时发布esx和esxi，直到vsphere 5到来。从esxi第一个版本开始，vmware就从来没有掩饰过这个事实：他们要用esxi取代esx。发布esx 4.1的时候，vmware即声明这将是esx的最后一个版本，以后所有的vsphere hypervisor都是基于esxi的。vsphere 5.0敲响了esx的丧钟，鸣起了esxi时代的号角。

为了给vsphere host一个响亮的名字，vmware开始称esx为传统esx以区别于它的同胞esxi。虽然它们的管理设计完全不一样，但是esx和esxi的相同之处远远大于其差异处，因为它们的hypervisor是基于相同底层代码的。

除了免费的单机版esxi外，传统esx 和esxi的售价和授权都是一样的。传统esx 和esxi的host可以在同一个集群中共存，且可以在虚拟机间共享资源。除非有host的实践操作经验，否则在用客户端连接到vcenter的时候，是无法发现二者的区别的。虚拟机管理员、存储或网络团队，以及it经理们可能不会在意这些差异。但是，作为设计或管理vsphere host的人，你肯定会对这些不同点感兴趣。

vmware曾公开表示esxi是企业裸机虚拟化的必然选择。现实情况是esx已经没有前途了，越快切换到esxi，那么在开发流程和支持已经走到尽头的产品上浪费的成本就越少。

传统esx包括三个主要元素，这些元素运行在物理硬件上，为guest操作系统提供虚拟化环境。其中两个的类似版本： vmkernel和虚拟机监视器（virtual machine monitor，vmm）还存在于esxi中。第三个service console就是传统esx和esxi的关键区别：esxi中已经没有service console了。

service console也叫控制台操作系统（console operating system，cos）或vmnix，是esx host的命令行接口和管理控制台。它是red hat linux企业版的改良版，允许以普通用户权限访问vmkernel。虽然service console中可能安装了硬件驱动，但它不能直接访问物理服务器和硬件组件。它促使脚本、基础设施、硬件和第三方代理能够运行。

esxi概念

service console的移除从根本上改变了vmware的hypervisor的能力。esxi 的消耗很少，也就是说esxi比esx占用的磁盘空间小很多，无论是本地硬盘还是网络硬盘。esx host的service console是作为一个单独的vcpu guest运行的，这就意味着它所有的进程都是串行运行的，而在esxi中，原service console的功能都移到vmkernel中了。这样，在更加精细的调度算法下，进程就可以并行运行了。

esxi简化的代码库有一个明显的优势，就是它带来了更高层次的安全性。esx的安装包有2gb，而esxi只有不到125mb。不难看出代码越少意味着要防范的攻击途径就越少。service console的存在，产生了额外需要保证安全性的代码。而esxi没有这个组件，就免去了相应的麻烦。

esxi的补丁也比esx少，从而减低了host服务器重启的频率，减少了管理员定期打补丁的工作量。拥有大量esx host的大型企业里一定少不了没完没了的host打补丁工作。相对于esx的多个且比较大的补丁文件，esxi只有一个相对较小的补丁文件。当host遍布多个站点时，特别是在wlan网络缓慢导致vcenter update manager（vum）无法推送大的补丁文件的情况下，esxi的打补丁工作也是很容易的。esxi补丁的另一个优势就是它是单个的类似于固件的镜像，可以同时更新所有组件。而esx的补丁是分多次更新的，每个补丁都依赖于前一个补丁，且需要重启多次。

esxi的host也比传统esx 的host可靠得多。它的代码比较少，运行在虚拟机上的进程也比esx少，因此出错的几率也低些。service console能支持第三方代理的能力其实是把双刃剑，虽然它增加了额外的功能，但这些代理也会给host带来不稳定因素。esxi则不允许运行其他代理，所以也就无需顾虑因第三方代理引起的问题。此外，esxi的双镜像本质表明当出现更新问题的时候，总会有一个备用的可引导的系统来进行回滚操作。

esxi可以让host在无状态模式下运行，也就是说host服务器更趋向于硬件设备。esxi的部署技术和esx的类似，只是安装会简单得多。安装时系统弹出的信息很少，安装时间也短了很多。你也不需要了解posix文件系统和技术细节，以及如何分区最好。甚至服务器重启的时间，esxi都会比传统esx短得多。

host管理被简化了，配置和排查错误的时候也不需要懂service console，这就降低了安装和维护新vsphere环境的工程师们的技术门槛。简单的direct console user interface（dcui）界面和bios的安装界面类似，不熟悉linux的工程师也不会头疼。如果问题发生在异地办公室且没有远程访问卡和kvm（键盘、视频和鼠标keyboard、video和mouse）切换器，此时比较灵活的做法就是让当地的员工帮忙重启管理进程。

esxi的优点太多了，所以很明显它不仅是vmware的产品发展的绝佳选择，也是企业用户发展虚拟化的一个明智之选。尽管还有很多传统esx准备迁移到esxi，但最明智也是唯一的选择还是部署esxi。由于vsphere固有的抽象性，迁移的工作量很少且很容易。