All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@qumranet.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: libvir-list@redhat.com, kexec@lists.infradead.org,
	Mike Snitzer <snitzer@gmail.com>,
	kvm@vger.kernel.org, Alexander Graf <agraf@suse.de>
Subject: Re: kexec/kdump of a kvm guest?
Date: Sun, 27 Jul 2008 11:32:41 +0300	[thread overview]
Message-ID: <488C32A9.7010402@qumranet.com> (raw)
In-Reply-To: <20080725011206.GC28627@redhat.com>

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


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@qumranet.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Mike Snitzer <snitzer@gmail.com>, Alexander Graf <agraf@suse.de>,
	kexec@lists.infradead.org, kvm@vger.kernel.org,
	libvir-list@redhat.com
Subject: Re: kexec/kdump of a kvm guest?
Date: Sun, 27 Jul 2008 11:32:41 +0300	[thread overview]
Message-ID: <488C32A9.7010402@qumranet.com> (raw)
In-Reply-To: <20080725011206.GC28627@redhat.com>

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


  reply	other threads:[~2008-07-27  8:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-26 18:58 kexec/kdump of a kvm guest? Mike Snitzer
2008-07-05 11:20 ` Avi Kivity
2008-07-24  0:13   ` Mike Snitzer
2008-07-24  8:39     ` Alexander Graf
2008-07-24  8:39       ` Alexander Graf
2008-07-24 11:49       ` Mike Snitzer
2008-07-24 11:49         ` Mike Snitzer
2008-07-24 13:15         ` Vivek Goyal
2008-07-24 13:15           ` Vivek Goyal
2008-07-24 19:03           ` Mike Snitzer
2008-07-24 19:03             ` Mike Snitzer
2008-07-24 19:50             ` Anthony Liguori
2008-07-24 19:50               ` Anthony Liguori
2008-07-25  1:12             ` Vivek Goyal
2008-07-25  1:12               ` Vivek Goyal
2008-07-27  8:32               ` Avi Kivity [this message]
2008-07-27  8:32                 ` Avi Kivity
2008-08-25 15:56               ` Mike Snitzer
2008-08-25 15:56                 ` Mike Snitzer
2008-08-25 16:05                 ` Vivek Goyal
2008-08-25 16:05                   ` Vivek Goyal
2008-07-27  9:12             ` Avi Kivity
2008-07-27  9:12               ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=488C32A9.7010402@qumranet.com \
    --to=avi@qumranet.com \
    --cc=agraf@suse.de \
    --cc=kexec@lists.infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=libvir-list@redhat.com \
    --cc=snitzer@gmail.com \
    --cc=vgoyal@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.