活动主题：VMware虚拟化实施过程中的最佳实践点探讨 - 如何配置平台高可用细节策略

<案例分享篇>

案例分享之一：存储Thin模式也可能导致的问题案例

【问题描述】
由于开发测试环境存储资源使用状况非常不均衡带来的空间浪费情况太严重，于是对于所有的开发测试环境进行了重组。第一、虚拟化环境内的所有虚拟机存储采用Thin模式。第二、存储设备上划出的Lun也采用Thin模式。第三、开启虚拟化上存储集群的DRS开关。第四、建立严格的存储空间使用监控机制。重组问题一个一个来执行，大量的虚机该重建重建，该迁移迁移。整整折腾了好几天。当所有人都在积极忙于监控自动化以及监控策略的时候，问题发生了，开发人员说开发环境有问题，应用发布失败，有的甚至都无法登录系统了。

【过程描述】
起初有点傻了，感觉是之前的重组过程有问题导致的问题。登上虚拟化环境一看，好多虚拟机处于灰色状态，几乎处于不可操作的状态。好多开发人员的虚拟机报出磁盘写入错误。
=> 查存储吧。1.果然，存储告警。怎么可能，留的空间明明不少啊，虽然是Thin模式也不至于两天就满了啊。2.从虚拟化环境内，查虚拟机的具体占用情况。一查总的占用量，果然超了。3.查具体的虚拟机，发现有几个虚拟机，占用空间量惊人。两天之内从实际占用空间的100G，直接超过1T。
=> 应用IO，BUG，导致狂占磁盘到最大限度。因为虚拟机一开始分配的时候，由于是Thin模式，几乎所有的虚机都是看似非常大，但是实际占用非常小的模式。因为运维的同事认为他们平均使用空间不可能超过100G空间，而Thin模式的阀值是按照每个机器150G的余量来设计的，所以认为不足为虑。

【问题总结】
对于这个问题本身来讲，其实是一个很简单的问题。但是似乎从运维管理上我们应该有所启示。1 Thin模式的设计本身来讲，是为了节省资源。实际上也帮我们做到了这一点。理论上只要我们做好监控，及时补充存储空间的不足，那么这个模式应该是个性价比很高的事情。2 任何事情都会有特殊场合，如果我们对特殊情况没有预想到，那么很可能会走到另一个弊端上。假设我们对Thin模式资源的最大申请比率也有一个控制，比如说最大300G。那么再异常的情况的影响面儿仅限于某个虚拟机。

案例分享之二：高可用策略不合理导致的面积性故障案例

【问题描述】
某天早上，公司内部好多办公系统登录失败。邮件系统、流程管理、代码管理等。但是过了大概一个小时，基本所有情况都恢复正常。

【问题确认】
业务系统的状况：没有任何异常情况，一切访问正常。数据中心基础实施：连续好多系统报警，而且还有物理主机报警，问题一大堆。

【解决过程】
先来描述一下环境，基本90%以上系统运行在Vmware虚拟化平台之上，业务系统和内部办公管理系统完全隔离为两个不同的集群环境。办公区为8台宿主机组成的物理集群，集群共享一台存储设备上的存储资源。
首先，我们再一次确认了宿主机的情况，5台宿主机当前运行状态正常，虚拟机也处于正常状态。只有一台宿主机处于失联状态。当把这一台宿主机再次重新启动之后，它也恢复正常了。
再次，查看问题发生时间的日志，包括宿主机日志。我们发现有好多虚拟机发生了HA切换，不仅仅是故障主机上的虚拟机，而且还包括其他非故障主机上的虚拟机。再仔细看，还有好多虚拟机发生了热迁移，有的迁移失败，有的迁移成功。总之几乎所有主机上的虚拟机发生过HA和热迁移现象。
随后，我们再次确认宿主机硬件日志，发现故障时刻点先后有三台宿主机发生重新启动。这样的话，事情就清楚了，几台宿主机先后发生重新启动，触发宿主机上的虚拟机发生HA，在这个过程中由于资源使用的瞬间不均衡，又触发了DRS的自动迁移。这么多事情发生的时间又是如此之集中，那么最终导致面积性的故障发生。

【问题总结】
此次问题之后，我们根据环境资源重新评估了HA和DRS等的策略，将激进策略修改为相对保守的策略。本来虚拟化的HA和DRS策略是为了保障虚拟机的平衡和高可用性的机制，但是在某种不合理策略策略和极端物理故障场合下就有可能导致比正常故障范围还要大很多的面积性故障。试想，如果DRS处于非激进状态，那么在发生HA的时候，即使资源不够，那么故障范围仅限于很小一部分虚拟机，不会发生彼此影响，而且时间集中化的影响。尤其是Windows的虚拟机，成功热迁移的概率比Linux要低很多。所以提醒大家合理设置高可用策略。

案例分享之三：VMware虚拟化HA集群环境频繁出现网络异常，重启后恢复，帮忙分析一下是什么故障原因？

【问题描述】
物理服务器4台ESXi，两个集群环境，共享存储一台，一直都是正常运行的，突然有一天就出现网络问题，宿主机无法访问，业务中断，重启ESXi主机后，网络恢复，问题消失。由于访问量较大，物理网卡一直处于工作状态，可所有硬件设备状态完好，日志无明显报错，问题在出现过第一次后，反复出现，只要一重启主机，问题恢复，间隔3-4天就出现一次。无法通过日志找到原因。联系vmware原厂，原厂说需要升级exsi版本，和服务器硬件微码。最后升级了服务器硬件微码，和exsi版本。结果只隔了一天，问题又一次出现了。这次并不是所有的网络都阻断，管理地址未中断，但是虚拟机任然无法连通，业务中断。在这之后，做过网络调整，管理网络和虚拟机业务网络分配到不通标准交换机中，问题出现时，同一个标准交换机内的虚拟机出现部分可以出去，外部可以访问，部分虚拟机出现网络配置中网关丢失现象，手动配置网关，依旧无法出去。重启虚拟机之后，部分网络会中断，部分能通。还是需要重启所有ESXi主机，才能恢复。现在ESXi版本已经是5.5.643，微码版本已经是4.0.596，服务器微码也已经升级完成。5.5 U3，问题依旧，现在只能先进行网卡硬件更换，HP NC365T，网卡驱动已经包含在vmwarelinux中，自带。不需要额外打驱动。问题无法定位。向各位高手大神求助，哪位能帮忙分析一下这个问题的可能性原因是什么？
现场答复：按照您说的现象“同一个标准交换机内的虚拟机出现部分可以出去，外部可以访问，部分虚拟机出现网络配置中网关丢失现象，手动配置网关，依旧无法出去” & “重启虚拟机之后，部分网络会中断，部分能通。还是需要重启所有ESXi主机，才能恢复。”假设一个标准交换机上有若干网卡，部分可以通，部分却不通。那么是不是可以推测通过某一个物理网卡的虚拟机是OK的，而虚拟网卡流量落在另外一个物理网卡上的虚拟机是Failed的。建议你下一次遇到这种情况的时候，手动把其中一块儿网卡提出去。如果最后的结果要么全部不通，要么全部恢复。那么某块儿网卡问题的可能性就非常大了。考虑更换网卡。不要盲目相信X86机器上看到的网卡状态。

【后续情况1】
现在已经完成网卡更换，目前链路正常。继续观察。

【后续情况2】
元旦稳定度过，未出现问题。

案例分享之四：我自己在实用vSphere过程中遇到的大坑之一：快照

【问题描述及总结】
请各位慎用虚拟机快照功能，需要用到快照时一定记得用完以后要删掉，不然快照会无限制的增长下去，关键是vClient中查看存储状态看不到快照占用的空间，会错误的以为存储空间还很充足，最终会拖垮整个ESXi上所有的主机，我用的是很早的版本vSphere4.0，新版本中是否还有这个问题，请有测试过的用户告知一下。 现场答复：1. 关于虚拟机的快照功能，我记得是可以设置保留份数的。快照的数量根据实际的虚拟机化性能来指定。不过为了保障业务和虚拟机性能，一般不会经常性的进行快照。大部分快照一般是备份软件备份时产生，通常备份完成后会自动删除。如果使用VMWARE进行快照，注意份数和快照策略就可以了。2. 快照越多，时间越久，性能越差，且合并时间越长，还是需要了解快照的实际作用，快照不是做备份的。3. 快照过多会影响性能 快照之后 会生成新快照文件原虚拟机文件将变成只读 后续数据的的变更会写写入快照文件 这种文件写入很慢。

<问答环节篇>

