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故障
- 故障原因分析:
- 2.1 快照问题修复
- 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 断开
- 3.1 ESXi主机网络连接不稳定或者瞬断
- 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修复
- 4.1 IP storage无法被ESXi主机访问
- 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 常规故障分层
编号 | 故障 | 说明 |
---|---|---|
5 | 应用程序 | |
4 | 虚拟机操作系统故障 | |
3 | 虚拟机故障 | |
2 | ESXi Host 故障 | |
1 | 物理设备硬件故障 |
2 虚拟机的故障排查
排查方向:
- 快照
- 能不能开机
- 能不能连接
- vmware tools 是不是有问题
2.1 快照问题修复
虚拟机文件架构:
![VM文件架构][VM文件架构]
CID(content ID),位于VM的磁盘描述文件里面负责磁盘相关整合状态跟踪
- 如果没有做快照,则原始的parentCID=ffffffff
- 如果做了快照,母盘的CID是第一个快照盘的parentCID
- 第二级快照的parentCID是第一级快照的CID,依次类推
- 第二级快照和原始盘没有关系,快照层级出问题一般为CID无法对应
2.1.1 解决CID不匹配问题
- 备份好磁盘描述文件
- 用文本编辑器打开文件,修改CID
- 使用
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
编号 | 检查层级 | 可能存在的问题 |
---|---|---|
1 | vcenter | vmotion 或者 DRS 导致问题 |
2 | vm | 没通过vcenter执行了对vm的删除动作 |
3 | vm | *.vmx 文件有故障 |
4 | ESXi 主机 | 当 ESXi 的根文件系统空间不足时可能会尝试删除动作 |
2.4.1 vmotion 或者 DRS 导致问题
- 查看tasks页标签
- 检查orphaned虚拟机被注册到的源或目标 ESXi Host
如果有找到虚拟机被注册到 ESXi Host
- 重启 ESXi Host 的管理服务
如果没有找到虚拟机被注册的信息,则执行
- 注册虚拟机到 ESXi 或者 vcenter
- 利用orphaned虚拟机的vmdk创建新的虚拟机
2.4.2 没有通过vcenter删除导致故障
使用ls命令查看虚拟机文件是否存在
如果配置文件被删除,则使用vmdk重建虚拟机
如果虚拟机的磁盘文件被删除,则执行备份恢复
2.4.3 vmx 文件被破坏导致故障
- 利用文本编辑器编辑vmx文件,去掉不当 的部分重试
- 从备份信息里恢复vmx文件
- 直接移除虚拟机,然后使用vmdk重建虚拟机
2.4.4 ESXi 根文件系统空间不足导致故障
- 当ESXi的根文件系统空间不足时,系统可能会尝试删除除掉虚拟机
- 清除掉根文件系统里的不必要内容
- 从inventory移除掉vm,再重新添加
2.5 vm snapshot故障
- 确认虚拟机的磁盘是否支持snapshot,因为RDM的physical mode,independent disk 状态下是无法做快照的
- 由于snapshot最多支持32级,因此,超过后会无法执行
故障原因分析:
- vcenter 用户没权限执行快照
- vm 虚拟机的-delta.vmdk 文件在描述信息里错乱
- ESXi 快照文件超过datastore的上线,datastore剩余空间不足以支撑所有的快照处理
3 networking 子系统故障查询
层级 | 查看内容 |
---|---|
物理环境 | 交换机、VLAN、策略 |
虚拟环境 | vswitch、portgroup、teaming、policy |
虚拟机 | vmOS、vNIC |
3.1 ESXi主机网络连接不稳定或者瞬断
3.1.1 检查过程
- DCUI界面 ping 外部地址(如果可以ping通则表明没有问题)
原理解析:ESXi 通过VMkernel 再通过 物理网卡连接外部网络,若ping不通,则说明vmkernel到物理网卡或者外部网络之间有故障
可能故障原因:
- ESXi主机
- ESXi的管理网络配置不正确
- port group的VLAN ID不对
- 网络卡的双工速率与P switch不匹配
- 网络连接中断
- NIC teaming的policy配置不当
- 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 |
|
添加port group | esxcfg-vswitch -A |
|
添加上行链路 | esxcfg-vswitch -L |
port group VLAN 设定调整:
esxcli network vswitch standard portgroup set -p -v
速率和双工模式调整:
esxcfg-nics -d -s 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做备用的准备
可能故障原因:
- windows版防火墙block了UDP 902 端口
- vcenter 没使用902端口来发送和接收心跳,且ESXi block 了这个端口(vcenter的心跳端口配置可以在
/etc/vmware/vpxa/vpxa.cfg
中查看,ESXi的heartbeat端口在heartbeat.xml
文件中) - ESXi与vcenter之间的通讯拥塞
4 storage 的故障排查
故障类型:
- 存储连接故障
- 多路径故障
4.1 IP storage无法被ESXi主机访问
存储信息验证:
excli storage core path list ///确认ESXi主机能够看到存储(能够看到说明硬件层面没问题)
esxcli storage core adapter rescan -A ///执行后一般能够恢复(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 硬件问题检查
- iSCSI HBA卡或者iSCSI storage 阵列不被ESXi支持:可以在vmware的HCL里查看型号
- 确认LUN被正确的映射到适当的ESXi上
- 同一个存储组里的LUN是否被映射到所有ESXi上
- LUN的构建是否符合ESXi的使用标准
- LUN是否被设定为R/O
- 阵列上For ESXi的HOST ID是否小于255
- 存储设备故障:利用硬件工具诊断存储故障
- 存储性能检查:esxtop/resxtop后输入d查看
4.2 多路径故障
excli storage core path list ///确认ESXi主机能够看到存储(能够看到说明硬件层面没问题)
excli storage nmp device list ///LUN的多路径配置信息
esxcli storage core adapter rescan -A ///执行后一般能够恢复(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触发情况
- 当存储永久性无法被ESXi访问时,存储可能回出现PDL状态
- 可能导致PDL的因素大致有如下方面
- 设备无意中被误删除了
- 设备的unique ID被手动更改了
- 设备发生了知名硬件故障
- 设备空间爆掉导致无法访问
- vsphere web client里体现形式
- 在设备的操作状态变成了lost communication
- 所有链路都变成了dead状态
- 设备上的datastore不可用
4.2.3 PDL修复
- 如果LUN在PDL发生时没有使用,可能回发生如下情况:PDL发生后LUN会消失
- 如果LUN在PDL发生时在使用,则需要从ESXi上手动detach和remove
- 执行完对存储的重新配置后需要:1.重新attach存储设备;2.重新mount datasore;3.重启虚拟机
4.2.4 APD触发情况
- 当存储在一定时间内无法被ESXi访问时APD就可能发生:比较短暂,设备很快重新可用
- 可能导致APD的情况如下:
- 存储设备从ESXi的一重动作并非计划内的
- VMkernel无法检测到存储设备导致
- IP storage 的前提下,网络连接中断导致所有的iSCSI路径中断
- iSCSi HBA卡本身的固件版本故障
- vsphere web client里体现形式
- 设备变成了desd或者error状态
- 所有存储路径变成了dead
- 设备上所有的datastore不可用
- vm无法使用
4.2.5 APD修复
- 当主机到存储连接出现APD时,想要在存储阵列或者区域网络里修复,需要:所有的ESXi重启
- 在APD情况下无法执行vmotion操作
- 针对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
5.2 vcenter: VMware VirtualCenter Server 服务无法启动
- 在操作系统层面查看服务是否真的没有启动
- 检查数据库,是否正常
可能存在的问题:
- ODBC数据源配置故障(windows vcenter)
- 检查902、80、443端口是否被占用
5.3 vcenter: 服务启动缓慢
- 数据库异常可能导致服务无法启动
- 检查vcenter server对应数据库配置是否满足下列要求:
- 磁盘空间满了
- 数据库增长情况
- vcenter到数据库的受信有效性
5.4 ESXi: 奔溃,出现紫屏
可能原因:
- CPU 争用
- 正版软件检测机制
- 驱动或者模块 panic
- MCE 自检失败
- 硬件故障
5.5 ESXi: hang死
可能原因:
- VMkernel繁忙或者deadlocked了
- 硬件层面故障
表现形式:
- 整个系统无响应
- 系统在重启后可能没有恢复正常
验证主机状态:
- ping vmkernel 网络配置
- 确认是否可以使用web client 去查询界面
- 监控ESXi与vm之间是否有网络通讯
- 以上都成功,则没有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启动、关闭、心跳时间、虚拟机运行、服务资源开销等记录 |