On Thu, Dec 21, 2017 at 3:51 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > On Thu, Dec 21, 2017 at 11:22:48AM +0100, Sergio Lopez wrote: >> 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. I'm thinking of this not as something to be enabled by default for the whole environment, but as a feature that would be temporarily enabled for debugging a certain misbehaving VM. Would be a great companion for softlockup_panic. > 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. GDB would allow us to dump all memory mappings even for VMs running with dump-guest-core=off, but as this is something that already requires modifying the domain's definition, adding dumpCore=on too shouldn't be a problem. I like the on_crash=abort approach. I'm going to work on it. Thanks Daniel. -- Sergio -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
