On Wed, Aug 13, 2014 at 08:43:43PM -0500, Richard Tollerton wrote: > Hi, > > I have 18 QEMU/KVM VMs configured on a local libvirtd instance. Normally > virt-manager connects to the session snappily, but when I set > 'access_drivers = [ "polkit" ]' in libvirtd.conf, virt-manager takes 7 > seconds to connect, and causes one of my cores to be pinned at 100% > usage. polkitd and libvirtd are the processes consuming CPU. This sucks, > and makes me reconsider recommending using virt-manager to others. > > Further investigation reveals that virt-manager is triggering **596** > polkit checks. In particular: > > - 240 from org.libvirt.api.node-device.getattr > - 120 from org.libvirt.api.node-device.read > - 128 from org.libvirt.api.domain.read > - obviously 18 of these are probably necessary > - 37 from org.libvirt.api.domain.read-secure > - 18 from org.libvirt.api.domain.getattr > - obviously all of these are probably necessary > > It seems like virt-manager is going out of its way to prefetch every > possible piece of system state; cf virtinst/connection.py and > virtManager/connection.py. Don't do that, I guess. Yep, virt-manager will load all domains, node devices, networks, storage pools, etc. Unfortunately this does indeed trigger alot of polkit checks when access control is enabled. virt-manager could optimize itself to only fetch state on demand, but even than I doubt it would reduce the initial penalty by a significant amount. > Note that `virsh list --all` does not have the same performance issues, > because it only does one domain.read and one domain.getattr for every > domain, which is optimal. Yep, 'virsh list -all' results in vastly fewer libvirt API calls than virt-manager makes. > I don't think I have an alternative to using polkit. I would like to > have a guest account that can only access a restricted list of VMs. > AFAIK, libvirt's other authorization facilities don't allow for that > sort of thing. > > So... maybe we could bypass connection prefetching under certain > circumstances? Or is pkcheck not supposed to be this slow? Unfortunately this is pretty much inherant in our use of pkcheck. I have a work in progress branch that kills pkcheck in favour of talking DBus directly. THis ought to have a major performance improvement. I don't have an ETA for completion of that work currently though 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 :| _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
