Fedora xen - Aug 2006 - Newbie question regarding Xen traps

I''m a newbie to Xen, so I apologise for this question which may be
buried
somewhere in a doc that I can''t seem to find.

 

Install and setup of Xen on my two athlon64 FC5 boxes went smoothly.
Unfortunately, Xen often cracks once a relatively heavy load is introduced
on one of the mysql servers that runs on the guests. Both machines are
equally unstable. If I remember correctly, the last one had mask_IO_APIC_irq
and mask_and_ack_level_ioapic_irq at the top of the stack.

 

My question is, how do I retain the trap output that is printed to the
console when the machine dies? I can''t seem to find it anywhere in
/var/log
and I''m not sure where else to look. I''d just like to retain
what is printed
to the console, like the traceback and registers so that I can see if the
stack is the same or similar each time on each system, or if I have multiple
problems. 

Thanks!
Alex

Alex Tomic wrote:
> My question is, how do I retain the trap output that is printed to the 
> console when the machine dies? 
Serial console.

The easiest thing is to buy two serial cables and have both
systems act as serial console server for the other, using
the excellent ttywatch program from Fedora Extras.

If one crashes, the other will log all the crash output.

Don''t forget to also configure the hypervisor for serial
console output.  Your grub.conf will look like this:

title Fedora Core (2.6.17-1.2488.fc6xen)
         root (hd0,0)
         kernel /xen.gz-2.6.17-1.2488.fc6 com1=38400,8n1
         module /vmlinuz-2.6.17-1.2488.fc6xen ro root=LABEL=/ 
console=ttyS0,38400 mem=2000M panic=180 debug 3
         module /initrd-2.6.17-1.2488.fc6xen.img


When you get a backtrace, please file a bugzilla and feel
free to add me to the CC: list.  I have a very strong
personal interest in fixing x86-64 Xen bugs, since I want
to get rid of a (noisy, warm) server at home and move that
workload into a virtual machine on my new desktop system :)

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan