vsphere 故障排查

• vsphere 故障排查
• 1 vSphere 排错思想
  • 1.1 故障排查逻辑
  • 1.2 常规故障分层
• 2 虚拟机的故障排查
  • 2.1 快照问题修复
    • 2.1.1 解决CID不匹配问题
    • 2.1.2 vss导致snapshot失败
  • 2.2 开启虚拟机失败
  • 2.3 vm tools 无法安装
  • 2.4 vm orphaned
    • 2.4.1 vmotion 或者 DRS 导致问题
    • 2.4.2 没有通过vcenter删除导致故障
    • 2.4.3 vmx 文件被破坏导致故障
    • 2.4.4 ESXi 根文件系统空间不足导致故障
  • 2.5 vm snapshot故障
    • 故障原因分析：
• 3 networking 子系统故障查询
  • 3.1 ESXi主机网络连接不稳定或者瞬断
    • 3.1.1 检查过程
    • 3.1.2 ESXi网络配置验证(检查)
    • 3.1.3 ESXi 配置问题修复
    • 3.1.4 硬件功能验证
    • 3.1.5 查看是否网络性能低下
  • 3.2 虚拟机网络中断
  • 3.3 ESXi 频繁从 vcenter 断开
• 4 storage 的故障排查
  • 4.1 IP storage无法被ESXi主机访问
    • 4.1.1 故障原因分析
    • 4.1.2 硬件问题检查
  • 4.2 多路径故障
    • 4.2.1 故障原因分析
    • 4.2.2 PDL触发情况
    • 4.2.3 PDL修复
    • 4.2.4 APD触发情况
    • 4.2.5 APD修复
• 5 vcenter&ESXi 故障排查
  • 5.1 SSO故障
  • 5.2 vcenter: VMware VirtualCenter Server 服务无法启动
  • 5.3 vcenter: 服务启动缓慢
  • 5.4 ESXi: 奔溃，出现紫屏
  • 5.5 ESXi: hang死
• 6 常用故障排查工具
  • 6.1 vcenter核心日志列表
  • 6.2 ESXi核心日志列表

1 vSphere 排错思想

  确认问题状况：

• 确认问题所在
• 收集故障相应日志或者资料

  确认导致故障的原因：

• 确认什么原因导致的问题
• 诊断问题的根本原因是什么

  解决问题：

• 制定可嫩的解决方案
• 评估数据安全风险
• 执行最佳解决方案

1.1 故障排查逻辑

![故障排查逻辑][故障排查逻辑]

1.2 常规故障分层

2 虚拟机的故障排查

  排查方向：

1. 快照
2. 能不能开机
3. 能不能连接
4. vmware tools 是不是有问题

2.1 快照问题修复

  虚拟机文件架构：

![VM文件架构][VM文件架构]

  CID(content ID)，位于VM的磁盘描述文件里面负责磁盘相关整合状态跟踪

• 如果没有做快照，则原始的parentCID=ffffffff
• 如果做了快照，母盘的CID是第一个快照盘的parentCID
• 第二级快照的parentCID是第一级快照的CID，依次类推
• 第二级快照和原始盘没有关系，快照层级出问题一般为CID无法对应

2.1.1 解决CID不匹配问题

1. 备份好磁盘描述文件
2. 用文本编辑器打开文件，修改CID
3. 使用 vmkfstools -q ******.vmdk -v10 验证CID是否修改成功，如果提示失败，则修改没有成功

2.1.2 vss导致snapshot失败

  执行snapshot时，提示I/O静默调用失败

• 虚拟机由大量的I/O负载导致在执行snapshot时I/O Quiescing失败
• 通常通过以下两个技术来执行I/O Quisescing

Microsoft Volume Shadow Copy Service(vss)
VMware Tools SYNC driver

• 初始化检查：检查是否可以手动创建一个不调用I/O Quiescing的快照

  解决过程：

• 如果利用vss执行I/O Quiescing，则需要确认下列条件满足：

vss要求满足
相关服务是正常运行状态
Microsoft Volume Shadow Copy Service正常
vss writer没报错

• 如果利用SYNC Driver执行I/O Quiescing，则需要确认下列条件满足：

禁止掉SYNC Driver
在执行snapshot之前，先将I/O密集业务停掉

• 老版本的windows os没包含SYNC Driver在Microsoft vss里面

2.2 开启虚拟机失败

  在 vmware.log 文件里可以看到虚拟机开启失败的原因

  虚拟机层面：部分文件丢失，或者部分文件处于锁定状态

  ESXi host层面：是否由足够的资源，ESXi主机是否有响应

ls /vmfs/volumes/Shared/VMname      ##查看虚机文件

  解决方案：

• 利用之前的备份来恢复
• 如果 descriptor 文件丢失，手动重建这个文件

  分析虚机是否被锁定：

