kexec/kdump of a kvm guest?
avi at qumranet.com
Sun Jul 27 04:32:41 EDT 2008
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
> 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
error compiling committee.c: too many arguments to function
More information about the kexec