Vivek Goyal wrote:
Seems that libvirt functionality isn't available yet with kvm (I'm
using libvirt 0.4.2, I'll give libvirt 0.4.4 a try). cc'ing the
libvirt-list to get their insight.
That aside, having the crash dump collection be multi-phased really
isn't workable (that is if it requires a crashed guest to be manually
saved after the fact). The host system _could_ be rebooted; whereby
losing the guest's core image. So automating qemu and/or libvirtd to
trigger a dump would seem worthwhile (maybe its already done?).
That's a good point. Ideally, one would like dump to be captured
automatically if kernel crashes and then reboot back to production
kernel. I am not sure what can we do to let qemu know after crash
so that it can automatically save dump.
We can expose a virtual pci device that when accessed, causes qemu to
dump the guest's core.
Ok. So first task is to fix host kexec/kdump with kvm-intel module
inserted.
Can you do little debugging to find out where system hangs. I generally
try few things for kexec related issue debugging.
1. Specify earlyprintk= parameter for second kernel and see if control
is reaching to second kernel.
2. Otherwise specify --console-serial parameter on "kexec -l" commandline
and it should display a message "I am in purgatory" on serial console.
This will just mean that control has reached at least till purgatory.
3. If that also does not work, then most likely first kernel itself got
stuck somewhere and we need to put some printks in first kernel to find
out what's wrong.
kvm has a reboot notifier to turn off vmx when rebooting. See
kvm_reboot_notifier and kvm_reboot(). Maybe something similar is needed
for kexec?
--
error compiling committee.c: too many arguments to function
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list