[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Reporting log/error messages through capabilities



On 19.02.2014 00:11, Richard W.M. Jones wrote:
When qemu is completely broken, libvirtd starts up OK but exists in a
kind of broken state where no guests can possibly be run.  I hit this
problem ... again ... today:

https://bugzilla.redhat.com/show_bug.cgi?id=1066630#c0

There is a libvirt bug here, which is that it's very hard to diagnose
what is going on when qemu fails to work at all.  The logging system
in libvirt(d) is trememdously powerful, but ultimately confusing to
use, and requires users to edit config files which makes it a
non-starter for programs using libvirt through the API [1].

From a libguestfs point of view, it's impossible for us to report back
to the user that there is a problem two layers below in qemu.

So my idea is that libvirt capabilities output should have an <info>
section containing log messages/errors.

   <capabilities>
     ...
     <info>
         Could not run qemu-system-blah:
         "symbol lookup error: /usr/bin/qemu-system-s390x: undefined symbol: glfs_discard_async"
     </info>
   </capabilities>

This makes sense, although we should make it more versatile to distinguish different qemu targets. For example -s390x can be missing a symbol, while -x86_64 can be missing a shared library, or have denied access somewhere, whatever. If that's the case, we should be able to report errors independently.


Libguestfs queries for libvirt capabilities anyway.  If we don't get a
satisfactory set of <guest/> elements, then we could list out the
<info/> section.  Easy for us.

The problem is the <info/> element hardly fits into capabilities.  If
we didn't put it there, could it go some other place?  Or a new API?

Are there other unanticipated problems here?  I think one is that
libvirt doesn't appear to collect detailed log information by default,
(unless the user edits log_level).  That's assuming I understand the
code correctly.  Personally I think libvirt should always collect
debug information, because you never know when it could be useful, but
for the above, collecting errors & warnings unconditionally is
sufficient.

Rich.


[1] By the way, this is a general complaint about libvirt.  Please
DON'T add any more stuff to the configuration file.  Everything should
be configurable through the API, or not at all.  There are two other
settings I can think of that libguestfs would like to adjust but
cannot because they are only available in a configuration file.


This all will be solved by administration module, once we implement it. I don't know about anybody working on it though.

Michal


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]