All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wen Congyang <wency@cn.fujitsu.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: [PATCH] kvm: notify host when guest paniced
Date: Wed, 29 Feb 2012 18:31:24 +0800	[thread overview]
Message-ID: <4F4DFE7C.3030501@cn.fujitsu.com> (raw)
In-Reply-To: <4F4DF86C.5010407@redhat.com>

At 02/29/2012 06:05 PM, 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

Yes, guest-internal dump is better than host dump. But the user may not
start guest-internal dump or guest-internal dump failed. So we need the
following feature:
1. If the guest-internal dump does not work, the guest's status is 'crashed'.
   And then the user does the host dump.
2. If the guest-internal dump is working, the guest's status should be
   'dumping'. The user see this status and know the guest has paniced, and
    the guest-internal dump is working.

Thanks
Wen Congyang

> 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.
> 

WARNING: multiple messages have this Message-ID (diff)
From: Wen Congyang <wency@cn.fujitsu.com>
To: Avi Kivity <avi@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.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 18:31:24 +0800	[thread overview]
Message-ID: <4F4DFE7C.3030501@cn.fujitsu.com> (raw)
In-Reply-To: <4F4DF86C.5010407@redhat.com>

At 02/29/2012 06:05 PM, 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

Yes, guest-internal dump is better than host dump. But the user may not
start guest-internal dump or guest-internal dump failed. So we need the
following feature:
1. If the guest-internal dump does not work, the guest's status is 'crashed'.
   And then the user does the host dump.
2. If the guest-internal dump is working, the guest's status should be
   'dumping'. The user see this status and know the guest has paniced, and
    the guest-internal dump is working.

Thanks
Wen Congyang

> 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.
> 


WARNING: multiple messages have this Message-ID (diff)
From: Wen Congyang <wency@cn.fujitsu.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 18:31:24 +0800	[thread overview]
Message-ID: <4F4DFE7C.3030501@cn.fujitsu.com> (raw)
In-Reply-To: <4F4DF86C.5010407@redhat.com>

At 02/29/2012 06:05 PM, 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

Yes, guest-internal dump is better than host dump. But the user may not
start guest-internal dump or guest-internal dump failed. So we need the
following feature:
1. If the guest-internal dump does not work, the guest's status is 'crashed'.
   And then the user does the host dump.
2. If the guest-internal dump is working, the guest's status should be
   'dumping'. The user see this status and know the guest has paniced, and
    the guest-internal dump is working.

Thanks
Wen Congyang

> 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.
> 

  parent reply	other threads:[~2012-02-29 10:31 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
2012-02-29 10:19             ` [Qemu-devel] " 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 [this message]
2012-02-29 10:31             ` 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=4F4DFE7C.3030501@cn.fujitsu.com \
    --to=wency@cn.fujitsu.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 \
    /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.