好文收藏

vsphere 故障排查

2019-08-09  本文已影响17人  迷鹿milu

vsphere 故障排查

1 vSphere 排错思想

  确认问题状况：

  确认导致故障的原因：

  解决问题：

1.1 故障排查逻辑

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

1.2 常规故障分层

编号 故障 说明
5 应用程序
4 虚拟机操作系统故障
3 虚拟机故障
2 ESXi Host 故障
1 物理设备硬件故障

2 虚拟机的故障排查

  排查方向：

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

2.1 快照问题修复

  虚拟机文件架构：

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

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

2.1.1 解决CID不匹配问题

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

2.1.2 vss导致snapshot失败

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

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

  解决过程：

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

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

2.2 开启虚拟机失败

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

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

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

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

  解决方案：

  分析虚机是否被锁定：

2.3 vm tools 无法安装

2.4 vm orphaned

编号 检查层级 可能存在的问题
1 vcenter vmotion 或者 DRS 导致问题
2 vm 没通过vcenter执行了对vm的删除动作
3 vm *.vmx 文件有故障
4 ESXi 主机 当 ESXi 的根文件系统空间不足时可能会尝试删除动作

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级，因此，超过后会无法执行

故障原因分析：

3 networking 子系统故障查询

层级 查看内容
物理环境 交换机、VLAN、策略
虚拟环境 vswitch、portgroup、teaming、policy
虚拟机 vmOS、vNIC

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

3.1.1 检查过程

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

  可能故障原因：

  1. ESXi主机
  1. 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的修复

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

操作 命令 说明
添加vSS esxcfg-vswitch -a <vswitch#>
添加port group esxcfg-vswitch -A <pg_name> vswitch#
添加上行链路 esxcfg-vswitch -L <vmnic#> vswitch#

  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虚拟机也失败

编号 层级 可能的原因 备注
1 操作系统 IP配置错误
2 操作系统 防火墙策略配置错误
3 操作系统 网络卡型号选择错误
4 VM 虚拟机的port group不存在
5 VM 虚拟机的网络卡配置异常
6 ESXi 网络连接故障
7 ESXi 存在存储或资源争用 处理办法：迁移
8 ESXi vSS的port数量不足以支撑vm的连接数量 可以修改数量，但是需要重启ESXi

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正常，在没有做任何变更的情况下出现故障，则可以参考如下流程，进行故障解决尝试

编号 层级 故障原因 备注
1 ESXi VMkernel接口配置丢失
2 ESXi IP storage 访问ESXi的配置异常
3 ESXi iSCSI TCP 端口 3260 不可达
4 ESXi 防火墙干扰了iSCSI通讯流量
5 ESXi NFS存储配置异常
6 ESXi VMFS Datastore 存储 Metadata 被破坏
7 硬件 iSCSI存储阵列不被支持
8 硬件 LUN没有被正确的映射到适当的ESXi
9 硬件 物理硬件故障
10 硬件 iSCSI storage 性能不足

4.1.2 硬件问题检查

  1. iSCSI HBA卡或者iSCSI storage 阵列不被ESXi支持：可以在vmware的HCL里查看型号
  2. 确认LUN被正确的映射到适当的ESXi上
  1. 存储设备故障：利用硬件工具诊断存储故障
  2. 存储性能检查：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) 之类的信息时，可以执行如下的故障排查流程

编号 层级 故障原因 备注
1 ESXi iSCSI storage 需要去检查是否NIC teaming 配置异常
2 ESXi 检查存储设备的路径选择策略(PSP)是否异常
3 硬件 检查是否发生了PDL
4 硬件 检查是否发生了APD

4.2.2 PDL触发情况

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

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的情况如下：
  1. vsphere web client里体现形式

4.2.5 APD修复

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

5 vcenter&ESXi 故障排查

5.1 SSO故障

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

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

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

  可能存在的问题：

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

5.3 vcenter: 服务启动缓慢

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

5.4 ESXi: 奔溃，出现紫屏

  可能原因：

5.5 ESXi: hang死

  可能原因：

  表现形式：

  验证主机状态：

6 常用故障排查工具

编号 工具 备注
1 vMA 统一管理ESXi(作为排错工具价值比较小，排错基本没有网络环境)
2 esxcli 随着VMware的版本升级，功能越来越多
3 vim-cmd 主要对ESXi和虚拟机操作(不建议对vcenter进行操作，而且操作有限，风险较高)

6.1 vcenter核心日志列表

日志文件 用途
vpxd.log 存放了vsphere client、vsphere web services SDK连接、 Tasks、Events已及与vpxa通讯记录
vpxd-profiler.log、profiler.log、scoreboard.log vcenter的配置相关信息
cim-diag.log(vws.log) CIM监控信息，vcenter与ESXi的CIM通讯信息记录

6.2 ESXi核心日志列表

日志文件 用途
hostd.log ESXi Host的管理服务
syslog.log 记录管理服务的初始化、watchdogs、计划任务和DCUI的使用记录和信息
vmkernel.log vmkernel日志，包含设备发现、存储、网络设备、驱动和虚拟机启动的信息
vmkwarning.log vmkernel日志当中关于警告、事件等日志信息
vmksummary.log 记录ESXi启动、关闭、心跳时间、虚拟机运行、服务资源开销等记录
上一篇下一篇

猜你喜欢

热点阅读