如何进行VMwareESXi宕机的分析-古蔺大橙子建站
RELATEED CONSULTING
相关咨询
选择下列产品马上在线沟通
服务时间:8:30-17:00
你可能遇到了下面的问题
关闭右侧工具栏

新闻中心

这里有您想知道的互联网营销解决方案
如何进行VMwareESXi宕机的分析

如何进行VMware ESXi 宕机的分析,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。

靖远ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为创新互联公司的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:18982081108(备注:SSL证书合作)期待与您的合作!

近期发现ESXI主机宕机导致视频会议系统故障,整理分析过程如下:
环境为ESXi 6.0,被vCenter 6.7U1管理,宕机后并未拍屏幕而直接重启了主机。

  1. 从vCenter层面收集ESXi 系统日志,只看到实时日志,未看到宕机前的日志信息。

  2. ssh 连接到esxi,   cd /var/log也未看到压缩的历史日志文件,从vmksummary.log看到主机重启后的时间,并有提示已经找到DUMP文件,故障时间点基本确认

2019-04-16T19:54:13Z bootstop: Host has booted                                                                                                                                  
2019-04-16T19:54:13Z bootstop: partition core dump found

  1. cd /scratch  看到有log文件夹,ls log 看到了大量压缩的历史日志文件

如何进行VMware ESXi 宕机的分析

原来日志被重定向到这里来了。

4、根据时间点查看历史日志文件内容,并未发现有用信息。

5、ls /scratch/core  看到有一个vmkernel-zdump.1 的dump文件,基本确认主机发了生紫屏才宕机的

