qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: fromani@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH] block: extend BLOCK_IO_ERROR event with nospace indicator
Date: Tue, 9 Sep 2014 09:42:59 -0400	[thread overview]
Message-ID: <20140909094259.156f0e51@redhat.com> (raw)
In-Reply-To: <20140909132350.GJ4847@noname.str.redhat.com>

On Tue, 9 Sep 2014 15:23:50 +0200
Kevin Wolf <kwolf@redhat.com> wrote:

> Am 09.09.2014 um 14:53 hat Eric Blake geschrieben:
> > On 09/09/2014 06:43 AM, Luiz Capitulino wrote:
> > 
> > >> Enhancing query-block in addition to the event makes sense, if it is
> > >> easy enough to do.  At this point, we are talking about debugging aids,
> > >> so as long as they are documented appropriately, I won't be too fussy.
> > > 
> > > OK, but I'm wondering if we need to add the string field to both,
> > > BLOCK_IO_ERROR and query-block, or only to one to the other.
> > > 
> > > In my opinion, we should only add it to BLOCK_IO_ERROR if libvirt is
> > > going to consume. Otherwise, it makes more sense to add it to query-block
> > > because that's where we'll meet the user.
> > > 
> > > Btw, by "consume" I mean read it and make it available to libvirt clients
> > > so that they can print it to their users. If we don't want libvirt to
> > > consume that field then I think we should only add it to query-block and
> > > info block.
> > 
> > [For those not aware, qemu built for downstream RHEL already has an
> > error string in the __com.redhat_ namespace; we're trying to figure out
> > what upstream should have so that downstream doesn't have to perpetually
> > maintain an extension]
> > 
> > Downstream libvirt does not currently consume any error string.  With
> > downstream qemu, the _only_ way to get the error string in the event is
> > to parse libvirt logs, or use upstream libvirt with its backdoor of
> > 'virsh qemu-monitor-event' (through the explicitly unsupported
> > libvirt-qemu.so) to get at the raw event information.  Changing libvirt
> > to expose such an error string to the end user would require a new
> > libvirt event number (the existing libvirt event is not extensible), so
> > existing clients would not be able to get at the information without
> > being recompiled to a new libvirt.
> > 
> > Since the whole point of this field is for debugging, I think that it is
> > sufficient to add it to JUST query-block, and not to the event.  That
> > is, if the app on top of libvirt gets an error, in the common case, they
> > won't care about the message (it won't change how they act), and in the
> > debug case, a developer trying to learn more about what happened can do
> > their own query-block directly (via 'virsh qemu-monitor-command', also
> > in libvirt-qemu.so) rather than trying to wire up libvirt to pass
> > through an error string through a new event.
> 
> You mention libvirt logs and I think that's an important point: If we
> move it to query-block, will we still get a log entry so that we can
> check this after the fact when only a log file is attached to a bug
> report, but we don't have a running guest?

Good point. I think this is call to have it in the event or both.

      reply	other threads:[~2014-09-09 13:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-29 20:07 [Qemu-devel] [PATCH] block: extend BLOCK_IO_ERROR event with nospace indicator Luiz Capitulino
2014-08-29 20:33 ` Eric Blake
2014-09-08 14:42 ` Luiz Capitulino
2014-09-08 15:33   ` Kevin Wolf
2014-09-08 16:57     ` Luiz Capitulino
2014-09-09  8:27       ` Kevin Wolf
2014-09-09 12:37         ` Eric Blake
2014-09-09 12:43           ` Luiz Capitulino
2014-09-09 12:53             ` Eric Blake
2014-09-09 13:23               ` Kevin Wolf
2014-09-09 13:42                 ` Luiz Capitulino [this message]

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=20140909094259.156f0e51@redhat.com \
    --to=lcapitulino@redhat.com \
    --cc=armbru@redhat.com \
    --cc=fromani@redhat.com \
    --cc=kwolf@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).