[virt-tools-list] virt-manager takes 7 seconds+100% CPU to connect to polkit-enabled libvirtd on localhost

[Daniel P. Berrange]

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 :|