本节书摘来自华章出版社《VMware vSphere设计（原书第2版）》一 书中的第2章，第2.3节，作者：[美] 福布斯·格思里（Forbes Guthrie）斯科特·罗威（Scott Lowe）肯德里克·科尔曼（Kendrick Coleman），更多章节内容可以访问云栖社区“华章计算机”公众号查看。
2.3 ESXi部署
ESXi的部署方式有很多，而且可以根据所在环境，灵活的动态选择配置选项。这样就会有多个部署选项，每个选项都有细微差别以适应不同的场景。这样不同的硬件环境就需要不同的交付机制，其结果就是ESXi服务器的基础设计应运而生。
2.3.1 硬件需求
安装ESXi需要考虑多个因素。首先，硬件要满足需求规格，还要验证每个组件是否在HCL内。第4章将详细介绍硬件需求。其最基本的要求就是：服务器的CPU是64位的 x86 CPU，至少2GB内存和1GB引导磁盘空间，这是完成本地安装的最低要求。
2.3.2 ESXi类型：可安装ESXi、嵌入式ESXi和无状态ESXi
ESXi的不同类型表明了不同的部署方式。可安装ESXi是最普通的，它允许你在自己的服务器硬件上安装hypervisor；嵌入式ESXi是OEM形式的，即你可以选择购买一个预安装ESXi的服务器；无状态ESXi即每次host都是从一个叫作Auto Deploy的PXE 服务引导的。
下面研究下这三种类型并讨论这三者是如何影响到host部署和hypervisor选择的。
可安装ESXi
可安装ESXi不是预安装在服务器上的，你可以自行安装。安装时有很多选项，不管名称是什么，你都可以引导和运行它，而不需要安装到本地硬盘。
ESXi与其他操作系统部署的显著区别就是它的系统镜像会被拷贝到安装位置，本质上没有安装东西。这使得部署过程非常快。ESXi可安装部署的主要涉及因素如下：
引导安装程序 你可以从多个位置引导ESXi安装程序。最常用的方法就是：从VMware官网下载安装程序，再刻一张引导CD，然后从CD引导服务器。服务器也可以从USB引导（只要服务器的BIOS支持从USB引导）或者通过PXE从服务器的网卡引导。以上任何方法都可以利用Image Builder创建的自定义镜像，而不是从VMware的vanilla下载。
服务器启动进行上电自检时将唤起PXE引导。通常需要敲特殊的键，或者如果服务器在自己的存储设备上没有找到合适的可引导的镜像，它就会自动尝试寻找PXE服务器。网卡发送广播信息来寻求适合的PXE服务器的响应。如果找到了，PXE服务器就会响应请求并可以将其配置成ESXI的引导设备。PXE服务器提供了一个在LAN环境下方便集中存储安装介质的解决方案。如果在一个地方有多个服务器，那么就可以使用基于PXE的ESXi介质库来加速安装，这是因为在构建或重构构建时，不需要从物理上访问所有的服务器。然而，在WAN下有多个站点，你可能需要在每个地点部署PXE服务器。通过WAN连接安装几百MB的操作系统是不太现实的。这样安装起来会很慢，还会占满WAN带宽，还很可能导致安装失败。
可安装的部署还可以从Auto Deploy服务器开始。接下来的Auto Deploy小结会详细介绍这部分内容，这个方法主要用于部署无状态服务器。但是从vSphere 5.1开始，Auto Deploy也可以用来进行有状态安装。有状态安装使用Auto Deploy做PEX服务，并将镜像拷贝到目的地来作为可安装的镜像。不同于无状态安装的是，有状态安装不会继续从Auto Deploy服务器引导，而是仅仅使用这个环境作为部署工具。一旦将镜像拷贝到目的地，这就已经是一个可以安装的ESXi镜像了。
安装指导 你可以通过交互模式安装，也可以使用应答文件通过脚本安装。
交互安装 交互模式是默认的安装方式，是一个简单的文本界面的程序。软件安装好后，你可以在服务器控制台（或通过远程硬件控制台，如Integrated Lights Out [iLO]）、Remote supervisor adaptor（RSA）或Dell RemoteAccessCard（DRAC）中选择不同的选项，文本界面的安装程序如图2-2所示。
传统ESX的交互式安装和大多数现在操作系统的安装默认都是基于图形界面的，而ESXi的交互式安装更加简单，其中没有复杂的分区问题，也没有多少选项需要你去了解。
脚本式安装 除了交互式安装外，你还可以制定一个文件来提供自动安装选项的答案。你可以将这些答案保存到一个文本文件中，然后在开始安装的时候选择这个文件作为脚本的输入。ESXi应答文件的语法模仿了Redhat kickstart的脚本，它设置的默认名字就是ks.cfg。脚本安装和交互式安装的结果是一样的。Kickstart脚本可以存储在CD、USB存储设备中，或通过FTP、HTTP、HTTPS或NFS导出。
基于kickstart脚本的安装有以下好处：
当需要重新构建服务器的时候，脚本式安装是个绝好的可重复的过程。
使服务器的构建和重新构建更快。
可以创建能够应用到多个服务器的标准构建。
提供了额外的安装选项。
最值得注意的是最后一点。大多数vSphere架构师和工程师都会认识到脚本安装的好处，但是使用ESXi脚本安装，你还需要在安装后通过命令自动配置服务器。
当把kickstart脚本、PXE引导程序和集中的媒体库组合在一起使用时，整个安装过程就不需要你动手了。当然，需要提前安装、测试并适当定制每个部分以确保其可行。这些构建环境很适合拥有几百个服务器的大型企业。和往常一样，必须权衡脚本式构建的好处和创建这个环境所需耗费的时间。
有两个社区项目都致力于简化PXE服务器、媒体库和kickstart脚本。它们很相像但体验略有不同。都是可以免费下载的虚拟设备，提供基于Web的控制台以创建自定义的脚本构建：
ESX Deployment Appliance（EDA）：www.virtualappliances.eu/。
Ultimate Deployment Appliance（UDA）：www.ultimatedeployment.org/。
遗憾的是，这两个项目都没能保持其最初的热情，直到Auto Deploy特性的到来。Auto Deploy（特别是vSphere 5.1时已支持有状态安装）可以完全取代它们。PXE服务器、媒体库、脚本安装和安装后配置都可以通过Auto Deploy完成。但是只有具有Enterprise Plus授权的高级vSphere版本中才有Auto Deploy特性。可以说，大多数足够大且在考虑Auto Deploy的可替代方案的vSphere用户都是有Enterprise Plus授权的用户。
目的地 可以将系统镜像部署到多个地方。一般情况下，你可以把它部署到本地硬盘（包括SSD硬盘）中。有些硬盘，特别是SAS硬盘，会被错误地认为是远程硬盘。这样安装时就不会创建scratch 分区，scratch目录就会被创建在内存中。
可安装ESXi还可以部署到U盘或者已挂载到服务器上的SD卡中。这两个部署位置都被ESXi认为是removable（可移除）的，并当作全功能的嵌入式ESXi处理。如果服务器供应商的设备支持U盘或者SD卡，那么根据VMware的定义，其中的ESXi就是嵌入式ESXi（虽然服务器供应商可能并不这么认为）。不管是否经过验证，将ESXi安装到U盘和SD卡上的影响都是一样的。要了解具体后果，请阅读下一小节“嵌入式ESXi”。
你还可以将系统镜像安装到SAN LUN上。SAN LUN可以是FC、FCoE，也可以是iSCSI。通过一个独立的硬件iSCSI卡（iSXSI HBA）或者独立硬件iSCSI适配器上的软件启动器，就可以用iSCSI LUN来引导ESXi。要使用软件启动器实现SAN引导，网卡必须支持iSCSI引导固件表（iSCSI Boot Firmware Table，iBFT）。iBFT格式 允许将iSCI参数保存到网卡内置的内存中。
VMware Go
常规安装方法的一个可替代方案就是使用VMware的基于SaaS的Go服务。它是一个云部署和管理方案。用户可以注册到这个服务。VMware Go可以通过远程的方式将ESXi安装到现有的Windows服务器上并通过Internet访问Web服务。它会检查服务器硬件以确保是兼容的，然后通过流媒体的方式将镜像拷贝到远程服务器上。最初它的目标市场是SMB：免费下载，注册服务便宜，且特性比正式版本中的还要多。如果小公司的部署可以从额外的支持和管理中获益，那么这个方案值得推荐。
再重申一下，ESXi可安装镜像提供如下引导方式：
CD。
USB。
PXE server。
Auto Deploy server。
如下安装方式：
交互式。
脚本式。
可以从如下位置引导镜像：
本地硬盘（包括SSD）。
USB或SD（类似于嵌入式ESXi）。
FC、FCoE或者 iSCSI SAN LUN。
嵌入式ESXi
嵌入式ESXi背后的理念就是服务器供应商刚买到产品就可以卖掉。镜像在服务器出厂前就以固件的方式预安装好了，或者写到USB闪存或SD卡上然后安装到主板内部socket上。 通常，ESXi镜像包含硬件驱动和CIM插件，这些也存在于供应商的ESXi可安装镜像的定制版本中。这些软件不是直接安装在服务器上的，而是上电后再获取安装信息。实际上，很多服务器供应商都会让客户从他们认证的USB驱动器中选择一个购买，这些驱动都包含在供应商定制的镜像中（可以在线定制的ESXi可安装镜像）。
重要的是除了驱动外，其他内容都是一样的。硬件不同，供应商的质保和技术支持也会不同，但是嵌入式ESXi的软件镜像和可安装ESXi中的镜像是一样的。理论上讲，嵌入式ESXi只是新硬件的一个选项。但是不能反过来将它添加到现有服务器上，也就是说由于镜像是一样的，所以将ESXi可安装镜像安装到USB闪存上，你得到的是完全一样的东西。
嵌入式ESXi认为媒介是可删除的，对它们的处理方式也不同。它只使用硬盘的前1GB空间，而不会创建scratch分区。除非找到本地硬盘分区或本地VMFS 数据存储来存储scratch目录，否则它会默认常驻内存的ramdisk。缺点就是重启或系统故障后其中的内容会消失。通过在远程数据存储上创建scratch目录或将日志重新定向到集中的syslog服务器上就可以缓解这个风险（本章2.6节会介绍这部分内容）。
如果要购买新的服务器硬件并决定在ESXi中使用，那么你需要考虑的关于嵌入式ESXi的关键决策有哪些呢？
嵌入式ESXi的优势：
无需安装。
服务器相对便宜，因为制造上不需要给服务器配置RAID卡和本地硬盘。
服务器本质上是一个设备，所有硬件都是支持的，且即时可用。
嵌入式ESXi的缺点：
你可以在所有服务器上使用可安装ESXi或Auto Deploy，这样安装方法统一且可以继续购买和以前一样的硬件。
ESXi的常规HCL更广泛，所以为了满足需求，你需要定制更多的内容。
为可安装ESXi或Auto Deploy购买的都是成品服务器，你可以为它们重新设定服务器角色。
为可安装ESXi购买的服务器可能都有本地硬盘，所以可以提供本地scratch分区和VMFS分区。
无状态ESXi
无状态ESXi是在vSphere 5.0时作为一个支持的部署方式引入的。与可安装ESXi和嵌入式ESXi不同，无状态host不是从硬盘引导的。目前所有的无状态主机利用的都是它们常驻内存的特点，以及每次引导时都能从网络中以流媒体的方式下载小型ESXi的特性。这和PXE引导可安装ESXi不同，因为host会直接将ESXi镜像拷贝到硬盘，以后就都从硬盘引导，而不是从网络引导。
无状态ESXi不等同于Auto Deploy
无状态ESXi使用Auto Deploy作为它的部署机制，没有Auto Deploy就不可能引导无状态host。但是这并不意味着Auto Deploy就完全等同于无状态ESXi：Auto Deploy是基础架构机制，无状态是host的配置方式。后面会介绍如何使用Auto Deploy.
无状态host最典型的特征就是物理服务器本身对其自身状态并不是权威的。这意味着不管服务器是从哪引导的，它都会从第三方获取权威状态。所以某种意义上讲无状态host也是有状态的，只是这个状态在每次引导时是从其他资源获取的。无状态host引导时，会从多个资源处获取其状态。表2-1列出了host状态的不同部分分别来自哪里。
默认情况下，运行时状态（比如日志文件）存储在host的ramdisk中，且重启后会消失。
无状态host的优点
你为什么想要一个每次引导都会忘记上一次配置的服务器呢？无状态服务器从中央权威处获取状态，这使硬件更容易更换，且部署及重新部署也会容易很多。如果要使用带有host更新、改进的驱动和变更的配置的新ESXi镜像的话，那么只需要重启host即可。同样，可以把host认为是集群的计算资源，分配给各个虚拟机。还可以实现在几分钟内自动重构host，让所有host都适应新的集群配置（新的网络和存储配置）。
无状态服务器还可以防止状态变异，因为每个服务器重启后都会回退到企业标准状态，无须再为每个host的配置状态进行排错了。
无状态host不需要本地存储设备。每次启动的时候镜像都是从网络获取的，且直接装载到内存中。如果没有本地存储，你应该把日志和核心转储信息重新定向到远程收集器来存储它们防止丢失。但是如果服务器启动时有本地存储，ESXi就会充分利用它，把scratch分区挂载到本地存储。不需要本地硬盘和本地状态信息的理念使得ESXi服务器比你想象中的更像硬件设备。无状态部署特性说明ESXi镜像和所有host的配置都是可以集中和管理的。在一个大的网络环境中，这个比kickstart形式的脚本安装高效得多。
无状态缓存
vSphere 5.1引入了一个新的选项：无状态缓存。无状态缓存继承了常规无状态部署的理念，但是每次启动时，host都会从Auto Deploy服务器中获取镜像和状态信息，并拷贝到硬盘中。这个硬盘可以是本地硬盘、可移动的U盘，或者boot-from-SAN LUN。如果Auto Deploy基础设施有什么问题，host还可以直接从其本地缓存的副本引导。正常情况下，无状态缓存主机会从网络镜像引导。它只有在发生故障的情况下才会使用缓存的镜像。本地副本的存在使得Auto Deploy发生故障时，服务器也可以上电并启动所有的虚拟机。之后还可以用于排查Auto Deploy的问题。Auto Deploy基础设施恢复正常使用后，下一次服务器重启时就会看到host又从网络获取镜像（并更新其本地缓存）了。要启用这个模式，需要修改host profile，如果PXE引导失败，那么服务器的BIOS则需要尝试从硬盘引导。
常规的无状态模式没有启用本地缓存（这个模式vSphere 5.0时就有了，到vSphere 5.1时还是作为默认模式存在）。未启用本地缓存的无状态ESXi保持了其原有的优势：不需要本地硬盘。
2.3.3 Auto Deploy基础设施
Auto Deploy是一个自动分配和配置ESXi host的部署工具。它通过集中镜像和配置信息简化了大型部署工作。所有host（至少，最开始的时候）都通过PXE引导并连接到Auto Deploy 服务器上。Auto Deploy服务器通过一系列规则选择ESXi镜像后以流媒体的方式将镜像推送到物理服务器。vCenter的host profiles 功能，可以为host提供配置详情。
Auto Deploy像上述描述的那样分发无状态host。这种情况下，host每次重启后都会回到Auto Deploy机制。Auto Deploy还可以作为有状态host的一个纯粹的安装机制。有状态部署的主机实际上就是常规的可安装镜像。唯一的区别就是刚开始的时候它是通过Auto Deploy工具分发的，所以会使用Auto Deploy镜像和host profile来配置host。 这意味着如果需要的话，host可以很快重构，这是因为Auto Deploy系统里保留了所有信息。但是，一旦有状态host部署完毕，它就不再依赖于Auto Deploy 服务器了。有状态host自己维护其状态，不需要从网络引导，打补丁也是通过常规方式，其他方面和ESXi 可安装host都是一样的。
Auto Deploy组件和使用流程
Auto Deploy 需要如下几个组件，并分别配置好以支持ESXi host。
PXE 环境 通过网络适配器将host设置为通过PXE启动。DHCP服务器给host分配预先设定的IP地址，然后提供选项66，告诉host哪个是TFTP服务器；以及选项67， 告诉host iPXE（vSphere 5.0使用gPXE）文件的文件名是什么。然后host联系TFTP服务器并获取iPXE引导程序以及iPXE配置文件。这样，host就可以向Auto Deploy请求ESXi镜像了。
Auto Deploy服务器 Auto Deploy服务器是一个服务，预安装在VCSA（vCenter Server Virtual Appliance，vCenter 服务器虚拟设备）上；虽然默认这个服务器是被禁用的，但在Windows vCenter ISO中仍然是个可安装选项。Auto Deploy服务器执行两个任务。首先，根据配置规则，匹配host提供的属性与镜像文件、host profile 和要加入的正确的vCenter对象的位置。其次，通过Web服务为host提供可引导的镜像。
Auto Deploy服务器可以根据需要使用Image Builder来自定义或者更新ESXi。匹配host的规则可以根据一系列的属性来设定，例如：MAC地址、IP地址和SMBIOS信息。你可以用PowerCLI来创建这些规则，然后再激活它们。
vCenter Auto Deploy给host提供的镜像包括host profile配置（由vCenter负责维护）。服务器除了基础ESXi镜像外，还需要host profile中包含配置详情。通过指定host的应答文件可以增强host profile。host启动后就会连接到vCenter，并作为分担计算负载的host资源加入相应的集群。
创建运行规则和激活规则的基本流程如下（此处提供的仅为主要命令，实际使用过程中还需要加入相应的开关和参数）：
- 连接到由Image Builder生成的软件库（Add-EsxSoftwareDepot）。
- 指定image profile、host profile和集群规则（New-DeployRule）。
- 添加运行规则并激活规则（Add-DeployRule）。
VMware发布了一个免费但不提供技术支持的工具fling，叫作Auto Deploy GUI，可以从http://labs.vmware.com/flings/autodeploygui 下载。Auto Deploy GUI 简化了Auto Deploy服务器的配置流程。虽然VMware flings 并不享受官方的技术支持，但是只要部署后host测试过，就不会影响正常运行。
部署模式
目前，Auto Deploy支持三个不同的部署模式。除非在host profile（在System Image Cache Configuration下）中专门设定成其他模式，否则host都会以第一种模式启动：
无状态 无状态Auto Deploy是自vSphere 5.0开始就有的经典模式。设定为Statless mode PXE的主机每次都会从网络引导，且每次的引导流程都一样。如果服务器需要打补丁，就更新镜像和规则集，然后重启。每次引导时host都依赖于Auto Deploy基础设施（开始运行时就不再依赖了）。
无状态缓存 无状态缓存模式与无状态模式类似，只是每次镜像被推送到服务器后，都会缓存到硬盘。这个硬盘可以是本地的，也可是远程的boot-from-SAN硬盘，或者是U盘。如果选择使用U盘，它就会覆盖在服务器上找到的第一个U盘。镜像仅仅是被缓存，因此，只要Auto Deploy基础设施正常运行，服务器就会一直从最新匹配的网络镜像引导。关键区别就是当Auto deploy基础设施发生故障时，host 服务仍然可以启动。一旦Auto Deploy恢复正常，host下一次还是从网络镜像引导（vSphere 5.1有这个模式，vSphere 5.0没有）。
有状态安装 有状态安装模式仅在第一次启动时使用Auto Deploy基础设施接收镜像。这个部署会被拷贝到硬盘中（本地、boot-from-SAN或者U盘），然后host会从该镜像启动。再重复一次，如果选择U盘，它就会覆盖在服务器上找到的第一个U盘。以后都是通过该硬盘的镜像启动，而不是通过Auto Deploy 基础设施。这是通过设定服务器BIOS中的引导顺序实现的：首先从本地硬盘引导，失败后再从PXE引导。给host打补丁是通过常规方法完成的，而且除非在vCenter中手动应用新的host profile，上述配置是不会改变的。这样可以导致配置改变，而与Auto deploy相关的很多优势也就不存在了（vSphere 5.1有这个模式，而vSphere 5.0没有）。
Auto Deploy推荐
设计Auto Deploy基础设施时，请参考如下推荐内容：
将Auto Deploy服务器部署在单独管理的集群中（vCloud Director也建议单独部署），这样就防止发生“鸡生蛋还是蛋生鸡”的问题：当整个数据中心断电时，所有的物理服务器都关机了，虚拟机需要启动，但是host无法启动。创建一个管理集群，其中host不能以无状态模式部署（虽然使用Auto Deploy以有状态模式构建它们是可行的）。
如果选择将Auto Deploy基础设施部署在非无状态host上，请确保所有的组件都运行在该集群中。至少包括DHCP服务器、TFTP服务器、Auto Deploy服务器和vCenter服务器（连同数据库、SSO和Web客户端服务器）、DNS，以及几乎必然存在的域控制器。
虽然可以在物理硬件上安装这些组件，但还是推荐安装在虚拟机上。这样就可以通过HA提供硬件故障保护，通过vMotion和Storage vMotion使硬件独立，还能够进行资源保护和带有DRS的负载均衡。
构建至少一个包含VM工具的全镜像host，这些工具可以拷贝到共享的locker中供所有host使用。不要在所有host上使用全镜像，因为这样会给网络和Auto Deploy服务器带来不必要的负载。
记住要为无状态host的日志和核心转储信息创建集中的永久性的存储，或者重新定向到其他远程服务器：syslog服务器和转储收集器。转储收集器仅支持vSphere 5.1 vNetwork distributed switch （vDS）。
如果host要加入AD中，还需要配置AD校验代理服务（Windows vCenter安装包含此选项）。这个代理服务可以防止管理员的用户名和密码被保存到host profile中。
2.3.4 对比不同的部署选项
每个部署选项都可以提供可服务的ESXi host，分别有各自的优点和缺点，每个方法都有各自最适合的环境。如图2-3所示，总结了这些选项以及它们是如何影响到服务器的引导位置的。
通常，部署方式的选择取决于部署规模、技术水平和时间要求。WAN拓扑和vCenter的实施也会影响到服务器的部署模式：可能每个vCenter只有一个Auto Deploy服务器，这就限制了无状态主机的部署，或者需要引入更多的vCenter才能满足要求。
调整部署规模
只有少量服务器的小公司很可能选择通过CD引导和常规的交互式安装方式手动安装每个服务器。随着公司的成长，自动化程度的提升，公司可能会考虑通过脚本方式安装。大多数服务器都在一个地方（或者分布在多个地方但WAN网络质量很好）的公司，通过PXE引导服务器集中管理镜像就是个很方便的部署方法。它是和kickstart脚本一起使用的，这样就可以更快更集中的安装了。有vSphere Enterprise Plus授权的大型企业，可以考虑使用自动化的post-install方法，指定初始化配置，并通过host profile策略来维护环境。
如果企业已经有了定制的PXE引导环境，而且积累了很多脚本安装的知识，那么他们很喜欢继续使用这种方式。但是还想从头开始建立自动安装环境。那么最好还是部署一个Auto Deploy基础设施。原则上，用脚本安装的定制PXE引导方式和有状态Auto Deploy部署方式很类似。但是既然VMware已经提供了解决方案，为什么还要自己定制呢？Auto Deploy解决方案正在快速标准化，而且维护起来还比定制的方案容易得多。当组织需要最大化灵活度并减少部署时间的时候，无状态Auto Deploy部署就是个不错的选择。VMware一直在改进Auto Deploy，一个图形界面的Web配置客户端很快就会面世了，而且其host profiles 特性也随着每个版本的发布逐渐成熟。
不同的方案需要不同的技术。例如，在首要数据中心采用Auto Deploy无状态部署，在管理集群中使用有状态部署，在远程站点部署少量的嵌入式服务器并由外包人员管理，以及在准备发往小办事处的服务器的本地硬盘上部署可安装的host。
对于使用Auto Deploy的大型安装来说，Auto Deploy基础设施是可以扩展的。目前制约因素就是每个vCenter只能有一个Auto Deploy服务器。如果需要更多，那么就要增加vCenter。然后通过SSO服务将它们链接起来，这样才能用一个Web Client服务器（或者链接模式，如果你需要共享license和角色，也可以使用跨WAN链接）一起管理它们。
目前，vSphere 5.1中每个Auto Deploy服务器可以引导大约40个服务器，前提是使用没有VMware工具的简化版ESXi镜像。你应该为最坏的引导风暴场景（比如：断电后的引导）做好准备，并确定上电后应最先引导至少多少个host。你可以在负载均衡器前面增加很多的Web代理服务器，将Web服务负载分发给Auto Deploy服务器，这样能实现更高层次的线性扩展（每增加一个Web代理服务器就可以多引导40个host），但是，最终都会因Auto Deploy服务器的CPU能力而达到极限。和往常一样，只有在环境中测试过才能证明这些措施的有效性。不管Auto Deploy基础设施的规模有多大，你都不能将Auto Deploy服务和vCenter部署在同一个服务器上，因为重启多个服务器的时候，这两个服务的访问量都特别大。
镜像位置的影响
虽然所有的部署方法都在host上产生一个ESXi的运行版本，但是理解最终配置的不同还是很重要的。如果已经有了一些带有硬盘的服务器，且部署规模很小，那么本地磁盘就是个不错的选择。本地硬盘一般很可靠，其安装时有很好的默认配置，不需要安装后再更正什么缺陷或错误了。以最常用的镜像位置（本地硬盘）为例，对比下每个可选硬盘：
可移动硬盘 可移动的引导介质就是USB/SD安装和ESXi嵌入式安装，这两种方式安装后没有scratch分区。如果本地硬盘有VMFS卷，那么ESXi就会使用它来创建scratch目录。如果没有，ESXi就会将scratch目录存储在ramdisk中。最好的方法就是在host的高级设置中将scratch分区指向到远程VMFS卷。此外还可以设置并将syslog服务和转储服务重新定向到远程的syslog和转储收集服务器中。如果安装时不使用U盘或SD卡，那么最好还是买质量高的介质。不要花了几千美元买服务器，然后拿5美元的引导硬盘来欺骗自己。虽然引导介质故障后服务器不会崩溃，但是还是要尽快更换引导介质并重启服务器。便宜的USB/SD介质用不了多久的。
从SAN引导 从SAN引导有很多优势，比如：可以买到比较便宜的服务器；使用SAN硬盘，具备较强的集中性和故障保护能力；服务器运行时是没有状态的，所以可以替换发生故障的服务器并重新指向SAN LUN。但是它也存在一定的问题，选择此方法时也要充分考虑到：
Boot-from-SAN 配置较复杂，每个服务器都需要单独的光纤结构分区，HBA/CAN的配置也很复杂。
SAN存储通常比本地存储贵，所以额外的SAN硬盘把服务器存储节省下来的费用都耗掉了。
每个服务器都需要分配和管理SAN LUN，为存储团队增加了不少工作量。
大量的VMkernel硬盘I/O交换会影响虚拟机硬盘的性能，因为它们共享的是相同的I/O渠道。
boot-from-SAN配置不支持用微软集群（Microsoft Clustering MSCS或者Failover Clustering故障转移集群）配置的虚拟机。
在很多数据中心，从SAN引导的方式还是很流行的，特别是刀片服务器数据中心，但是无可争议，Auto Deploy（特别是vSphere 5.1改进了Auto Deploy之后）对大型的大站点数据中心来说是更好的选择。与ESXi安装的简易性相比，boot-from-SAN的复杂性意味着它不能提供与物理Windows或Linux boot-from-SAN配置同样的价值。
无状态 传统的无状态服务器没有基础硬盘，所有东西都是运行在ramdisk上的，没有可挂载scratch分区和store分区的硬盘。没有机会重新引导到alternate bootbank（虽然通过改变活动的规则集，可以为重新引导提供一个新的镜像）。
