On Thu, Dec 21, 2017 at 11:22:48AM +0100, Sergio Lopez wrote:
Hi,
Right now, the actions coredump-[destroy|restart] for on_crash work in
a similar way as "virsh dump", requesting a dump of Guest's memory
contents to QEMU.
I think it'd be nice to have the ability for executing gdb/gcore to
produce a full core dump of QEMU. This would be especially useful for
debugging hard/soft lockups on the Guest.
Of course, this should be implemented in a completely optional way,
checking if the gdb binary is present, to avoid creating a direct
dependency between libvirt and gdb.
I'm willing to work on a patch implementing this feature myself, but
first I'd like to know if this sounds good to you. Also, if it does,
do you think the behavior of coredump-[destroy|restart] should be
changed to use gdb if available, falling back to qemuDomainCoreDump if
it isn't, or just implement another action for on_crash?
I really don't like the idea of running GDB automatically in response to
anything that can be triggered by the guest. GDB is not robust wrt
parsing cores, so a suitably corrupted memory image of QEMU could be
used to abuse GDB. Further, few production deployments of libvirt & QEMU
will ever have GDB installed. Many organizations outright forbid install
of such tools on production machines.
A much simpler way is to just have an "abort" action, which would cause
libvirt to send SIG_ABRT to QEMU. This should cause QEMU's default
SIG_ABRT handler to kick in which will make the kernel trigger a coredump.
If really wanted, you can then use abrt to catch this coredump.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|