1 Vmware的计算高可用设计相关。

相关问题：
Q1：高可用平台中物理服务器的网络怎么样配置既合理有稳定，还能保证不会掉线（包括网卡如何配置）？
Q2：VMware环境搭建中，在系统配置、架构等方面有哪些需要特别注意的地方？
Q3：VMware虚拟化的高可用配置时，过程、环境有哪些特别需要注意的地方？请各位高手们指教！
Q4：VMware虚拟化实施过程中，如何配置平台高可用细节策略？
Q5：VMware高可用的应用转移策略如何设置？

回答提炼：

这类相关问题主要的关注点在于以下几个方面：
第一，就VMware HA 的接入控制策略。

1. 主机容忍的宿主机故障数目。假设数目设置为1，那么集群发生超过这个数目的主机故障，那么虚拟机就不会再发生HA切换。假设集群内所有宿主机的规格很标准，一种或者是两种，那么可以通过对所有虚拟机所需资源的总和以及现有宿主机资源的总和来算出究竟几个宿主机满负荷的时候可以支持这些虚拟机。剩下的宿主机数目就是我们可以容忍的故障。当然这个算法不是简单的加和，是需要在不同环节取整的。具体可以参照Vmware的插槽计算方法。
2. 预留资源百分比策略。这个策略是说集群会按照设定比率来预留一定的CPU和内存资源来满足HA。超过这个资源的故障也不会切换。当所有虚拟机启动所占资源已经超过（100-设置值），那么集群不允许再有虚拟机来启动占用资源。如果说集群内的宿主机规格五花八门，那就只有这么去估算预留资源比例的方法来执行HA了。 3. 指定主机故障切换。那就是按照指定策略来执行主机HA切换。以上三种策略，严格来讲没有最优或者最好。完全需要按照自己的需求来设定。但是对于第一种策略来讲，设置的数目越多，那么意味着HA的活跃度越高。如果HA的活跃度超越集群的资源限制，那么这种HA会影响到其他正常运行的虚拟机，而且有可能触发故障的泛滥或者连锁影响。所以不建议设置太高。对于第二种策略来讲，如果设置的太高，那么会很影响集群的资源利用率。第三种策略除非是特殊场合使用。光靠以上策略来完成集群的HA功能，想保障自己的业务系统连续性，我认为远远不够。应用系统毕竟有重要及非重要之分，有重量与非重量之分。有的可能已经具备了负载均衡架构，有的可能还是单节点运行。所以我们需要根据这些情况在接下来的“虚拟机选项”当中针对不同的虚拟机设置不同的HA优先级。根据负载均衡的位置，设置同样应用系统的不同应用节点的互斥HA规则等。总之，这个策略不是单一某个策略就能最适合我们的应用环境。需要根据我们的环境特点以及每一项HA策略的功能去合理组合优化。希望对大家能有帮助。

第二，就VMware HA本身的故障诊断切入点问题。关于故障的排查，不同类型的故障会有不同的切入点。故障不明确很难找到准确的切入点。一般是从报警日志中去找切入点。举个例子，比如说发现一个虚拟机HA失败，除了从日志中寻找线索。还可以考虑去检查以下几个方面：

1. 存储是否已经在源和目标宿主机上共享并没有问题？
2. 目标宿主机上在故障时刻的资源剩余是否足够支撑虚拟机的启动？
3. 从VC上查看集群的HA状态是否正常，虚拟机的Vmtools是否异常？
4. 是否是个例？那么虚拟机本身是否有文件系统损坏之类的问题？等等.....

第三，就虚拟化机构当中的众多细节。绝对的稳定，感觉没有。但是有些点，可以考虑:

1. 物理网卡、宿主机、接入交换机及汇聚交换机这几个层面保证冗余设计，目标就是保证任何一个物理对象故障时都不会影响到网络。例如：双网口网卡双份、跨机柜实现交换机双冗余，汇聚及核心交换机实现物理上的冗余以及虚拟化技术。
2. 根据Vmware的最佳建议实现宿主机侧的网口绑定以及交换机侧的辅助配合。一般情况下，宿主机上实现基于端口路由方式绑定，而交换机侧不需要做任何绑定。vmware侧的管理网络和业务网络在物理网卡上的分布要隔离。
3. 业务网段内的逻辑隔离靠Vlan隔离。当然跨功能区的隔离可以靠虚拟化环境之外的防火墙策略来控制。
4. 从物理网络以及虚拟网络的整体架构尽量实现扁平化，避免纵向隔离太多，经过的安全设备太多。

