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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org