From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060911 Red Hat/1.5.0.7-0.1.el4 Firefox/1.5.0.7 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: Always 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/.
Correction: Option configured in /etc/xen/xend-config.sxp is: (enable-dump yes)
Does it work if you disable selinux enforcing? ("setenforce 0")
On both dom0 and domU: # getenforce Disabled
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?
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?
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) unpaused. [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) XendDomainInfo.destroyDomain(1) [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)?
"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.