2 Vmware的存储高可用架构相关。

相关问题：
Q1：VMware虚拟多台主机后，如果要为这些主机搭建共享存储，如何保证高可用，方法是什么？
Q2：如何合理规划VMware架构以应对未来企业IT架构平台的扩容问题？
Q3：好马如何配好鞍——VMware如何根据业务需求搭配存储解决方案？
Q4：一套VMware环境能不能采用SAN存储和NAS存储并用？如果可以，配置时有何需要注意的事项？

回答提炼：
假设想利用物理节点本地硬盘来实现NAS共享，那么我觉得有以下两种实现方式：

1. 利用开源NAS软件实现传统高可用NAS集群。你可以选择虚拟化环境当中两台宿主机上的两个虚拟机，然后通过FreeNas或者是openfiler之类的NAS软件实现传统NAS的HA集群，数据可以以两份本地盘数据互为主备。
2. 利用Ceph\\Vsan之类的软件来实现软件定义存储。然后就这些条件做的话，可能性能会有些问题。软件定义存储的实现还是要依靠SSD来支撑它的整体性能。个人觉得还是看你的应用用途，如果是开发测试或者是实验环境，那么可以降低性能的要求，也不用那么复杂。如果是生产环境还是要考虑一个稳固的架构。

个人认为虚拟化本身由两个很好的特点就是其扩展的灵活性和资源利用的动态性。
对于第一种情况，假设期初的发展仅仅是尝试性的应用。规模小，功能少等等。随着技术的发展和成熟，想要横向实现扩展，纵向实现升级。对于计算资源的扩展，很容易，兼容性没问题可以直接扩入集群。然后根据后来的资源规模配置等调整集群参数及策略。对于升级来讲，可以借助Vmotion实现隔离一台升级一台，逐步完成。对于第二种情况，存储资源扩容。扩容导致控制器无法工作的故障应该说是个例。但是针对这种个例其实如果扩容之前能把备用方案考虑周全，那么业务瘫痪的几率或者说是长时间中断的几率就会小很多。比如说找一个临时备份存储，做一个克隆，以备故障场合下的应急。再不行，本地磁盘都是加了Raid保护的，做一个克隆也可以。总而言之，任何先进技术的利用都离不开对管理方案的深思熟虑。

对于存储架构来讲，多数环境还是传统SAN存储方式。可能有个别会通过VPLEX、SVC、MCC等做个存储的虚拟化再划给虚拟化环境等。也有一些采用了VSAN商业化存储软件化产品或者是其他的软件定义存储产品。超融合产品里面就会有软件定义存储的部分，尽管实现的方式各有差异。对于存储的配置来讲，比如说划分多大的LUN、每个虚拟机的规格是多大、LUN上承载的虚拟机有多少、存储的路径切换以及ISOC控制策略如何设置、存储LUN要不要做成存储集群的模式、要不要开启存储资源调度参数等会有一系列可以优化或者仔细规划的地方。这个需要根据自己的环境特点，搞清楚每一项设置的原理和意义来具体规划。

一般为了平衡性能和成本问题会采取NAS和SAN混搭的用法。所以第一个问题就是在VC上必须能清楚Datastore对应存储的类型，不要出现性能需求与实际分配底层存储类型不匹配的问题。再有就是规划好各自的用途，规划好他们的共享问题，是不是两种存储类型都需要所有的宿主机共享？如果出现非全集群共享的情况，将来的扩展和迁移管理会比较麻烦。再有所有宿主机的网络配置和HBA配置尽量不要出现差异很大的情况，要四个口都四个口，要万兆都万兆。

3 虚拟机备份恢复相关。

相关问题：
Q1：VMware虚拟机上恢复出来的ORACLE数据库的数据不一致，能否分析一下是什么原因？
Q2：VMware虚拟化平台中，VM虚拟机的数据安全、备份恢复等有什么比较好的方案？
Q3：开启ISCSI存储接口后，每次宿主机重启都无法启动成功，求原因分析解决办法？

回答提炼：
对于虚拟化的备份恢复软件来讲，个人认为最方便的就是Vsphere自己的VDP软件模块。当然也可以用NBU之类的被人软件做统一备份，Vmware都提供接口。

对于数据库之类应用的备份，利用虚拟机整机备份的方式来做是远远不够的。NBU做备份的时候是把虚拟机按照文件的方式进行备份，在某一个时刻切一个快照，然后不管应用是什么状态，只管按照那个时刻的文件状态备份。但是对于数据库来讲，最重要的是事务，在某一个时刻的数据状态有可能处于事务过程当中，单凭文件层面的快照无法保证数据库的事务ACID特点，因此当你把机器恢复的时候，就有可能会有事务不一致的问题。数据库也就无法正常使用了。所以对于有数据库的机器，绝对不能单靠虚拟机备份方式来做数据备份。一定要从数据库RMAN层来做备份。

4 关于虚拟机化实施过程中的资源比例问题。

相关问题：
Q1：VMWARE虚拟机与物理机的性能、数量平衡，DataStore数据存储区的大小和数量最佳实践？
Q2：两台VMware esxi怎样做HA，才能将VMware esxi的性能发挥得最好？

回答提炼：
第一，关于物理资源和虚拟机的配比问题。这个事情的规划需要考虑几个方面的事情。

1. 应用节点对资源的实际需求。
2. 集群的高可用策略，究竟要拿出多少冗余资源来应对物理故障，重点要保障哪些应用虚拟机的优先级等。
3. 应用对资源的占用模式（独占、共享、优先级等）。

第二，关于存储LUN和虚拟机的配比问题。这个事情没有一个绝对的最佳。一般来讲VMware原厂建议一个LUN至少1T，一个LUN上的虚拟机不要超过15个。但是这个完全取决于虚拟机的平均大小，存储设备的性能以及应用的IO负载特点。总的原则来讲，虚拟机分散，LUN小一点，性能会好。但是LUN小的话将来的管理会麻烦一点。第三，关于Thin模式。只能是做好监控，不仅仅是VMware层面的Datastore使用率的监控，而且还得监控存储侧。更重要的是要检查是否有异常的磁盘增长发生。比如说某一个或几个磁盘的迅速增长。

5 关于存储配置。

相关问题：
Q1：主机与存储的多路径设置，如何配置策略以保证可靠行和高可用性？
Q2：实施虚拟化后，存储可靠性变得十分重要，因为存储故障将导致大量虚拟机不可用，请我vmware平台用哪种存储？
Q3：ESXI SERVER几种创建磁盘的模式的性能和安全的差异有哪些？
Q4：VM虚拟机变为“孤立“的异常处理方法分享，大家有没有更好的解救办法？

回答提炼：

关于Vmware存储的多路径管理，VMware 自己的多路径管理模块（NMP）来讲，其实策略相对比较简单：

1. 最近使用: 主机使用磁盘的路径，直到路径不可用为止。当路径不可用时，主机将选择替代路径之一。
2. 固定:当通往磁盘的首选路径可用时，主机将始终使用此路径。如果主机无法通过首选路径访问磁盘，它会尝试替代路径。
3. Robin：主机使用自动路径选择算法轮流选择所有可用路径。这样可跨所有可用物理路径实现负载均衡。一般情况下，会选择Robin方式实现IO的负载均衡。注意要看到Active的路径与SAN环境设计的Zone一致，一般我们会设计2*4=8条路径。

关于存储的配置参数以及相关，对于SIOC控制参数“Storage IO Control”，它主要是来控制存储IO拥堵状况下的虚拟机的IO优先级，保障重要系统的IO不受影响。设计初衷是好的，但是在实际使用过程当中，尤其是对应用系统IO特点把握的不是很准确的时候，反而适得其反。可以通过极限测试来决定是否打开这个参数。

对于存储自己的多路径管理软件，那要看存储是否提供了For vsphere版本的软件版本，如果提供了，可以通过vsphere的update manager安装并使用，安装之后，那么在相应策略以及控制参数上面会有更灵活的选项可供选择。个人认为如果用Powerpath代替NMP来管理多路劲倒是可以尝试，对于其他存储的多路径软件和Vmware的结合，就没有体验过了。关于兼容性、稳定性等问题就不好回答了。

存储利用过程中，因为存储侧LUN的闪断。可能会造成所有虚拟机状态不可用，作为一个参考解决方案，就是把宿主机挨个关掉，上面的虚拟机完成一次主动制造的HA切换。

