From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: kexec/kdump of a kvm guest? Date: Sun, 27 Jul 2008 11:32:41 +0300 Message-ID: <488C32A9.7010402@qumranet.com> References: <170fa0d20806261158me6f81d0p2ea4fa6b7e694a5a@mail.gmail.com> <486F58EC.6020408@qumranet.com> <170fa0d20807231713t19b5bd5bt5f418f509040b7aa@mail.gmail.com> <170fa0d20807240449n3e52c002qdb9c2626a192b0f1@mail.gmail.com> <20080724131552.GA22243@redhat.com> <170fa0d20807241203h7065b643k7df1187ef7e76f87@mail.gmail.com> <20080725011206.GC28627@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Snitzer , Alexander Graf , kexec@lists.infradead.org, kvm@vger.kernel.org, libvir-list@redhat.com To: Vivek Goyal Return-path: Received: from il.qumranet.com ([212.179.150.194]:14063 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751032AbYG0Icm (ORCPT ); Sun, 27 Jul 2008 04:32:42 -0400 In-Reply-To: <20080725011206.GC28627@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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