Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 216498 - Xen crash dumps not captured
Xen crash dumps not captured
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Xen Maintainance List
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-11-20 14:51 EST by Ivan Makfinsky
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-21 11:00:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ivan Makfinsky 2006-11-20 14:51:06 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060911 Red Hat/ Firefox/ pango-text

Description of problem:
Xen domU crash dumps are not being captured even though Xen is configured to do so.

Version-Release number of selected component (if applicable):
RHEL5 Beta2

How reproducible:

Steps to Reproduce:
1. Boot Xen kernel 2747
2. Install guest - in this case RHEL5b2
3. turn on dumps in /etc/xen/xend-config.sxp:
(enable-dumps yes)
4. Restart xend
5. Login to guest, trigger crash:
# echo "c" > /proc/sysrq-trigger

Actual Results:
Guest rebooted, however, nothing was produced in /var/xen/dump/.

Expected Results:
Guest dumpfile would be present in /var/xen/dump/

Additional info:
kernel.sysrq was set to 0 on the first attempt in guest. Sysrq triggers seemed to work regardless of this option. Changed to "1", still no dump file in /var/xen/dump/.
Comment 1 Ivan Makfinsky 2006-11-20 14:55:33 EST

Option configured in /etc/xen/xend-config.sxp is:

(enable-dump yes)
Comment 2 Stephen Tweedie 2006-11-20 17:40:13 EST
Does it work if you disable selinux enforcing?  ("setenforce 0")
Comment 3 Ivan Makfinsky 2006-11-20 17:47:23 EST
On both dom0 and domU:

# getenforce
Comment 4 Stephen Tweedie 2006-11-20 18:03:40 EST
Running 2.6.18-1.2747.el5xen, with (enable-dump yes), I just had no trouble
getting a dump file:

# ls -l /var/xen/dump/
total 513412
-rw------- 1 root root 525209600 Nov 20 22:38 2006-1120-2238.43-rhel5U64.3.core

Is there anything relating to dumping in /var/log/xen/xend.log?
Comment 5 Ivan Makfinsky 2006-11-20 18:14:54 EST
No, there is nothing in the logs about dumps or cores. I can get cores from the
guests by using # xm dump-core <dom> and that places cores into /var/xen/dump.

What should the log messages look like for enabling core dumps in
/etc/xen/xend-config.sxp and what should I be seeing when a core is produced?
Comment 6 Ivan Makfinsky 2006-11-20 18:43:24 EST
Upon closer inspection I did find this in the logs:

[2006-11-20 18:29:11 xend 2496] DEBUG (DevController:143) Waiting for devices vtpm.
[2006-11-20 18:29:11 xend 2496] INFO (XendDomain:370) Domain rhel5b2-32 (1)
[2006-11-20 18:33:47 xend.XendDomainInfo 2496] INFO (XendDomainInfo:892) Domain
has shutdown: name=rhel5b2-32 id=1 reason=reboot.
[2006-11-20 18:33:47 xend.XendDomainInfo 2496] DEBUG (XendDomainInfo:1457)
[2006-11-20 18:33:47 xend 2496] DEBUG (image:517) hvm shutdown watch unregistered
[2006-11-20 18:33:47 xend.XendDomainInfo 2496] DEBUG (XendDomainInfo:190)
XendDomainInfo.create(['domain', ['domid', 1], ['uuid',
'51f837f6-b270-64b6-921d-9c3ed1913dfb'], ['vcpus', 1], ['vcpu_avail', 1],
['cpu_weight', 1.0], ['memory', 500], ['shadow_memory', 3], ['maxmem', 500],
['features', ''], ['name', 'rhel5b2-32'], ['on_poweroff', 'destroy'],
['on_reboot', 'restart'], ['on_crash', 'restart'], ['image', ['hvm', ['kernel',
'/usr/lib/xen/boot/hvmloader'], ['device_model', '/usr/lib/xen/bin/qemu-dm'],
['pae', 1], ['vcpus', 1], ['boot', 'c'], ['serial', 'pty'], ['acpi', 1],
['apic', 1], ['vnc', 1], ['vncunused', 1], ['display', ':0.0'], ['xauthority',
'/tmp/.gdmOBA9IT']]], ['device', ['vif', ['backend', 0], ['script', 'vif-bridge'],
['bridge', 'xenbr0'], ['mac', '00:16:3e:47:de:ad'], ['type', 'ioemu']]],
['device', ['vbd', ['backend', 0], ['dev', 'hda:disk'], ['uname',
'file:/xen/images/rhel5b2-32.img'], ['mode', 'w']]], ['state', '--ps--'],
['shutdown_reason', 'reboot'], ['cpu_time', 65.095287182000007],
['online_vcpus', 1], ['up_time', '276.433331966'], ['start_time',
'1164065350.61'], ['store_mfn', 134625]])

What config/clues should I be looking for in order to get this to work the way I
hope it does (ie. produce a core)?
Comment 7 Stephen Tweedie 2006-11-21 11:00:04 EST
"hvmloader"... "qemu-dm"... it's fully virt!

There's nothing in the standard PC architecture that lets an OS tell the
platform "I crashed, dump me now".  The bare-metal kernel just reboots on panic
if it can.  So FV isn't expected to dump core, as it does not attempt any crash
handshake with  the host.

This would be worth documenting, I expect.

Note You need to log in before you can comment on or make changes to this bug.