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@xxxxxxxxxx> 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.
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
