Re: [libvirt] Reporting log/error messages through capabilities
On Wed, Feb 19, 2014 at 02:00:21PM +0000, Daniel P. Berrange wrote:
On Tue, Feb 18, 2014 at 11:11:10PM +0000, Richard W.M. Jones wrote:
> 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].
The problem with allowing apps to change the logging config is that
it is global state, not per client. So multiple apps would conflict
in what they could do with changes here. While we could probably
make it possible for apps to register their own callback to receive
log messages, the setting of actual log levels would still be global.
This comes back to the whole private libvirtd thing. Even sharing a
single session libvirtd with the current user has proven problematic
for libguestfs, and it's a big mess for root. See bugs passim. In an
ideal world we'd have one private libvirtd per connection.
> [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.
What are the other settings you're thinking of here?
- log_level / log messages as discussed.
- qemu user/group: when libguestfs runs as root, we'd like to set it
to root/root
- max_clients
There are lots of problems (still) with max_clients. The default
setting is far too low. The default was recently increased but we
cannot read what it is, thus cannot make a decision on how many
threads we can run safely. And being a global setting (and us being a
local library) it wouldn't help much even if we could read it, because
another libguestfs instance might be running threads. Ideally it
would be just a safety mechanism, stopping someone from connecting
thousands of times, and would also depend on the size of the main
memory.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)