[libvirt] Reporting log/error messages through capabilities

Daniel P. Berrange berrange at redhat.com
Wed Feb 19 13:41:21 UTC 2014


On Tue, Feb 18, 2014 at 11:11:10PM +0000, 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>
> 
> 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?

Yeah, I don't really like the idea of doing this in the capabilities
XML. 

I'm not even really convinced this should be in the API at all in fact.

What we could usefully do in libvirt though is to log a structured
message to the systemd journal when we find a QEMU binary that we
fail to extract capabilities from. Apps that care about it could
directly query the journal for the precise well-known log UUID.

And of course it goes without saying we should never have got into
this scenario in the first place. We need better testing of QEMU
binaries to make sure such brokenness can get detected at build
time.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list