Re: [libvirt] Reporting log/error messages through capabilities
On Wed, Feb 19, 2014 at 05:00:43PM +0000, Richard W.M. Jones wrote:
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.
Yep, I don't have a perfect answer for that yet. Conceptually the
idea of having a dedicated "root" session libvirtd but it does raise
co-ordination issues. eg when libvirtd tracks what vms are using
what PCI devices it is assuming there's only one privileged libvirtd
instance. We could avoid this by saying that the 'session' instance
that runs as root is unprivileged and thus not allowed to use PCI
devices and other such things, but there could be dragons here.
> > [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
We do have an override for that in the XML now, though I do
recall there were some issues. Conceptually though, the goal
of the XML override is that it /ought/ to be functionally
identical to changing the global config file.
- 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.
We are partway through changing this. The end goal is that we'll have a
new 'max_anonymous_clients' setting that will be a low value and just
prevents DOS from clients which have not yet authenticated. The existing
'max_clients' value will then only apply to authenticated clients, and
can thus be raised to a very high value such that people won't hit it
in any reasonably normal usage.
I thought we'd finished it, but I see it is outstanding review still
https://www.redhat.com/archives/libvir-list/2013-December/msg00453.html
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 :|