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#) -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list