Re: [Crash-utility] crash and libvirt, and more
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.