All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>,
	kvm list <kvm@vger.kernel.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	linux-kernel@vger.kernel.org, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [PATCH] kvm: notify host when guest paniced
Date: Wed, 29 Feb 2012 10:19:13 +0000	[thread overview]
Message-ID: <20120229101913.GG5050@redhat.com> (raw)
In-Reply-To: <4F4DF86C.5010407@redhat.com>

On Wed, Feb 29, 2012 at 12:05:32PM +0200, Avi Kivity wrote:
> On 02/29/2012 11:58 AM, Daniel P. Berrange wrote:
> > > 
> > > How about using a virtio-serial channel for this?  You can transfer any
> > > amount of information (including the dump itself).
> >
> > When the guest OS has crashed, any dumps will be done from the host
> > OS using libvirt's core dump mechanism. The guest OS isn't involved
> > and is likely too dead to be of any use anyway. Likewise it is
> > quite probably too dead to work a virtio-serial channel or any
> > similarly complex device. We're really just after the simplest
> > possible notification that the guest kernel has paniced.
> 
> If it's alive enough to panic, it's alive enough to kexec its kdump
> kernel.  After that it can do anything.
> 
> Guest-internal dumps are more useful IMO that host-initiated dumps.  In
> a cloud, the host-initiated dump is left on the host, outside the reach
> of the guest admin, outside the guest image where all the symbols are,
> and sometimes not even on the same host if a live migration occurred. 
> It's more useful in small setups, or if the problem is in the
> hypervisor, not the guest.

I don't think guest vs host dumps should be considered mutually exclusive,
they both have pluses+minuses.

Configuring kexec+kdump requires non-negligable guest admin configuration
work before it's usable, and this work is guest OS specific, if it is possible
at all. A permanent panic notifier that's built in the kernel by default
requires zero guest admin config, and can allow host admin to automate
collection of dumps across all their hosts/guests. The KVM hypercall
notification is fairly trivially ported to any OS kernel, by comparison
with a full virtio + virtio-serial impl.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

WARNING: multiple messages have this Message-ID (diff)
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	kvm list <kvm@vger.kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH] kvm: notify host when guest paniced
Date: Wed, 29 Feb 2012 10:19:13 +0000	[thread overview]
Message-ID: <20120229101913.GG5050@redhat.com> (raw)
In-Reply-To: <4F4DF86C.5010407@redhat.com>

On Wed, Feb 29, 2012 at 12:05:32PM +0200, Avi Kivity wrote:
> On 02/29/2012 11:58 AM, Daniel P. Berrange wrote:
> > > 
> > > How about using a virtio-serial channel for this?  You can transfer any
> > > amount of information (including the dump itself).
> >
> > When the guest OS has crashed, any dumps will be done from the host
> > OS using libvirt's core dump mechanism. The guest OS isn't involved
> > and is likely too dead to be of any use anyway. Likewise it is
> > quite probably too dead to work a virtio-serial channel or any
> > similarly complex device. We're really just after the simplest
> > possible notification that the guest kernel has paniced.
> 
> If it's alive enough to panic, it's alive enough to kexec its kdump
> kernel.  After that it can do anything.
> 
> Guest-internal dumps are more useful IMO that host-initiated dumps.  In
> a cloud, the host-initiated dump is left on the host, outside the reach
> of the guest admin, outside the guest image where all the symbols are,
> and sometimes not even on the same host if a live migration occurred. 
> It's more useful in small setups, or if the problem is in the
> hypervisor, not the guest.

I don't think guest vs host dumps should be considered mutually exclusive,
they both have pluses+minuses.

