kexec/kdump of a kvm guest?

Avi Kivity avi at
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
> 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

More information about the kexec mailing list