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#)