[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]