[Crash-utility] crash and libvirt, and more

[Bryn M. Reeves]

Dave Anderson wrote:
>> Item (ii) is the big deal for us.  Our current virt-* tools can work
>> with a wide range of kernels.
>>
>> What we do is to download the kernel-debuginfo packages beforehand,
>> extract only the tiny amount of debug info we actually need from
>> vmlinux, and build a 'kernel database'.  (We're using dwarves to get
>> the layout of the dozen or so structures that we care about).  It
>> turns out that it's quite easy to heuristically determine the version
>> of a running kernel, and from that we can look up the structures in
>> the kernel database at runtime.

We do a similar task for a project we have for automatically setting up
crash environments for a given vmcore file.

>> Upshot is that we support currently ~ 350 kernels with a database
>> which is a modest 1 MB in size, and probably could be made smaller
>> with very little effort.
>>
>> The problem I haven't yet resolved with using crash is that we need a
>> matching, identical vmlinux image (ie. 50-100 MB) per guest kernel
>> version.  In the case where we see a kernel version we've not seen
>> before, we may have to download this and store it somewhere.
>>
>> The alternative seems to involve some really deep hacking inside gdb,
>> perhaps so it can be persuaded to use only partial debug info?
>>
>> I don't know if you have any thoughts about (ii).

Sounds like another possible use for the "debuginfo-server" idea that
comes up periodically. There are a couple of things that could benefit
from a centralised way of managing a collection of kernel (or other
package) debug data.

It needn't be anything spectacularly clever - even a few scripts that
pull down debuginfo packages to an NFS exported file system and unpack
them in some predictable way would be a start.

Regards,
Bryn.