故障排查方法、工具总结
一、vSphere 故障排查思想
1 、故障排查思维逻辑
故障排查涉及到整体的排错方法论，总体而言，故障排查需要遵循一个工作逻辑：
确认问题状况
o 确认问题所在
o 收集故障相关问题
确认导致故障的原因
o 确认什么原因导致的问题
o 诊断问题的根本原因是什么
解决问题
o 制定可能的解决方案
o 评估数据安全风险
o 执行最佳解决方案
2 、故障排查逻辑图示（流程及细节）
图示说明：
配置问题、软件 Bug、硬件故障是三种最为常见的故障
软件 bug 示例
o 在 ESXi 5.5 u1 或 u2 中存在这样一个常见的软件 Bug：网卡原因紫屏事件
硬件故障示例
o 若主机 HBA 卡电池出问题，可能会在写上面会有很差的表现
3 、vSphere 常规故障分层
4 、故障解决 E2E
故障状态故障原因
1 个或多个 LUN 不可见LUN 不可见，存储可能没有恰当的 MAP 到主机
无法通过 vSphere Web Client 连接 vCenterVirtualCenter Service 没有启动
Virtual Machine 无法启动文件可能被锁定，文件可能丢失
5 、案例流程 - 故障状态（示例）
6 、案例流程 - 日志搜集（收集日志信息，用于进行故障分析）
7 、案例流程 - 可能性分析
利用结构化思维来进行故障分析，可以有效提高排错效率；
根据问题的提示，按照下图所示排错流程来进行排错
图示说明：
自上而下进行排错
自下而上进行排错
从中间环节排错
8 、案例流程 - 查找问题的根源
通过反复测试，来确认问题的根源所在，例如：VM 无响应的排错逻辑：
图示说明：
如果仅仅是单台虚拟机无响应，建议自上而下
若涉及很多虚拟机响应慢，建议从中间环节
存在告警，建议从下而上
9、案例流程 - 解决问题
完成问题根源定位之后，评估问题可能带来的影响
o 较大影响 - 立即解决
o 一般影响 - 条件许可的情况下解决
o 较小影响 - 有空解决
制定解决问题的方案
o 头疼医头 - 立刻就事论事解决问题
o 头疼医脚 - 避免同一个问题再次发生
o 长远考虑 - 整体考虑，从未来的思路触发去执行问题处理
10、vSphere 常规故障排查流程 - 追根溯源（图示）
图示说明：
此处以 vMotion 为例，其它故障与此类似
11、vSphere 排错组件归纳
二、针对 Virtual Machine 的故障排查
1、VM 故障排查思想
2 、VM 的文件架构
3 、Content ID
所谓 CID，位于 VM 的磁盘描述文件里面，负责磁盘相关整合状态跟踪
图示说明：
• 母盘的 parentCID 为"fffffff"
• 若虚拟机有快照，则第一级快照的 parentCID 为母盘的 CID，第二级快照的 parentCID 为第一级快照的 CID（若虚拟机存在多层快照，则依次类推）
• 如果快照层级出问题，可能会导致快照出问题，很有可能导致虚拟机无法启动
4 、故障 01 - 解决 Countent ID 不匹配的问题
• Step1：备份好磁盘描述文件
• Step2：下载这个文件，用文本编辑器打开，然后修改 CID
• Step3：修改之后，利用如下命令来验证 CID 的修改是否成功(若提示失败，则意味着 CID 的更改没有成功)
o vmkfstools -q Win01-A-000002.vmdk -v10
注意：虚拟机快照导致的虚拟机无法启动的故障，很多时候都是快照层级发生错乱所致。这类问题可以采用上述方法来解决。
5 、故障 02 - 解决 Snapshot 之 之 vss 导致故障（执行 Snapshot 时，提示 I/O 静默调用失败）
• VM 有大量的 I/O 负载导致在执行 Snapshot 时 I/O Quiescing 失败
• 通常通过下面 2 个技术来执行 I/O Quiescing
o Microsoft Volume Shadow Copy Service(VSS)
o VMware Tools SYNC driver
• 初始化检查
o 检查是否可以手动创建一个不调用 I/O Quiescing 的快照
6 、解决 I/O Quiescing 导致的 Snapshot 失败的故障问题
• 如果利用 VSS 执行 I/O Quiescing，则需要确认下列条件是否满足
o VSS 要求满足
o 相关服务是正常运行状态
o Microsoft Software Shadow Copy 服务正常
o VSS Writer 没报错
• 如果利用 SYNC Driver 执行 I/O Quiescing，则需要确认下列条件满足
o 禁止掉 SYNC Driver
o 在执行 Snapshot 之前，先将 I/O 密集型的业务停掉（比如数据库）
• 老版本的 Windows OS 没包含 SYNC Driver 在 Microsoft VSS 里面
7 、故障 03 - VM 开机失败
• 在 vmware.log 文件里面可以看到虚拟机开启失败
• 故障原因逻辑分析（从上到下）
• 分析是否 vm 文件丢失
o 执行如下命令来查看是否存在文件丢失
• ls /vmfs/volumes/Shared/Win01-B
• 解决方案
o 利用之前的备份来恢复
o 如果 descriptor 文件丢失，手动重建这个文件
• 分析是否虚拟机被锁定
o 确认是否存在文件被锁定
• 尝试开机虚拟机，如果失败，说明可能有锁定
• 执行如下命令查询是否有文件被锁定
▪ touch filename
• 可执行如下命令查看哪台 ESXi Host 锁定磁盘文件
▪ vmkfstools -D /vmfs/volumes/Shared/Win01-B/Win01-B-flat.vmdk
• 执行如下命令来找到锁定的进程信息
o lsof | grep
• 找到后杀掉它
• 如果依然无法确认那个进程导致虚拟机文件锁定，那就用最简单的逻辑
o 迁移虚拟机或重启 ESXi Host
8 、故障 04 - VMware Toolsf 无法安装( 最有可能是 GOS 类型选择错误)
• 检查 Guest OS 类型是否正常
• 分析 Guest OS 类型选错的问题
9 、故障 05 - Virtual Machine orphaned( 虚拟机被孤立)
检查 vCenter Server 是否在 VM 执行迁移的过程中重启过该虚拟机（在迁移到 60%的时候最容易出现），因为在虚拟机被重启时，会临时性的无法使用，状态就会显示为 orphaned
• 故障原因逻辑分析（自上而下）
• 分析 vMotion 或 DRS 导致故障
o 确认是否由于迁移导致故障
• 查看 Tasks 页标签
• 检查 orphaned 虚拟机被注册到的源或目标 ESXi Host
o 如果有找到虚拟机被注册到 ESXi Host
• 重启 ESXi Host 的管理服务
o 如果没有找到虚拟机被注册的信息，则执行
• 注册虚拟机到 ESXi Host 或 vCenter
• 利用 orphaned 虚拟机的 vmdk 创建全新的虚拟机
• 分析虚拟机没通过 vCenter 删除导致故障
o 执行如下命令去验证虚拟机的文件是否存在
• ls /vmfs/volumes/shared/Win01-B
o 如果配置文件被删除，则执行如下动作来恢复
• 重建虚拟机，借此重建*.vmx 文件
o 如果虚拟机的磁盘文件被删除，则执行
• 备份恢复计划
• 分析*.vmx 文件导致故障
o *.vmx 这个文件包含了虚拟机的所有配置信息，如果它被破坏可能会出现上述问题
o 解决思路
• 利用文件编辑器打开这个*.vmx 文件，去掉其中不当部分后重新尝试
• 从备份信息里恢复*.vmx 文件
• 直接从 Inventory 里移除掉虚拟机，然后重建 vm
• 分析 ESXi Host 根文件系统空间不足导致的故障
o 当 ESXi Host 的根文件系统空间不足时，系统可能会尝试删除掉虚拟机
o 可以执行如下命令来确认是否存在这个问题
• DCUI 下面执行:df -h
• 清除不必要的根文件系统里的内容
• 从 Inventory 移除掉 VM，再重新添加
10 、故障 06 - Virtual Machine Snapshot 故障（尝试创建或者处理快照时出错）
• 确认 vm 的磁盘是否支持 Snapshot，因为 RDM 的 Physical Mode、Independent Disk 等状态下是无法做快照的
• 由于 Snapshot 最多支持 32 级，因此，超过后会无法执行
• 故障原因逻辑分析（自上而下）
• 分析描述文件混乱问题导致故障
o 快照的 delta 文件在描述文件里错乱
• 000001-delta.vmdk 文件在 000001.vmdk 里没有正确描述
o Delta 磁盘根本就没了描述的配对文件
• copy 基础磁盘的描述文件，然后更名为配对 Delta 磁盘的描述文件
• 编辑里面，将相关的配对信息更改为 Delta 磁盘的信息
• 分析文件尺寸过大问题导致故障
o VMFS 5 Datastore 单个文件最大支持 62.93TB
o 快照最大值会受到限制
• VMFS 5 里，最大只能超过原始盘的 8GB 左右
• 这里的 8GB 的来源是开销的部分
• 分析 Datastore 空间不足问题导致故障
o 要处理所有的快照信息的前提条件就是 Datastore 的空间要足够
o 可以通过如下方式来确认是否有足够的空间
• 去 GUI 下查看快照所在的 Datastore 空间是否 ok
• 在 ESXi host 上运行命令：df -h
• 解决方案
o 增加 Datastore 的尺寸
o 移走虚拟机
三、针对 Storage 的故障排查
1 、Storage 故障排查逻辑
2 、vSphere Storage 架构示意图
• 当虚拟机无法使用时，排除其它故障，很大程度上会与 Storage 部分有关系。下图是 vSphere 环境下的 Storage 结构示意图：
3 、存储故障 01 - IP Storage 无法被 ESXi Hosts 访问
• 确认 ESXi Hosts 能看到虚拟机所在的 storage
o esxcli storage core path list
• 执行 rescan 动作看看能否重新查看到
o esxcli storage core adapter rescan -A
• iSCSI Storage 结构示意图
o 如果 ESXi Host 出现连接 IP Storage 故障时需要去检查如下图所示的地址：
• 故障原因分析逻辑
o 如果 ESXi Hosts 过去访问 IP Storage 正常，在没做任何更改的情况下出现故障，则可以参考如下流程进行故障解决尝试：
• 检查存储硬件级别的问题
o iSCSI HBA 卡或 iSCSI Storage 阵列不被 ESXi Host 支持（比较少见）
去 vmware 的 HCL 里查看型号
o 确认 LUN 被正确的映射到适当的 ESXi Hosts 上
• 同一个存储组里的 LUN 是否被映射到所有的 ESXi Hosts 上
• LUN 的构建是否符合 ESXi Host 的使用标准
• 不同 ESXi 版本支持的 LUN 大小是不一样的
• 存储的微码版本
• LUN 是否被设定为 R/O（只读）
• 阵列上 For ESXi 的 Host ID 是否小于 255
o 存储设备故障
• 利用硬件工具诊断存储故障
• 检查是否 iSCSI 存储性能
o 检查是否设计了最佳 IP Storage 网路：
• 规避链路问题导致的过载
• 分开 iSCSI Traffic 和 NFS Traffic 以及其它相关的 vmk 接口
o 监控设备延迟情况
• 利用 esxtop 或 resxtop 命令后输入 d 查看
• 检查 VMkernel 配置是否异常
o VMkernel 接口是 IP Storage 的重要接口
• 在 ESXi Host 上 ping iSCSI Target 地址
▪ 例如：ping 172.20.13.14
▪ 如果 ping 不通则可能是 IP 问题
• 检查 iSCSI HBA 卡配置是否异常
o iSCSI 的 Initiator 是 iSCSI 连接的重要接口
• iSCSI Initiator 名称
• iSCSI Target 名称、端口和地址
• CHAP
o 确认 VMkernel 与网路卡的绑定是否正确，如下图所示：
注意：在 iSCSI 存储环境中，NIC 即使做了 Teaming，同一个 VMkernel 的话同一时间只允许一个 iSCSI HBA卡处于活动状态
• 检查 iSCSI 3260 端口是否可达
o iSCSI TCP 端口 3260 可用如下命令来检查：
• 在 ESXi Host 上执行 nc 命令来查看是否可到 iSCSI Storage 的 3260 端口
▪ nc -z
o 解决方案
• 确认存储运行是否正常
• 确认 iSCSI 流量没被干扰
• 检查 VMFS Datastore Metadata 一致性（建议平时多做必要的备份）
o vSphere VMFS Datastore 的 Metadata 一致性需要检查：
• 使用 vSphere On-disk Metadata Analyzer（VOMA）这个工具检查 VMFS Metadata 一致性：
▪ voma -m vmfs
• -d /vmfs/devices/disks/naa.000…0000:1
• -s /tmp/analysis.txt
o 通常出现下列情况下需要执行这个一致性检查：
• 更换过磁盘
• VMkernel.log 里报 Metadata 错误
• 在 VMFS Volume 上的文件无法给其它 ESXi Host 访问
o 当出现一致性问题时，建议执行如下动作：
• 重建 VMFS Datastore 后恢复之前的备份
• 实在不行，就找 Vendor 的 RD 了
4 、存储故障 02 - 多路径故障
• 利用如下 命令来查找关于 LUN 的路径信息：
o esxcli storage core path list
• 利用如下命令列出 LUN 的多路径配置信息
o esxcli storage nmp device list
• 检查是否需要执行 Rescan 重现 LUN
o esxcli storage core adapter rescan -A
• 故障原因分析逻辑
o 如果在/var/log/vmkernel.log 文件里看到关于 permanent data loss(PDL)或 all paths down（APD）之类的信息时，可以执行如下的故障排查流程
• PDL 的触发情况（vSphere 5.5 之后几乎不会发生）
• 计划外 PDL 修复
• APD 的触发情况
o 当存储在一定时间内无法被 ESXi Host 访问时 APD 可能发生：
• 这种情况一般都是短暂的，设备会很快重新可用（存储 IO 负载过大时 vSphere 可能会触发自动保护机制，暂时让存储离线）
o 可能导致 APD 的情况有如下：
• 存储设备从 ESXi Host 的移除动作并非计划内的
• VMkernel 无法检测到存储设备导致
• IP Storage 的前提下，网路连接中断导致所有 iSCSI 路径中断
• iSCSI HBA 卡本身固件版本故障
o 在 vSphere Web Client 里显示如下信息
• 设备变成了 Dead 或 Error 状态
• 所有存储路径变成 Dead 状态
• 设备上的所有 Datastore 不可用
• VMs 无法使用
• APD 的修复方式
o 当 host 到存储的连接出现 APD 时，想要在存储阵列或区域网路里面修复，则需要所有的 ESXiHost 重启
o 在 APD 情况下无法执行 vMotion
o 针对 APD 故障，ESXi Host 提供了一些缺省组件：
• 全局设定里，找到：Misc.APDHandlingEnable
▪ 缺省为 1，表示激活存储 APD 处理机制
• Timeout 设定，找到：Misc.APDTimeout
▪ 缺省为 140，这个数据表示 APD 故障的允许时间间隔，以秒为单位
• 检查 NIC Teaming 异常
o 对于 iSCSI Storage 来说，NIC Teaming 的配置是很重要的：
• 检查 Path Selection Policy 异常
o PSP 对于多路径来说，直接影响着活动链路状态和存储传输性能
四、针对 vCenter 和 和 ESXi 的故障排查
1 、vCenter SSO 架构回顾
2 、SSO 工作逻辑
3 、SSO 的 的 MultiSite
4 、SSO 故障
故障：SSO 无法自动发现信任域
• 通常是在先安装 SSO 后加域的情况下会出出现这种情况
• 安装之后尝试用命令来恢复--在 SSO 安装目录下，找到 utils 目录，执行命令：
o ssocli configure-riat -verbose -a discover-is -u admin -p
5 、vCenter 环境组件回顾
• VMware VirtualCenter Server service 和 Webservice Management 服务会随着 vCenter Server 自动启动
• vCenter 服务器与 DB 之间必须通过 ODBC 进行连接
故障一：VMware VirtualCenter Server 服务无法启动
• 在服务器管理器里查看该服务是否真的没有启动
• 查看 Windows Event 里面的相关错误提示信息
1 ） 、可能的故障排查逻辑
• 检查可能存在的相关问题，由于 OS 是正常的。因此，这个状态下仅仅可能由于 OS 内部的问题，在做排查时，应当重点关注到 vCenter Server 自身的一些问题
2 ） 、解决 ODBC 数据源配置故障问题
• 利用注册表检查 vCenter Server 使用的是哪个数据源
• 对比 ODBC 数据源设定，看看是否匹配
3 ） 、解决端口可能被占用的问题
• 在 vCenter 所在系统，执行如下命令：
o netstat -bano | more
• 如果端口被占用，则去掉冲突的服务，或者为 vCenter 配置其它端口【不推荐】
4 ） 、解决 VCMSDS 服务异常问题
•VMware VCMSDS 服务没有正常运行
o 打开 windows 的服务管理器，去看看这个 VCMSDS 服务是否正常运行
o 尝试重启这个服务，如果失败，请检查 windows 日志提示
故障二：vCenter Server 服务启动缓慢
• vCenter Server 数据库异常可能导致 vCenter Server 服务无法启动
• 检查 vCenter Server 对应的数据库配置是否满足下列要求
o 磁盘空间是否满了
o 检查 SQL 的相关信息（是否空间不足了）
o 检查 Oracle 数据库增长情况
o 检查 Oracle 或 SQL 数据表的大小
o 验证 vCenter 到数据库的授信有效性
1 ） 、解决 vCenter Server 数据库增长问题
• vCenter Server 数据库的增长会影响到 vCenter server 的性能
• vCenter Server 会收集下列数据库中的相关信息
o Performance data
o Tasks Events Logs
o Error Logs
• 大多数情况下，数据库的增长都是由于 Performance 数据库增长过快导致
2 ） 、 vCenter Server 常规增长数据表
• vCenter Server 的数据库自然包涵系列数据表，例如：
o vpx_hist_stat1 到 vpx_hist_stat4(包含 Performance 数据信息)
o vpx_sample_time1 到 vpx_sample_time4(在 vpx_hist_stat 表的相关 performance 的时间帧数据)
o vpx_event 和 vpx_event_arg(存放来自于 vCenter Server 中 Tasks and Events 页标签的 Event 数据信息)
o vpx_task(存放在 vCenter Server 中来自于 Tasks and Events 页标签的 Tasks 相关信息)
3 ） 、如何通过 Rollup Jobs 控制增长
• vpx_hist_stat1 和 vpx_sample_time1 表里的 Performance 数据会按照下面的状态进行归档：
o 汇总过去每天的 rollup 任务
o 相关任务会通过将数据插入到 vpx_hist_stat2 与 vpx_sample_time2 表来完成
•下面是不同的时间间隔的变化状态节点：
4 ） 、验证数据表尺寸
• 可以根据相关性能数据来判断 vCenter 的性能状况，可以执行如下步骤来查看性能相关的东西
o 从 vpx_hist_stat1 表开始，看看它的 size 是怎样的
o 通常可以接受的数据量在 10 million 以内，如果超过，则可能存在性能问题
• 如果觉得 Performance 数据没有问题，则请检查一下看看过去 24 小时是否存在较大数据变化的情况
5 ） 、解决由于数据增长过快导致的问题
• 确认 Statistic Rollup Jobs 的存在
• 确认 Datastore Server 的 MSQL agent 服务是否正常启动
• 确认 Statistic Collection Levels 不是设置的过高：
o 尽量让 Statistics Level 在 2 以下，VMware 不建议超过 Level2
o 如果为了做 debugging，则建议增加 Static Level，但是记得做完之后做回调操作
6 ） 、重新初始化 vCenter Server 数据库
• 可以有下列方式来重置 vCenter Server 数据库
o 重建 vCenter Server
o 找 VMware 厂家处理
o 压缩数据库
• 可以通过下列方式重置 vCenter 数据库配置
o 在 vCenter 服务器上，执行如下命令
• vpxd.exe -b C:\ProgramFiles\Vmware\Infrastructure\VirtualCenter
6 、ESXi 故障
故障一：ESXi Server 崩溃，出现紫屏的情况
• 主机 crash 会导致 PSOD 的出现
• 下列是几种典型的紫屏情况
o CPU exception
o Driver 或 module panic
o Machine check exception(MCE)
o Hardware fault
o 正版软件检测机制
PSOD 解决思路
• 记录下当前系统状态
o 将 PSOD 拍下来
o 记录下当时的相关故障场景
• 重启 ESXi Host
o 让 vm 能够正常启动
o 利用 vm-support 命令来收集主机上的故障包信息
• 联系 VMware 的技术支持力量
故障二：ESXi Host Hang 住
• ESXi host 可能由于下列问题 Hang 住
o 整个系统无响应
o 系统再重启后可能没能恢复正常
• 下面几种情况是 ESXi Host Hang 住的常见原因
o VMkernel 繁忙或者 deadlocked
o 硬件层面故障
1 ） 、验证 ESXi 是否 Hang 住
• 确认是否能做下列操作
o Ping VMkerenl
o 确认是否可以用 vSphere Client 去查询界面
o 监控 ESXi Host 与 VMs 之间是否有网路通讯
• 如果上述操作都能成功，则 ESXi Host 没有 hang 机
2 ） 、解决 ESXi Server Hang 掉的问题
• 重启 ESXi Server
• 通过下列确认为何会出现 hang 机情况
o 看日志
o 收集性能统计信息
• 如果是硬件故障，则在解决之后，尝试重装下 ESXi Host 或打个新补丁
五、常用的故障排查工具箱
1 、命令行工具介绍
• vSphere 支持的命令行工具很多，其中，可以用于排错的核心工具包括：
o DCUI 下的 ESXi Shell
o vSphere Management Asisstant(vMA)--基于网络
o vSphere Command Line Interface(vCLI)--基于网络
o ESXTOP（排错、监控、性能优化）
• ESXi Shell
o ESXi Shell 的访问途径有两种
• DCUI
• SSH
o SSH 访问 ESXi Shell 的方式
• 激活 ssh 访问服务
• 利用 Putty 之类的工具访问
• vMA
o vMA 是一个包含了下列内容的 Virtual Appliance
• vCLI 命令行
▪ 可以用这个命令行工具执行下面的命令管理 ESXi Host
• esxcli
• vim-cmd
• Vicfg-*
▪ 运行时，先执行命令连接到服务器
• vi-fastpass 授信组件
▪ 支持针对 vCenter Server 和 ESXi target 的授信
▪ 不用每次执行命令都需要输入权限信息
▪ 支持运行批处理脚本信息
o vMA 配置 Active Directory 授信
• 如果 ESXi Hosts 和 vCenter Server 加入了域，则可以通过 vMA 统一管理
▪ vMA 可以将 target 添加进来
▪ 相对而言，从安全角度而论 vi-fastpass 不如这个
• 为 vMA 配置 AD 前，建议做下列事情
▪ 确认 vMA 与 DNS 服务器在同一台 os
▪ 确认 vMA 可以访问 Domain
▪ 确认 IP 与 DNS 的解析无误
o 添加 vMA 到 AD
• 将 vMA 添加到 AD Doamin
▪ sudo domainjoin-cli join
• 检查 vMA 配置的 Domain 设定
▪ sudo domainjoin-cli query
• 为 AD 授信添加 target
▪ vifp addserver
ADDOMAIN\\
• 从 Doamin 删除掉 vMA
▪ sudo domainjoin-cli leave
• esxcli 命令介绍
o vSphere Storage 信息
• esxcli storage
▪ 可以获取存储多路径配置、LUN 信息和 Datastore 的相关设定
o esxcli network
• 可以查看网路相关的设定
o esxcli network vswitch standard
• 查看 vSS 的设定信息
o esxcli network vswith dvs
• 可以查看 vds 相关的信息，但不能用这条命令创建修改 vDS
o esxcli hardware
o vim-cmd -- 主要用于操作 ESXi Host、vCenter、虚拟机等信息
• 操作虚拟机
• 操作 ESXi Host
• 操作 vCenter
2 、vCenter Server 日志信息
• vCenter Server 包含了系列日志信息
• Windows 2003 的日志存放位置
o C:\Documents and Setting\All Users\Application Data\VMware VirtualCenter\Logs
• Windows 2008 的日志存放位置
o C:\ProgramData\VMware\VMware VirtualCenter\Logs
3 、ESXi Host 日志位置 -- /var/log
4 、vCenter Server 核心日志列表
5 、ESXi Host 日志清单
6 、vSphere Web Client 中的 Log Browser
7 、ESXi Host 的 DCUI 界面日志查看器
8 、vSphere Syslog Collector
9 、诊断数据收集之 vm-support
• 可以利用 vm-support 命令来收集诊断数据，发送给 VMware 技术支持部门进行故障排查
• 总体需要收集的信息如下
o Log files
o System status
o Configuration files
• vm-support 可以在 esxi host 上执行，然后收集相关的 Core 信息，收集到的信息格式为 xxxxxx-2016-08-21--.tgz
10 、vSphere Web Client 日志导出