From: "Daniel P. Berrange" <berrange@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: armbru@redhat.com, qemu-devel@nongnu.org,
Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] Re: Two QMP events issues
Date: Mon, 8 Feb 2010 14:56:53 +0000 [thread overview]
Message-ID: <20100208145653.GA25256@redhat.com> (raw)
In-Reply-To: <4B702470.5080401@codemonkey.ws>
On Mon, Feb 08, 2010 at 08:49:20AM -0600, Anthony Liguori wrote:
> On 02/08/2010 08:12 AM, Daniel P. Berrange wrote:
> >
> >For further backgrou, the key end goal here is that in a QMP client, upon
> >receipt of the 'RESET' event, we need to reliably& immediately determine
> >why it occurred. eg, triggered by watchdog, or by guest OS request. There
> >are actually 3 possible sequences
> >
> > - WATCHDOG + action=reset, followed by RESET. Assuming no intervening
> > event can occurr, the client can merely record 'WATCHDOG' and interpret
> > it when it gets the immediately following 'RESET' event
> >
> > - RESET, followed by WATCHDOG + action=reset. The client doesn't know
> > the reason for the RESET and can't wait arbitrarily for WATCHDOG since
> > there might never be one arriving.
> >
> > - RESET + source=watchdog. Client directly sees the reason
> >
> >The second scenario is the one I'd like us to avoid at all costs, since it
> >will require the client to introduce arbitrary delays in processing events
> >to determine cause. The first is slightly inconvenient, but doable if we
> >can assume no intervening events will occur, between WATCHDOG and the
> >RESET events. The last is obviously simplest for the clients.
> >
>
> I really prefer the third option but I'm a little concerned that we're
> throwing events around somewhat haphazardly.
>
> So let me ask, why does a client need to determine when a guest reset
> and why it reset?
If a guest OS is repeatedly hanging/crashing resulting in the watchdog
device firing, management software for the host really wants to know about
that (so that appropriate alerts/action can be taken) and thus needs to
be able to distinguish this from a "normal" guest OS initiated reboot.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
next prev parent reply other threads:[~2010-02-08 14:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-08 13:41 [Qemu-devel] Two QMP events issues Luiz Capitulino
2010-02-08 14:12 ` [Qemu-devel] " Daniel P. Berrange
2010-02-08 14:49 ` Anthony Liguori
2010-02-08 14:56 ` Daniel P. Berrange [this message]
2010-02-08 15:13 ` Anthony Liguori
2010-02-08 18:25 ` Luiz Capitulino
2010-02-08 19:14 ` Anthony Liguori
2010-02-08 19:59 ` Luiz Capitulino
2010-02-08 20:22 ` Anthony Liguori
2010-02-08 18:19 ` Luiz Capitulino
2010-02-09 19:24 ` Jamie Lokier
2010-02-09 19:32 ` Jamie Lokier
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=20100208145653.GA25256@redhat.com \
--to=berrange@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=armbru@redhat.com \
--cc=lcapitulino@redhat.com \
--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.