2.1 vSphere hypervisor的发展史
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固有的抽象性，迁移的工作量很少且很容易。