[libvirt] Reporting log/error messages through capabilities

Michal Privoznik mprivozn at redhat.com
Wed Feb 19 13:01:43 UTC 2014


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




More information about the libvir-list mailing list