• 尝试开机，如果失败，则可能有锁定
• 执行touch filename 命令查看是否有文件被锁定
• 执行vmkfstools -D /vmfs/volumes/Shared/vmname/****-flat.vmdk 查看哪台ESXi主机锁定了该文件
• 执行lsof | grep <被锁定文件名>
• 杀掉相应的进程

2.3 vm tools 无法安装

• 检查 guest os 类型选择是否正确
• vmware tools iso 的匹配错误
• vmware tools iso 无法找到
• vmware tools iso 镜像故障

2.4 vm orphaned

• 检查vcenter Server是否在VM执行迁移时重启过，因为在虚拟机被重启时，会临时性的无法使用，状态就会显示为orphaned

2.4.1 vmotion 或者 DRS 导致问题

1. 查看tasks页标签
2. 检查orphaned虚拟机被注册到的源或目标 ESXi Host

  如果有找到虚拟机被注册到 ESXi Host

1. 重启 ESXi Host 的管理服务

  如果没有找到虚拟机被注册的信息，则执行

1. 注册虚拟机到 ESXi 或者 vcenter
2. 利用orphaned虚拟机的vmdk创建新的虚拟机

2.4.2 没有通过vcenter删除导致故障

  使用ls命令查看虚拟机文件是否存在
  如果配置文件被删除，则使用vmdk重建虚拟机
  如果虚拟机的磁盘文件被删除，则执行备份恢复

2.4.3 vmx 文件被破坏导致故障

1. 利用文本编辑器编辑vmx文件，去掉不当 的部分重试
2. 从备份信息里恢复vmx文件
3. 直接移除虚拟机，然后使用vmdk重建虚拟机

2.4.4 ESXi 根文件系统空间不足导致故障

1. 当ESXi的根文件系统空间不足时，系统可能会尝试删除除掉虚拟机
2. 清除掉根文件系统里的不必要内容
3. 从inventory移除掉vm，再重新添加

2.5 vm snapshot故障

1. 确认虚拟机的磁盘是否支持snapshot，因为RDM的physical mode，independent disk 状态下是无法做快照的
2. 由于snapshot最多支持32级，因此，超过后会无法执行

故障原因分析：

• vcenter 用户没权限执行快照
• vm 虚拟机的-delta.vmdk 文件在描述信息里错乱
• ESXi 快照文件超过datastore的上线，datastore剩余空间不足以支撑所有的快照处理

3 networking 子系统故障查询

3.1 ESXi主机网络连接不稳定或者瞬断

3.1.1 检查过程

• DCUI界面 ping 外部地址(如果可以ping通则表明没有问题)

原理解析：ESXi 通过VMkernel 再通过 物理网卡连接外部网络，若ping不通，则说明vmkernel到物理网卡或者外部网络之间有故障

  可能故障原因：

1. ESXi主机

• ESXi的管理网络配置不正确
• port group的VLAN ID不对
• 网络卡的双工速率与P switch不匹配
• 网络连接中断
• NIC teaming的policy配置不当

2. hardware

• 物理网络卡不在兼容列表范畴
• 物理设备本身故障
• 网络性能低下

3.1.2 ESXi网络配置验证(检查)

  配置验证(ESXi SHELL)

  检查vSS、vmnics和port groups

esxcfg-vswitch -l

  检查port groups的VLAN ID：

esxcli network vswitch standard portgroup list

  检查速率和双工模式：

esxcfg-nics -l

  检查网络连接状态：

esxcffg-nics -l

3.1.3 ESXi 配置问题修复

  针对vSS、vmnics和port groups的修复

下表中带有#符号的设备皆为设备编号

  port group VLAN 设定调整:

esxcli network vswitch standard portgroup set -p <pg_name> -v <vlan_id> 

  速率和双工模式调整:

esxcfg-nics -d <duplex> -s <speed> vmnic# 

3.1.4 硬件功能验证

  查看硬件信息，然后在官网的HCL查询设备是否在兼容列表中

esxcfg-nics -l

lspci -p        ###查看是否由硬件故障导致

3.1.5 查看是否网络性能低下

  esxtop或者resxtop

3.2 虚拟机网络中断

从虚拟及ping其他vm或者ESXi主机失败，同时从其他设备ping虚拟机也失败

3.3 ESXi 频繁从 vcenter 断开

ESXi 可以成功添加到vcenter 但是每隔30-90秒会自动断开
Dropped、blocked或丢失heartbeat包在vcenter与ESXi之间频繁发生

  vcenter与ESXi之间的通讯结构

  ESXi会发送心跳到vcenter(UDP 902断口)，目的：确定连接是否正常，HA做备用的准备

  可能故障原因：

1. windows版防火墙block了UDP 902 端口
2. vcenter 没使用902端口来发送和接收心跳，且ESXi block 了这个端口(vcenter的心跳端口配置可以在/etc/vmware/vpxa/vpxa.cfg中查看，ESXi的heartbeat端口在heartbeat.xml文件中)
3. ESXi与vcenter之间的通讯拥塞

4 storage 的故障排查

  故障类型：

1. 存储连接故障
2. 多路径故障

4.1 IP storage无法被ESXi主机访问

  存储信息验证：

excli storage core path list      ///确认ESXi主机能够看到存储(能够看到说明硬件层面没问题)

esxcli storage core adapter rescan -A <vmhba##>     ///执行后一般能够恢复(target到initiator之间的重新握手)

4.1.1 故障原因分析

如果ESXi过去访问IP storage正常，在没有做任何变更的情况下出现故障，则可以参考如下流程，进行故障解决尝试

4.1.2 硬件问题检查

1. iSCSI HBA卡或者iSCSI storage 阵列不被ESXi支持：可以在vmware的HCL里查看型号
2. 确认LUN被正确的映射到适当的ESXi上

• 同一个存储组里的LUN是否被映射到所有ESXi上
• LUN的构建是否符合ESXi的使用标准
• LUN是否被设定为R/O
• 阵列上For ESXi的HOST ID是否小于255

3. 存储设备故障：利用硬件工具诊断存储故障
4. 存储性能检查：esxtop/resxtop后输入d查看

4.2 多路径故障

excli storage core path list      ///确认ESXi主机能够看到存储(能够看到说明硬件层面没问题)

excli storage nmp device list     ///LUN的多路径配置信息

esxcli storage core adapter rescan -A <vmhba##>     ///执行后一般能够恢复(target到initiator之间的重新握手)

4.2.1 故障原因分析

如果在 /var/log/vmkernel.log 文件里看到关于 permanent data loss (PDL) 或 all paths down (APD) 之类的信息时，可以执行如下的故障排查流程

4.2.2 PDL触发情况

1. 当存储永久性无法被ESXi访问时，存储可能回出现PDL状态
2. 可能导致PDL的因素大致有如下方面

• 设备无意中被误删除了
• 设备的unique ID被手动更改了
• 设备发生了知名硬件故障
• 设备空间爆掉导致无法访问

3. vsphere web client里体现形式

• 在设备的操作状态变成了lost communication
• 所有链路都变成了dead状态
• 设备上的datastore不可用

4.2.3 PDL修复

1. 如果LUN在PDL发生时没有使用，可能回发生如下情况：PDL发生后LUN会消失
2. 如果LUN在PDL发生时在使用，则需要从ESXi上手动detach和remove
3. 执行完对存储的重新配置后需要：1.重新attach存储设备；2.重新mount datasore；3.重启虚拟机

4.2.4 APD触发情况

1. 当存储在一定时间内无法被ESXi访问时APD就可能发生：比较短暂，设备很快重新可用
2. 可能导致APD的情况如下：

• 存储设备从ESXi的一重动作并非计划内的
• VMkernel无法检测到存储设备导致
• IP storage 的前提下，网络连接中断导致所有的iSCSI路径中断
• iSCSi HBA卡本身的固件版本故障

3. vsphere web client里体现形式

• 设备变成了desd或者error状态
• 所有存储路径变成了dead
• 设备上所有的datastore不可用
• vm无法使用

4.2.5 APD修复

1. 当主机到存储连接出现APD时，想要在存储阵列或者区域网络里修复，需要：所有的ESXi重启
2. 在APD情况下无法执行vmotion操作
3. 针对APD的故障，ESXi提供了一些缺省组件

• 全局设定里，找到Misc.APDHandlingEnable：缺省为1，表示激活存储的APD处理机制
• Timeout设定，找到Misc.APDTimeout：缺省为140，这个数据表示APD故障的允许时间间隔

5 vcenter&ESXi 故障排查

5.1 SSO故障

  SSO无法发现信任域(先加域，再安装，养成良好的操作习惯)：

• 通常实在先安装SSO后加域的情况下会出现这种情况
• 安装完之后尝试使用命令来恢复：在SSO安装目录的utils目录ssocli configure-riat verbose -a discover-is -u admin -p <password>

5.2 vcenter: VMware VirtualCenter Server 服务无法启动

1. 在操作系统层面查看服务是否真的没有启动
2. 检查数据库，是否正常

  可能存在的问题：

1. ODBC数据源配置故障(windows vcenter)
2. 检查902、80、443端口是否被占用

5.3 vcenter: 服务启动缓慢

1. 数据库异常可能导致服务无法启动
2. 检查vcenter server对应数据库配置是否满足下列要求：

• 磁盘空间满了
• 数据库增长情况
• vcenter到数据库的受信有效性

5.4 ESXi: 奔溃，出现紫屏

  可能原因：

• CPU 争用
• 正版软件检测机制
• 驱动或者模块 panic
• MCE 自检失败
• 硬件故障

5.5 ESXi: hang死

  可能原因：

• VMkernel繁忙或者deadlocked了
• 硬件层面故障

  表现形式：

• 整个系统无响应
• 系统在重启后可能没有恢复正常

  验证主机状态：

• ping vmkernel 网络配置
• 确认是否可以使用web client 去查询界面
• 监控ESXi与vm之间是否有网络通讯
• 以上都成功，则没有hang死

6 常用故障排查工具

6.1 vcenter核心日志列表

6.2 ESXi核心日志列表