关于存储的Thin模式，虚拟机创建磁盘，悬着的精简，但是如果存储分配LUN的时候也用的精简，这将是一个很大的隐患，会存在将存储LUN空间溢出错误，导致虚拟机无法正常运行。如果使用thin模式，就要注意配置使用比率，我们现在一般都使用thick，安全省心，而且理论上性能会更好，thick模式。这两个模式可以互相转换。

6 关于应用高可用的保障问题。

相关问题：
Q1：启用VMware HA以后，是否还有必要在虚拟机里配置Windows或Linux群集？
Q2：请问各位是否有在实际工作中使用过VMware FT，应用效果如何？

回答提炼：
VMware在做虚拟化的方面是有它过人之处和长久的积淀，但是切入到应用层的集成感觉还是差了一点，所以对于FT来讲，感觉有两点：
第一、对于应用的把握，不是那么平滑。
第二、兼容的应用类型还是很有限。VMware的HA主要是实现虚拟机和系统层面的切换。一般情况来讲，感觉再利用操作系统层的HA的必要性不是特别强烈。有特殊需求，另当别论。

7 关于VSAN。

相关问题：
Q1：VMware的存储虚拟化vSAN，网络虚拟化NSX的原理、配置过程是怎样的？目前应用案例多吗？
Q2：vSAN的计算资源和存储资源逻辑同属一个Pool，虚拟机层面上这二者是否可以跨主机？
Q3：san和超融合解决方案相比，各自的产品优势和适用场景如何？

回答提炼：
关于VSAN和超融合，超融合是一个整体解决方案，是将计算虚拟化，软件定义存储，软件定义网络等解决方案集成到一起的一个整体解决方案。而VSAN只能算是或者近似是软件定义存储当中的一种。比如说超融合产品Vxrail里面的存储软件定义方案就是升级了的VSAN。个人感觉这两个东西不能放在一起去比较。而且好与坏都是相对于一个维度来讲的。没法儿去讲谁家的超融合一定比另外一家好很多或者差很多，看你取的是什么维度。放在什么场合，看重的是什么。

超融合本身会包含类似VSAN这样的软件定义存储技术。每一家的超融合产品都会有计算虚拟化、存储软件定义、网络虚拟化等等这方面的东西。但是就存储的软件定义而言，各家会有一些区别：

1. 有的可以在计算节点IO下沉之前做到数据的压缩。
2. 有的可以直接用闪盘做缓存。
3. 有的利用infiniband可以实现系统内的超高带宽，尤其适合数据库。
4. 有的在存储侧实现数据复制是以块儿为单位的，有的是对象存储复制。
5. 有的是把存储的软件层做到每一个节点的系统层，有的需要依赖单独的虚拟机。
   总之各有各的亮点。VSAN目前是被集成到了EMC的超融合产品VXrail里面了，而且有所改进。

关于VSAN和超融合的资源池共享，存储资源肯定没问题啊，计算资源把当然不能，不过据说现在emc的超融合可以，不知道给vmware用没有。

8 安全相关。

相关问题：
Q1：安全还是易用？！VMware虚拟化平台网络方案设计中的取舍和抉择？
Q2：直接用内置U盘安装ESXI，是否有办法做到高可用？
Q3：ESXI SERVER几种创建磁盘的模式的性能和安全的差异有哪些？

回答提炼：
在虚拟化平台方面，很多时候不能一刀切去设计网络，这就出现了很多问题：比如如何规避网络风暴？网络带宽是否可以满足高网络io的需求，是否要设计多个子网？是否要选择SDN？我觉得啊sdn肯定是方向，我们这边也在搞了。多子网对实现网段隔离，安全性比较好。当然要是上联堆叠就更ok了。网络风暴可以采用监控手段（监控时间可以是1个月，中间可以调整），先判断每个口的最大pps，然后设置1.5-2倍pps。

目前U盘没法做raid，虽然ESXI启动后所有信息都已加载至物理机内存，但是一旦U盘损坏，物理机重启还是会遇到问题的，时间推移、人员流动后重装U盘系统再配置对应信息还是很麻烦的。个人认为从安全角度来讲，如果是生产环境，不建议用U盘来做ESXI的启动跟盘，虽然仅仅是个内核，占用空间很小。但是安全性并没有一个很好的保障。