Title says it all
The title doesn't really say it all. This is a complicated one: 1. virt-manager can be used remotely 2. libvirt itself only even uses the group with USE=polkit
Sorry for the late reply :( Could it be displayed in the info after you install a package so people know about it if they need it?
So would it make sense to require libvirt with the same state of policykit USE flag as libvirt? I mean, IIUC the problem is virt-manager was built with policykit but libvirt wasn't. And while it's true that virt-manger can be used remotely there's no way to guarantee that on ebuild level. I mean, libvirt.so (to which virt-manager ultimately links to) is not in a separate package. Unless we want to fine tune the dependency (libvirt built without libvirtd/lxc/qemu/virtualbox/... USE flags). And even then, libvirt has these "local" drivers (like virtualbox) where it's just a very thin layer that translates hypervisor APIs onto libvirt APIs (virtualbox is perfect example). But then again, policykit would be a problem iff libvirt was built with policykit. If we agree I can post a fix.
(In reply to Michal Privoznik from comment #3) > So would it make sense to require libvirt with the same state of policykit > USE flag as libvirt? I mean, IIUC the problem is virt-manager was built with > policykit but libvirt wasn't. > > And while it's true that virt-manger can be used remotely there's no way to > guarantee that on ebuild level. I mean, libvirt.so (to which virt-manager > ultimately links to) is not in a separate package. Unless we want to fine > tune the dependency (libvirt built without libvirtd/lxc/qemu/virtualbox/... > USE flags). And even then, libvirt has these "local" drivers (like > virtualbox) where it's just a very thin layer that translates hypervisor > APIs onto libvirt APIs (virtualbox is perfect example). But then again, > policykit would be a problem iff libvirt was built with policykit. > > If we agree I can post a fix. I think a policykit= dep on libvirt would work. Interestingly virt-manager isn't even depending on libvirt at all (directly) right now, but AFAIK it *does* need libvirt to do the remote connection, right?
@Michal: There is a question from Sam open :-)
(In reply to Sam James from comment #4) > I think a policykit= dep on libvirt would work. Interestingly virt-manager > isn't even depending on libvirt at all (directly) right now, but AFAIK it > *does* need libvirt to do the remote connection, right? Yeah. virt-manager depends on libvirt-python (which is a python bindings to libvirt), because virt-manager is written in python. However, libvirt-python does depend on libvirt, because as I said, the python bidings are really just a very thin layer that exposes C functions into python (via cpython). But now that I think about this even more, I'm failing to understand why virt-manager would require libvirt with polkit. After debugging this for a bit, the real problem here is that when libvirt's build without polkit, the socket it creates (for user to connect to, including virt-manager), is owned by root:root and has perms 0700 whereas with polkit it has perms of 0777. That's what's denying virt-manager connection. Looking further into the code, libvirt's built in defaults are so that with polkit the socket perms are 0777 and without it are 0700. But these can be changed in /etc/libvirt/libvirtd.conf (or virtWHATEVER.conf when using the split daemon), bu changing unix_sock_rw_perms knob. After all, virt-manager can work even without libvirt group, but not out of the box. The user most friendly thing here, IMO, would be just to have app-emulation/libvirt[policykit] as a runtime dependency for virt-manager. This does not really bring any new dependency, because virt-manager already requires libvirt, transitively. The other option would be a postinst message (elog).
Having a slightly different, but tangential bug. When the /var/run/libvirt/libvirt-sock is created its permissions are root:root which means that the traditional steps of adding your user to the libvirt group fail, because they don't have permissions for the socket. I can only assume that this is related to the non-inclusion of the libvirt group. I'm also not using the polkit use flag.
I ran into this same problem as well. It would at least be helpful to indicate to the user (maybe via ewarn?) that the 'policykit' USE flag is needed for libvirt in order to create the group. If not via ewarn, maybe at least in the documentation for libvirt or virt-manager? Cheers, Nathan Zachary
