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.
prev parent 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).