Re: [Qemu-devel] QMP: RFC: I/O error info & query-stop-reason

[Luiz Capitulino]

On Mon, 6 Jun 2011 16:27:55 +0100
"Daniel P. Berrange" <address@hidden> wrote:

> On Mon, Jun 06, 2011 at 08:08:51AM -0500, Anthony Liguori wrote:
> > On 06/06/2011 04:25 AM, Kevin Wolf wrote:
> > >Am 02.06.2011 20:09, schrieb Luiz Capitulino:
> > >>>>I'm ok with either way. But in case you meant the second one, I guess
> > >>>>we should make "reason" a dictionary so that we can group related
> > >>>>information when we extend the field, for example:
> > >>>>
> > >>>>   "reason": { "no space": false, "no permission": true }
> > >
> > >Splitting up enums into a number of booleans looks like a bad idea to
> > >me. It makes things more verbose than they should be, and even worse, it
> > >implies that more than one field could be true.
> > 
> > I agree.  What I had suggested was to not have a reason at all.
> > 
> > >
> > >If this new schema thing doesn't support proper enums, that's something
> > >that should be changed.
> > 
> > It does BTW.
> > 
> > >>>
> > >>>Why would we ever have "no permission"?
> > >>
> > >>It's an I/O error. I have a report from a developer who was getting
> > >>the BLOCK_IO_ERROR event and had to debug qemu to know the error cause,
> > >>it turned out to be no permission.
> > >
> > >And I want to add that it's a PITA to handle bug report when the only
> > >message you get from qemu is "something went wrong". Sorry, that's not
> > >useful at all. I want to see the real error reason (and at least for
> > >debugging this means, I want to see the errno value/string).
> > >
> > >Finding out that it was -EACCES in fact cost me (and QA who ran into the
> > >problem) much more time than it should have. It's simply too much that
> > >you need to attach gdb to find out what really happened.
> > 
> > You want a log file and you want libvirt to actually let QEMU write
> > to a log file.
> 
> Anything QEMU writes to stderr or stdout gets recorded in a
> per-VM logfile already at /var/log/libvirt/qemu/$GUESTNAME.log

I can submit a patch to write this info to stderr (in case we don't do that
yet).

> 
> Regards,
> Daniel