本节书摘来自华章出版社《VMware vSphere设计（原书第2版）》一 书中的第2章，第2.2节，作者：[美] 福布斯·格思里（Forbes Guthrie）斯科特·罗威（Scott Lowe）肯德里克·科尔曼（Kendrick Coleman），更多章节内容可以访问云栖社区“华章计算机”公众号查看。
2.2 ESXi设计
ESXi hypervisor和传统ESX有很多共同元素，但是它与ESX之间最大的区别就是移除了基于Linux的Service Console。ESXi保留了与ESX类似的VMkernel和VMM组件，在VMkernel中增加了一些特性，增加了一个新的且比较小的管理控制台，以及一些用户模式进程以取代老的Service Console 操作系统的功能。
ESXi这样重新设计是为了让VMware用户能够像处理硬件设备一样，通过hypervisor实现横向扩展。愿景是实现一个基础操作系统，让它能够自动配置，远程接收配置信息，从内存运行而不是从硬盘运行。但它仍然是一个足够灵活的操作系统，支持不需要额外设施的小巧且随时可用的安装：安装到本地硬盘上，且保留本地保存的状态和用户定义的设置。
当然，移除Service Console还是有一定负面影响的。很多以前安装的服务和代理需要重新考虑如何处理。在ESXi中，ESX用户熟悉的可以用于管理、排错、配置的命令行工具已经被其他工具取代了。原来ESX中用于备份、监控硬件的Linux风格的第三方代理也需要用其他方式取代。
2.2.1 ESXi组件
ESXi操作系统建立在三个层次上，能够实现和传统ESX一样的虚拟机环境，但是在架构上与传统ESX有显著差别：
VMkernel VMkenel是ESXi的基础，且是为ESXi专门设计的。它是64位的POSIX 操作系统的微内核。VMware设计并不是为了打造一个普通的操作系统（译者注：即2型操作系统），而是一个能够作为hypervisor的操作系统。VMkernel管理物理服务器的硬件，协调所有CPU的资源调度和内存分配，控制磁盘和网络的I/O stack，处理所有符合HCL（Hardware compatibility list，硬件兼容性列表）的设备驱动。
VMkernel Extensions 除了VMkernel外，还有很多Kernel模块和驱动。这些扩展使得操作系统能够通过设备驱动与硬件交互，支持不同的文件系统，以及允许其他系统调用。
Worlds VMware把它的可调度用户空间称为worlds。这些worlds允许内存保护、与CPU调度共享，以及定义separation权限基础。worlds有如下三种类型：
系统worlds 系统worlds是特殊的内核模式的worlds，能够以系统权限运行进程。例如：idle和helper进程都是以系统worlds运行的。
VMM worlds VMM worlds用户空间的抽象，它让每个guest操作系统都能够看到自己的x86虚拟硬件。每个虚拟机都运行在由它自己调度的VMM world中。它将硬件（包括BIOS）呈现给每个虚拟机，分配必需的虚拟CPU、 内存、硬盘、虚拟网卡等。它还决定了每个虚拟机的监控模式，这取决于服务器的物理CPU和guest操作系统的选择。在完全虚拟化（二进制转化）和硬件辅助虚拟化之间选择（半虚拟化监控器，也叫VMI（Virtual Machine Interface）在vSphere 5.0中已经不存在了）。
用户worlds 用户worlds指所有不需要以系统world赋予的权限来执行调用命令的进程。它们可以执行系统调用来与虚拟机或整个系统交互。
重要（且可以将ESXi与其他普通操作系统区别开来）的一点就是系统引导的时候它是装载到内存中的。用户空间的worlds是永远不会交换到硬盘中的。但是，可以通过资源池，像控制虚拟机一样控制这些worlds。它们可以申请、共享或限制CPU和内存。这体现了ESXi相对于传统ESX的优势。在传统ESX中，Service Console是以一个world运行的，且一个Service Console代理会占用大量内存从而影响到其他进程。这就是为了阻止交换hostd进程，Service Console内存经常会增到最大值的原因。在ESXi中进程得到了更好地保护，不会存在这个问题。
2.2.2 ESXi代理
VMkernel有几个值得关注的代理或进程：
hostd hostd（由mgmt-vmware服务管理）是主要的管理进程。它负责与VMkernel交互，是直接vSphere客户端和远程API调用之间的联系点。hostd还包括默认的SNMP代理（默认是禁用的）。
vpxa vpxa使得vCenter实例可以连接到VMkernel。当首次将host ESXi服务器连接到vCenter时，它会启动vpxa进程，作为vpxuser账号下VMkernel功能之间的媒介。
syslog syslog进程可以将日志转发到远程syslog服务器上。
ntpd ntpd进程提供时间服务以保持host和时间服务器的时间是同步的。保持时间同步很重要，这是因为服务器之间的几个服务，比如高可用性（HA）和基于目录的校验服务都是依赖于准确的时间同步的。你也可以设置虚拟机使guest操作系统的时间与本地host同步。
DCUI DCUI是BIOS分割的黄色界面，显示在服务器控制台窗口。通过它你可以进行基本的配置、设置访问权限、重启服务代理等。
sfcbd sfcbd进程是CIM（common information model）代理，它通过一个可以外部访问的API以无代理的方式访问硬件监控。这样就降低了对第三方硬件代理和SNMP的依赖。
ESXShell ESXi Shell（technical support model，TSM）以ESXShell进程的形式运行，提供一个简单的命令行工具、一个本地控制台可以使用ESXCLI工具包（esxcli）、其他CLI工具（如vmkfstools）、 esxcfg-* 命令（ESXCLI的替代），以及实时进程监控工具esctop。
后续会详细介绍最后三个进程，以展示这三个进程在host管理方面中所发挥的作用。
2.2.3 ESXi系统镜像
在介绍ESXi设计的安装和部署选项前，有必要先了解ESXi镜像的结构。系统镜像（system image）是个可引导的镜像，它被加载到内存中然后以hypervisor的形式运行。ESXi安装程序使用这个系统镜像将文件拷贝到可引导设备中（/bootbank分区）。首次引导后，镜像会自动发现硬件并根据所选的安装类型执行自动配置。系统镜像可以通过CD、PXE、本地硬盘、USB存储设备（U盘或SD卡）、FC、FCoE和iSCSI SAN 等多种渠道引导。
除了一些用来引导ESXi的文件外，ESXi系统镜像主要包括以下两类文件：
VMkernel可执行文件 这些可执行文件都是压缩文件，它们一起构成了VMkernel。你可以根据.gz扩展名来组织它们。加载ESXi后，这些文件不会在文件系统中显示。
归档文件 归档文件构成了可见的文件系统。它们是由很多扩展名为.bgz、.v0n或者.tgz的 VIB（VMware Installation Bundle）文件。
解压缩每个VIB后，都会被覆盖添加到文件系统中。连续解压缩所有归档文件后，只有最新的变更是可见的。如果删除了一个归档文件，那么在文件系统中就会显示它的上一个归档文件。
最后一个被解压缩的归档文件叫作状态归档（state archive）state.tgz。这个归档中包含所有配置信息，例如/etc文件。在ISO镜像文件里是找不到这个状态归档的，因为那时候（引导前）是没有非默认配置的，配置都是在初始化的时候创建的。为了避免对引导磁盘的过度磨损（可能是基于flash的），配置变更发生时，这些更新会直接更新到硬盘中。这个更新动作每10分钟发生一次，每小时不会超过6次。这就意味着host崩溃后有些变更可能无法恢复（虽然重启前会有硬盘更新的过程）。这个归档文件tardisk是日常备份与恢复的基础。
由于镜像是被装载到内存中的，因此运行时并不依赖于引导设备。这表明引导设备故障或者断开连接时，操作系统都会正常运行。针对文件系统但不会修改系统镜像的变更在重启后会丢失。因此所有添加组件和配置的变更必须更新到镜像中，以确保其永久性且能够被重新装载。
ESXi仅认可授权的代码，而且这些模块必须有VMware 的数字签名。这个关于VMkernel扩展的限制保证了环境的安全性、保全了系统资源和确保了代码库的严格性。
供应商镜像
主要的服务器供应商会定制自己的系统镜像。这些ISO镜像都是常规VMware系统镜像的增强版（包含硬件方面的扩展）。其中会包含新的或改进的硬件驱动，以及可以提供更好的硬件监控和支持信息的CIM插件。
2.2.4 ESXi自定义镜像
你也可以定制自己的ESXi镜像。这个是很有帮助的，因为VMware提供的常规系统镜像可能会过期。虽然VMware会发布补丁，但只有在更新较少的情况下才会发布新的镜像。通过定制自己的镜像，可以将镜像流分成多个补丁。此外，标准的系统镜像并不会包含所有的驱动或硬件CIM提供程序（provider），或者即使包含了也是过期的，需要更新。对于刚发布的新硬件，用标准的镜像可能无法安装，这是因为其中没有相应的驱动。还有一些插件，比如HA代理，通常它们都是通过vCenter推送安装的，以及一些第三方解决方案，都可以通过自定义的方式添加到镜像中。
为了满足自定义ESXi镜像的需求，VMware在vSphere 5中发布了一个新的工具Image Builder。Image Builder是一套PowerCLI小命令，它将安装包一起打包到自定义的ISO镜像中，并填充到一个专门的镜像发布容器（软件仓库）中。Image Builder使用三个不同的组件来创建自定义ESXi镜像：
VIB VIB是ESXi组件的安装包，它的文件扩展名是.vib。VIB是个压缩文件，类似于tarball，其中包括载荷（例如，软件、插件或者驱动）、一个描述文件和一个签名文件。描述文件中包含很多重要信息：此VIB依赖的VIB（这些VIB必须先于此VIB安装）、与其他VIB间的冲突、此VIB是否会取代以前的VIB、是否需要重启host或者进入维护模式，以及它的验收等级（acceptance level）。签名文件是用于验证验收等级的数字证书。
Image Builder工具有四个验收等级：VMwareCertified、VMwareAccepted、PartnerSupported和CommunitySupported。每个VIB都属于某个等级，当Image Builder创建自定义镜像的时候，这个镜像不会接受任何高于最低VIB级别的验收等级。这保证了一个镜像的验收等级以最低验收等级的组件为准。
VIB Author
VMware提供一个叫VIB Author的工具，使用这个工具可以很容易地创建community supported级别的VIB。
Image Profile Image profile定义了由Image Builder创建的ESXi镜像中所包含的包。建好镜像后，就可以创建image profile、添加VIB了。更直接的方法就是克隆已有的image profile，然后根据要添加或删除的VIB进行调整。你可以为不同的硬件或不同的配置创建和维护多个image profile。例如，不同的服务器模型/生产商，是否带有VMware工具、第三方插件、HA代理等。从vSphere 5.1开始，镜像中已包含FDM（Fault Domain Manager）代理。
除了每个VIB的验证等级外，image profile也有验证登记。所有VIB的验证登记必须等于或高于image profile的验证登记，否则就无法添加VIB。当将VIB添加到image profile中时，它的依赖和冲突也要遵从这个原则。
Software Depot 除了自定义镜像前可以创建并添加VIB外，服务器供应商和OEM硬件厂商也可以提供VIB文件以表示对其硬件的特殊支持，其中包括驱动和CIM插件。
VIB本身是可以被分发的，但是前提是必须先通过命令行工具或图形界面的VUM安装。供应商则通常会选择通过software depot来分发它们的产品。Software depot将VIB组成一个软件包，这个包可以被Image Builder直接使用。Software depot就是一个VIB或者一个VIB集合，再加上一些额外的包含在Zip文件中的元数据。这是一个很好的分发软件包方式，因为它提供了多样化的安装选项。Software depot包含VIB而不是基本的ESXI VIB，它有时候会被叫作software bundles以避免误认为只是对核心镜像的简单增加。
Software depot有两种使用方式：离线和在线。离线 software depot只是一个Zip压缩文件，很像是一个包含ESXi镜像的software bundle。用Image Builder时需要使用software depot，此时选一个本地的Zip文件就可以很快开始了。也可以使用在线的software depot，它和基于文件的离线版本中包含的内容相同，不过是安装在一个Web服务器上的。大多数主流供应商会搭建他们自己的在线software depot，这样就可以通过Internet访问了。使用在线depot还有一个优势，就是无论什么时候想创建一个新的镜像，都可以直接从供应商的工具上自动获取最新的版本。但是这样你就会受制于供应商来掌握其他组件的最新动态。你可以使用VUM中的在线depot，注册到供应商的网站，然后允许VUM发现新的软件版本时给你发送通知。
VMware还提供它自己的sofware depot，包括离线的Zip文件和基于Web的软件库。如果没有要创建的镜像中服务器硬件所需的定制depot，那么你可以使用VMware的基础镜像。VMware提供了两类镜像：标准镜像（完整版）和去掉VMware工具的镜像（简化版）。标准镜像的大小几乎是后者的两倍。知道要如何使用镜像就知道要选择哪个了。可以看出，完整版适合ISO方式的安装，简化版适合自动部署。如果你选用简化版，则还需要为VMware Tools搭建一个可以全局共享的服务，并且将所有host都指向这个服务。
Software depot一直是用Image builder创建镜像时所需的必要输入。Image Builder创建的镜像可以用于常规安装或升级的ISO文件，也可以转换成可供VUM、CLI安装或自动部署服务器使用的软件格式。
Image Builder 使用流程
Image Builder是一个PowerShell命令集合，需要在PowerCLI中执行命令来创建自定义镜像。这些命令会用到VIB、image profile和software depot。生成的ESXi镜像可以是用于交互式脚本安装的ISO文件，也可以是自动部署准备包。
用Image builder创建自定义镜像的基本流程如下（其中使用的命令为主要命令，真正执行时还需要增加相应的开关和参数）：
- 将software depots导入/连接到Image Builder（Add-EsxSoftwareDepot）。
- 创建Image profile，制定所需的基础VIB。或者克隆现有的profile（New-EsxImage-Profile）。
- 根据需要添加/删除VIB（Add-EsxSoftwarePackage或Remove-EsxSoftwarePackage）。
- 将image profile导出到打包的ISO镜像或depot文件镜像中（New-EsxImageProfile）。
创建自定义镜像的备选方案
创建自定义镜像还存在一些第三方备选方案。除了直接从服务器供应商处直接获取定制的镜像外，可以用于自定义镜像的一个方案就是使用ESXi-Customizer这个工具（http://v-frontde/p/esxi-customizer.html）。这个GUI工具就是一个简单的脚本，通过它可以将VIB和software bundle添加到ISO镜像中。这是一个免费工具，但VMware并不支持它。如果只是想将一两个RAID控制器添加到一个服务器可以从中成功引导的ISO文件中，那么这就是个便捷的方案，无需费力去研究PowerCLI命令了。
如果不是真正需要，那么创建自定义镜像是不值得的。如果大型企业有很多服务器或者需要频繁地重构服务器，那么就会从自定义镜像中受益。但是对于大多数公司来说，标准的VMware ISO镜像和供应商定制ISO镜像就已经足够了。
2.2.5 ESXi硬盘布局
ESXi引导后会被加载到内存中，并在内存中运行。在内存中，它会使用tardisk（静态文件的归档文件）和ramdisk（内存虚拟硬盘文件，在使用过程中会不断增长或减少）。除了tardisk和ramdisk外，在内存中还会找到一些硬盘分区。ESXi的部署方式和部署后硬件的发现方式决定了会有哪些额外的分区以及这些分区的存储位置。如果存在额外的分区，那么它们会被挂载到文件系统中。安装时无法手动设定分区。但是，如果存在分区的话，那么内存中的备份文件会比较多。本章后续内容会有关于ESXi部署选项的详细介绍。在此，我们主要介绍最流行的类型可安装ESXi镜像是如何被拷贝到本地硬盘的，因为这个类型涉及所有可能的分区。典型的分区布局如图2-1所示。
新的ESXi 5 build版本使用一个GPT（GUID Partition Table）分区表，而上一版本使用的是老的MBR（Master Boot Record）分区方式。要查看分区列表，请执行paredUtil命令，而不是之前的fdisk。
System 磁盘开始部分是一个只有4MB的引导分区，这个系统盘负责引导两个bootbank中的一个。
Bootbank Bootbank分区是主要的系统镜像。这个分区挂载在文件系统的/bootbank目录下。这个分区中的镜像，特别是s.v00文件，在引导时被解压到内存中，称为文件系统的根目录。
Alt Bootbankalt Bootbank分区是为备份镜像预留的分区。升级时如果发生故障就可以使用这个备用的bootbank。其中存储了“最后一次正确配置”来作为故障保险。引导时，按Shift+R可以回到这个选项。这个分区被挂载在文件系统的/altbootbank目录下。
vmkDiagnostic 当host因紫屏（Purple Screen of Death，DSOD）故障崩溃时，核心内存转储信息就存储在这个分区中。排查故障时，可以检索和分析这些信息。一般情况下，这个分区是空的，也不会被挂载到文件系统中。
Store Store分区保存了VMware工具的ISO文件和要挂载到虚拟机上的驱动软盘镜像。它还用于存储所有辅助文件。store分区被挂载在/store目录下。./locker通过符号链接连接到这个目录。
Scratch Scratch分区是一个4GB的VFAT（virtual file-allocation table）分区，如果首次引导时本地磁盘大于5.2G，那么常规安装时默认会创建这个分区。Scratch分区保留状态归档并捕捉运行时状态文件，如日志和诊断包（vm-support，排查故障时可以创建）。userworld的交换也在这里进行。如果没有scratch分区，也没有可替代的本地分区，那么scratch目录就会被重新定向到ramdisk的/temp/scratch目录。这意味着scratch分区的内容重启后就消失了，而且最多有4GB的内存可以用来存储这些文件。
如果本地引导硬盘或另一个本地硬盘上还有剩余空间，ESXi就会创建scratch分区。如果没有剩余空间，ESXi会尝试在本地VMFS（virtual Machine File system）数据存储（如果有的话）中创建一个目录。如果失败的话，就使用ramdisk。如果安装程序无法创建scratch分区，那么你可以将它重新定向到永久的VMFS或NFS卷中（虽然VMware并不推荐使用NFS卷）。即使有剩余空间，ESXi也不会将scratch分区创建在远程硬盘（即“boot from SAN”逻辑单元数和被标记为远程的SAS硬盘），也不会创建在USB存储器或SD卡上，这是因为来自userword交换的大量I/O会损坏这些设备。
VMFS数据存储 如果首次引导时有足够的空间，ESXi就会创建VMFS-5 数据存储。这个数据存储大小就是引导磁盘的剩余空间。
2.2.6 Tardisk 和Ramdisk
ESXi使用tardisk和ramdisk来创建文件系统。系统一启动，tardiak就会以目录的形式挂载在基础VMkernel的tardisk（被解压缩到内存中）上。不同于常规的文件系统，ESXi不会解压tardisk然后使用解压后的文件副本，而是保持tardisk的原貌，就像硬盘一样挂载它们。上节介绍的物理分区也会被挂载到文件系统中。执行ls –lah命令就可以看到每个目录的符号链接，这些目录都会被重新定向到指定的分区（这是一个检查本地分区、VMFS或ramdisk中是否有/scratch目录的简单方法）。系统引导时tardisk会被依次放到文件系统中，一旦这个过程结束，文件系统就安装好了（可以通过ESXi Shell查看或操作这个文件系统）。Tardisk是只读的，无法修改。镜像中的tardisk可以覆盖但不能修改正在运行的文件系统中的tardisk。
ramdisk存储ESXi运行时创建和修改的文件。例如，需要维护的配置和日志文件。如果需要修改tardisk中的某个文件，ESXi就会用分支技术在ramdisk上创建一个它的副本。这个技术广泛应用于/etc 文件夹。用文件粘滞位来指定这个文件可以通过分支技术来创建分支。但是这些修改是无法写回到tardiak文件中的，因为tardiak文件是只读的。所以为了保留这些信息，它们会被写到状态文件state.tgz文件中（实际上大多数文件会存储在state.tgz里面的local.gz中）。