Configuring kexec+kdump requires non-negligable guest admin configuration
work before it's usable, and this work is guest OS specific, if it is possible
at all. A permanent panic notifier that's built in the kernel by default
requires zero guest admin config, and can allow host admin to automate
collection of dumps across all their hosts/guests. The KVM hypercall
notification is fairly trivially ported to any OS kernel, by comparison
with a full virtio + virtio-serial impl.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

  reply	other threads:[~2012-02-29 10:19 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-27  3:01 [PATCH] kvm: notify host when guest paniced Wen Congyang
2012-02-27  3:01 ` [Qemu-devel] " Wen Congyang
2012-02-27  3:05 ` [PATCH]qemu: deal with guest paniced event Wen Congyang
2012-02-27  3:05   ` [Qemu-devel] " Wen Congyang
2012-02-27  8:59   ` Jan Kiszka
2012-02-27  8:59     ` [Qemu-devel] " Jan Kiszka
2012-02-27  8:59     ` Jan Kiszka
2012-03-01 16:51   ` [Qemu-devel] " Luiz Capitulino
2012-03-01 16:51     ` Luiz Capitulino
2012-03-02  0:40     ` Wen Congyang
2012-03-02  0:40       ` Wen Congyang
2012-02-27 15:08 ` [PATCH] kvm: notify host when guest paniced Jan Kiszka
2012-02-27 15:08   ` [Qemu-devel] " Jan Kiszka
2012-02-28  5:26   ` Wen Congyang
2012-02-28  5:26     ` [Qemu-devel] " Wen Congyang
2012-02-28  5:26     ` Wen Congyang
2012-02-28  8:07     ` Wen Congyang
2012-02-28  8:07       ` [Qemu-devel] " Wen Congyang
2012-02-28  8:23   ` Wen Congyang
2012-02-28  8:23     ` [Qemu-devel] " Wen Congyang
2012-02-28  9:34     ` Jan Kiszka
2012-02-28  9:34       ` [Qemu-devel] " Jan Kiszka
2012-02-28  9:34       ` Jan Kiszka
2012-02-28  9:42       ` Wen Congyang
2012-02-28  9:42         ` [Qemu-devel] " Wen Congyang
2012-02-28 10:19         ` Jan Kiszka
2012-02-28 10:19           ` [Qemu-devel] " Jan Kiszka
2012-02-28 10:45           ` Gleb Natapov
2012-02-28 10:45             ` [Qemu-devel] " Gleb Natapov
2012-02-29  1:08             ` Wen Congyang
2012-02-29  1:08               ` [Qemu-devel] " Wen Congyang
2012-02-29  9:36               ` Gleb Natapov
2012-02-29  9:36                 ` [Qemu-devel] " Gleb Natapov
2012-02-29 10:06                 ` Wen Congyang
2012-02-29 10:06                   ` [Qemu-devel] " Wen Congyang
2012-02-28 11:23 ` Avi Kivity
2012-02-28 11:23   ` [Qemu-devel] " Avi Kivity
2012-02-29  1:29   ` Wen Congyang
2012-02-29  1:29     ` [Qemu-devel] " Wen Congyang
2012-02-29  1:29     ` Wen Congyang
2012-02-29  9:49     ` Avi Kivity
2012-02-29  9:49       ` [Qemu-devel] " Avi Kivity
2012-02-29  9:55       ` Gleb Natapov
2012-02-29  9:55         ` [Qemu-devel] " Gleb Natapov
2012-02-29 10:00         ` Avi Kivity
2012-02-29 10:00           ` [Qemu-devel] " Avi Kivity
2012-02-29 10:00           ` Avi Kivity
2012-02-29 10:05           ` Gleb Natapov
2012-02-29 10:05             ` [Qemu-devel] " Gleb Natapov
2012-02-29 10:08             ` Avi Kivity
2012-02-29 10:08               ` [Qemu-devel] " Avi Kivity
2012-02-29 10:17               ` Wen Congyang
2012-02-29 10:17                 ` [Qemu-devel] " Wen Congyang
2012-02-29 10:39                 ` Avi Kivity
2012-02-29 10:39                   ` [Qemu-devel] " Avi Kivity
2012-03-01  3:34                   ` Wen Congyang
2012-03-01  3:34                     ` [Qemu-devel] " Wen Congyang
2012-03-01  3:34                     ` Wen Congyang
2012-03-01  5:21                   ` Wen Congyang
2012-03-01  5:21                     ` [Qemu-devel] " Wen Congyang
2012-02-29 10:44               ` Gleb Natapov
2012-02-29 10:44                 ` [Qemu-devel] " Gleb Natapov
2012-02-29 10:48                 ` Avi Kivity
2012-02-29 10:48                   ` [Qemu-devel] " Avi Kivity
2012-02-29 10:52                   ` Gleb Natapov
2012-02-29 10:52                     ` [Qemu-devel] " Gleb Natapov
2012-02-29  9:58       ` Daniel P. Berrange
2012-02-29  9:58         ` [Qemu-devel] " Daniel P. Berrange
2012-02-29 10:05         ` Avi Kivity
2012-02-29 10:05           ` [Qemu-devel] " Avi Kivity
2012-02-29 10:19           ` Daniel P. Berrange [this message]
2012-02-29 10:19             ` Daniel P. Berrange
2012-02-29 10:44             ` Avi Kivity
2012-02-29 10:44               ` [Qemu-devel] " Avi Kivity
2012-02-29 10:31           ` Wen Congyang
2012-02-29 10:31             ` [Qemu-devel] " Wen Congyang
2012-02-29 10:31             ` Wen Congyang
2012-02-29 10:46             ` Avi Kivity
2012-02-29 10:46               ` [Qemu-devel] " Avi Kivity
2012-02-29 10:46               ` 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=20120229101913.GG5050@redhat.com \
    --to=berrange@redhat.com \
    --cc=avi@redhat.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=wency@cn.fujitsu.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.