[libvirt] [PATCH 3/3] Debug: Report VM errors more concisely.

[Prerna]

Oops, sorry. Dropping the list was not intentional.  I didnt realise I had
sent a "reply" in place of "reply-all" .
Adding back :)

I still would argue that having the VM's name narrows down the problem
space. If a client knows what operations have been fired for a VM over the
last time window, it is not too difficult to deduce which of them could
have caused this message to occur.

As I said before, use of libvirt Debug logs adds way too much logspew. If
we have more pointed error/warning messages, it can largely help debugging
on its own.

Even if we turn debugging on, libvirt honestly has way too many messages
that look like an en-masse CTRL-C/V operation. Sample:
 All qemuMonitorEmit* except one have this message:

VIR_DEBUG("mon=%p", mon);

Even if this message shows up in logs, it is near impossible to trace which
event was seen by the VM. And it is quite another task to see which VM this
monitor belonged to.


Not that more vebosity wont help here.

However, I am only trying to make logs easier to work with. Every message
should ideally contribute to something meaningful, else it has little value
to add while debugging.

On Wed, Mar 22, 2017 at 1:59 PM, Peter Krempa <pkrempa at redhat.com> wrote:

> [Please don't drop the list on the responses.]
>
> On Wed, Mar 22, 2017 at 13:52:14 +0530, Prerna wrote:
> > Always enabling debug logs adds a *lot* of logspew.
> > It would be good to have self-sufficient error messages, dont you think ?
> > What is wrong with adding a VM name field here ?
>
> It's mostly useless. You get the VM name, but you don't have the
> operation that failed. So it's useless for debugging.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170322/296e1f10/attachment-0001.htm>