[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