6、如何分析打开这个文件呢?网上查询了VM 也有KB说明,根据KB使用一个命令:
vmkdump -l vmkernel-zdump.1 会创建一个vmkernel.log.1 的文件,可用cat 或vi或其它文本工具查看:
^[[7m2019-04-15T11:31:36.550Z cpu30:32805)WARNING: Heartbeat: 781: PCPU 26 didn't have a heartbeat for 21 seconds; may be locked up.^[[0m
^[[31;1m2019-04-15T11:31:36.550Z cpu26:33339)ALERT: NMI: 681: NMI IPI recvd. We Halt. eip(base):ebp:cs [0x3080cd(0x41800d800000):0x1:0x4010](Src0x1, CPU26)^[[0m
2019-04-15T11:31:36.550Z cpu30:32805)World: 9729: PRDA 0x418047800000 ss 0x0 ds 0x10b es 0x10b fs 0x10b gs 0x0
2019-04-15T11:31:36.550Z cpu30:32805)World: 9731: TR 0x4020 GDT 0x4392ef421000 (0x402f) IDT 0x41800d8c9000 (0xfff)
2019-04-15T11:31:36.550Z cpu26:33339)0x4390d1d9b560:[0x41800db080cd]MemNode_NUMANodeMask2MemNodeMask@vmkernel#nover+0x25 stack: 0x1
2019-04-15T11:31:36.550Z cpu30:32805)World: 9732: CR0 0x80010031 CR3 0x6c4ed1000 CR4 0x42768
2019-04-15T11:31:36.550Z cpu26:33339)0x4390d1d9b580:[0x41800db45622]MemDistributeNUMAPolicy@vmkernel#nover+0x27a stack: 0x0
2019-04-15T11:31:36.550Z cpu26:33339)0x4390d1d9b6c0:[0x41800db4616d]MemDistribute_Alloc@vmkernel#nover+0x299 stack: 0xe59bb55
2019-04-15T11:31:36.550Z cpu26:33339)0x4390d1d9b820:[0x41800d8181f0]PagePool_AllocCustom@vmkernel#nover+0x2f0 stack: 0x4390d1d9bac0
2019-04-15T11:31:36.550Z cpu26:33339)0x4390d1d9b8e0:[0x41800d820c04]vmk_MemPoolAlloc@vmkernel#nover+0x37c stack: 0x41800dfad8b1
2019-04-15T11:31:36.550Z cpu26:33339)0x4390d1d9bd90:[0x41800dfad8b1]fusion_get_seq_num@#+0xd9 stack: 0x43034ef4cc40
2019-04-15T11:31:36.550Z cpu26:33339)0x4390d1d9bea0:[0x41800dfa2adb]megasas_hotplug_work@#+0x16b stack: 0x0
2019-04-15T11:31:36.550Z cpu26:33339)0x4390d1d9bf20:[0x41800d82245f]VmkTimerQueueWorldFunc@vmkernel#nover+0x21f stack: 0x0
2019-04-15T11:31:36.550Z cpu26:33339)0x4390d1d9bfd0:[0x41800da13dae]CpuSched_StartWorld@vmkernel#nover+0xa2 stack: 0x0
2019-04-15T11:31:36.600Z cpu30:32805)Panic: 798: Saved backtrace: pcpu 26 Heartbeat NMI
2019-04-15T11:31:36.600Z cpu30:32805)pcpu 26 Heartbeat NMI: 0x4390d1d9b560:[0x41800db080cd]MemNode_NUMANodeMask2MemNodeMask@vmkernel#nov
2019-04-15T11:31:36.600Z cpu30:32805)pcpu 26 Heartbeat NMI: 0x4390d1d9b580:[0x41800db45622]MemDistributeNUMAPolicy@vmkernel#nover+0x27a
2019-04-15T11:31:36.600Z cpu30:32805)pcpu 26 Heartbeat NMI: 0x4390d1d9b6c0:[0x41800db4616d]MemDistribute_Alloc@vmkernel#nover+0x299 stac
2019-04-15T11:31:36.600Z cpu30:32805)pcpu 26 Heartbeat NMI: 0x4390d1d9b820:[0x41800d8181f0]PagePool_AllocCustom@vmkernel#nover+0x2f0 sta
2019-04-15T11:31:36.600Z cpu30:32805)pcpu 26 Heartbeat NMI: 0x4390d1d9b8e0:[0x41800d820c04]vmk_MemPoolAlloc@vmkernel#nover+0x37c stack:
2019-04-15T11:31:36.600Z cpu30:32805)pcpu 26 Heartbeat NMI: 0x4390d1d9bd90:[0x41800dfad8b1]fusion_get_seq_num@#+0xd9 stack:
2019-04-15T11:31:36.600Z cpu30:32805)pcpu 26 Heartbeat NMI: 0x4390d1d9bea0:[0x41800dfa2adb]megasas_hotplug_work@#+0x16b stac
2019-04-15T11:31:36.600Z cpu30:32805)pcpu 26 Heartbeat NMI: 0x4390d1d9bf20:[0x41800d82245f]VmkTimerQueueWorldFunc@vmkernel#nover+0x21f s
2019-04-15T11:31:36.600Z cpu30:32805)pcpu 26 Heartbeat NMI: 0x4390d1d9bfd0:[0x41800da13dae]CpuSched_StartWorld@vmkernel#nover+0xa2 stack
2019-04-15T11:31:36.623Z cpu30:32805)^[[45m^[[33;1mVMware ESXi 6.0.0 [Releasebuild-3073146 x86_64]^[[0m
PCPU 26: no heartbeat (2/2 IPIs received)

基本确认主机宕机原因是Esxi 主机无法与CPU通信(通信超时21秒)导致。

vCPU分配过多了??检查了下vCPU 数量小于LCPU。

7、通过关键字进行搜索“POSD no heartbeat”,未找到此故障原因,国外网友也有类似问题,只查到建议是升级ESXi。

8、最后一在篇ESXi 6.0U2发行说明“已解决问题”看到解决了“no heartbeat”的问题:

ESXi 主机显示紫色诊断屏幕并显示多条“可更正计算机检查中断”(CMCI) 消息

由于短时间内 vmkernel.log 文件中的多个 CMCI 导致 CPU 无响应,ESXi 主机可能会失败并显示紫色诊断屏幕。紫色诊断屏幕中会显示类似以下内容的条目:

ESXi 主机显示紫色诊断屏幕并显示多条“可更正计算机检查中断”(CMCI) 消息

由于短时间内 vmkernel.log 文件中的多个 CMCI 导致 CPU 无响应,ESXi 主机可能会失败并显示紫色诊断屏幕。紫色诊断屏幕中会显示类似以下内容的条目:

PCPU : no heartbeat (2/2 IPIs received)0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]MCEReapMCABanks@vmkernel#nover+0x195
br/>0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]IRQ_DoInterrupt@vmkernel#nover+0x33e
br/>0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]BH_DrainAndDisableInterrupts@vmkernel#nover+0xf3

将向 vmkernel.log 文件中记录类似于以下内容的条目:

cpu1:33127)MCE: 1118: cpu1: MCA error detected via CMCI (Gbl status=0x0): Restart IP: invalid, Error IP: invalid, MCE in progress: no.
cpu1:33127)MCE: 231: cpu1: bank9: MCA recoverable error (CE): "Memory Controller Scrubbing Error on Channel 0."
cpu1:33127)MCE: 222: cpu1: bank9: status=0xXXXXXXXXXXXXXXXX: (VAL=1, OVFLW=0, UC=0, EN=0, PCC=0, S=0, AR=0), ECC=no, Addr:0xXXXXXXXXXXXXXXXX (valid), Misc:0x8c3589300 (valid)

本版本已解决该问题。

最后实在找不到其它原因了,就定为BUG吧。升级到esxi 6.0 U3

看完上述内容,你们掌握如何进行VMware ESXi 宕机的分析的方法了吗?如果还想学到更多技能或想了解更多相关内容,欢迎关注创新互联行业资讯频道,感谢各位的阅读!


网页名称:如何进行VMwareESXi宕机的分析
路径分享:http://scgulin.cn/article/iphgjg.html