- Channel HP
- :
- Enterprise Business Blogs
- :
- Services
- :
- Technical Support Services Blog | HP Technology Services
- :
- Converting a vmkernel-zdump to Text and Making Sen...
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Email to a Friend
- Printer Friendly Page
- Report Inappropriate Content
Converting a vmkernel-zdump to Text and Making Sense of it
Well I’m back from a wonderful trip to Korea with my wife to visit my daughter and her husband who are teaching English in a small town called Haenam at southern tip of the Korean peninsula. When the local High School, where my son in law teaches found out I work for HP, I even enjoyed an opportunity to speak to his High School class on career opportunities in the IT industry.
Anyway, as promised in my last blog entry Examining the logs from a vm-support diagnostic here is some information on what you can do if your ESX/ESXi host has crashed with what is called a Purple Screen Of Death or PSOD for short.
One of the pieces of information captured by the vCenter host (vm-support) diagnostic is a copy of the binary dump file when the host has crashed. This will be located in the “root” directory once you have unpacked the diagnostic. See my earlier post Unpacking and Making Sense of a VMware vm-support Diagnostic Bundle for information on unpacking the diagnostic bundle.
If your vm-support contains a dump, it will have an unreadable binary file with a name in the format of vmkernel-zdump-<timestamp>. For example: vmkernel-zdump-052111.03.12.1
On ESX 4 and above you can convert this file to readable text using the command esxcfg-dumppart –L. The file produced will be named vmkernel-log.1 by default.
Example:
# esxcfg-dumppart -L vmkernel-zdump-052111.03.12.1
Created file vmkernel-log.1
Log wrapped
#
The resulting vmkernel-log can be quite lengthy, thousands of lines in some cases, because it contains all recent VMkernel log messages leading up to the PSOD. The actual crash trace-back will always be at the end of this document.
Example:
36:17:19:45.957 cpu7:4200)ALERT: IDT: 590: VMK DF handler: ip=0x41802e463165 sp=41802e8e75b7^[[0m
36:17:19:45.957 cpu7:4200)ALERT: Bluescreen: 375: PSOD level 1: #DF Exception(8) in world 4200:helper20-13 @ 0x41802e463165
LBR: from 0x41802e463160 to 0x41802e463164
ra=0x41802e422c6e^[[0m
VMware ESX [Releasebuild-208167 X86_64]
#PF Exception(14) in world 4100:idle4 ip 0xff addr 0xff
LBR: from 0x41802e7bbf90 to 0xff
cr2=0xff cr3=0xcfe27000 cr4=0x16c
frame=0x4100c00275d8 ip=0xff err=16 rflags=0x10002
rax=0x4100c03479d0 rbx=0x4100c0347a10 rcx=0x0
rdx=0x0 rbp=0x4100c00276c8 rsi=0x3
rdi=0x4100c03479b8 r8=0x0 r9=0x1a4d23a7c00000
r10=0xbadc0ded r11=0xbadc0ded r12=0xc0347b00
r13=0x1 r14=0x4100c0347990 r15=0x0
0:4096/console 1:4515/vmm1:CDSV 2:4940/vmm1:CDSV 3:4388/vmm0:CDSV
*4:4100/idle4 5:4995/vmm0:CDSV 6:4939/vmm0:CDSV 7:4200/helper20-
@BlueScreen: #PF Exception(14) in world 4100:idle4 ip 0xff addr 0xff
LBR: from 0x41802e7bbf90 to 0xff
Code starts at 0x41802e400000
0x4100c00276c8:[0xff]Unknown stack: 0x417fef2343f0
0x4100c0027718:[0x41802e7bc12e]__wake_up+0x6d stack: 0x1
0x4100c0027758:[0x41802e8e75af]lpfc_sli_wake_iocb_
0x4100c0027978:[0x41802e8e29c9]lpfc_sli_handle_fas
0x4100c0027a08:[0x41802e8e7b76]lpfc_intr_handler+0
0x4100c0027a48:[0x41802e7b8208]Linux_IRQHandler+0x
0x4100c0027ab8:[0x41802e42e0e5]IDTDoInterrupt+0x31
0x4100c0027ae8:[0x41802e42e484]IDT_HandleInterrupt
0x4100c0027b08:[0x41802e42e9f2]IDT_IntrHandler+0x9
0x4100c0027c18:[0x41802e4a9b16]gate_entry+0x25 stack: 0x4100c0027d00
0x4100c0027c48:[0x41802e42e524]IDT_HandleInterrupt
0x4100c0027c68:[0x41802e42e9f2]IDT_IntrHandler+0x9
0x4100c0027d48:[0x41802e4a9b16]gate_entry+0x25 stack: 0x410006409040
0x4100c0027e58:[0x41802e5a09ce]CpuSchedIdleLoopInt
0x4100c0027e68:[0x41802e5a2847]CpuSched_IdleLoop+0
0x4100c0027e88:[0x41802e431753]Init_SlaveIdle+0x9e stack: 0x0
0x4100c0027fe8:[0x41802e646a56]SMPSlaveIdle+0x3d1 stack: 0x0
VMK uptime: 36:17:19:45.964 TSC: 7403164751824695
FSbase (0x0) GSbase (0x0) kernelGSbase (0x0)
36:17:19:45.957 cpu7:4200)IDT: 590: VMK DF handler: ip=0x41802e463165 sp=41802e8e75b7
36:17:19:45.957 cpu7:4200)Bluescreen: 375: PSOD level 1: #DF Exception(8) in world 4200:helper20-13 @ 0x41802e463165
LBR: from 0x41802e463160 to 0x41802e463164
Starting coredump to disk.
This will reflect the same information that appears on the screen during the crash, but viewing it in this format has several benefits.
1. You’ll have the complete trace-back in case some of it scrolled off your console display.
2. It contains additional messages leading to the panic.
3. Rather than just taking an image of the console it’s in a much more portable text format, from which you can cut and paste for searches etc.
Most VMware ESX PSODs tend to be hardware related. In some cases you may be able to identify the source of the problem without even needing to elevate to VMware. In the above example even without VMware sources we can already tell that the problem was related to the Emulex Light Pulse Fibre Channel HBA so something was going on with the Storage Network.
For additional information:
Here is an excellent KB article from VMware on interpreting a PSOD:
http://kb.vmware.com/kb/1004250
And another KB article showing the basics of how to extract information from a dump:
http://kb.vmware.com/kb/1006796
- Mark as Read
- Mark as New
- Bookmark
- Highlight
- Email to a Friend
- Report Inappropriate Content
Thanks a lot for your great posting,I love this post very much,please keep sharing of knowledges with us.
- Mark as Read
- Mark as New
- Bookmark
- Highlight
- Email to a Friend
- Report Inappropriate Content
Thanks for sharing this it related information. I didn't know it.....





