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
