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