libvirt users - Apr 2019 - libvirtd via unix socket using system uri

I want to run libvirtd as a special user, and allowing users that belong
to a special group to connect via qemu+unix:///system (eg: unix socket).

I did everything necessary to do so: created a libvirt user and group,
added the libvirt user to the kvm group, added my normal user to the
libvirt group, and made sure the socket is owned by libvirt:libvirt with
permissions set to 770.

libvirtd starts successfully, but when I try to connect as the normal
user I get this error:

bash$ virsh --connect qemu+unix://system
error: failed to connect to the hypervisor
error: invalid argument: using unix socket and remote server 'system' is
not supported.

A trace shows virsh is not even trying to open the socket.

I want to use the socket because I just need local connectivity and
don't want to run sasl and set up certificates for this, but at the same
time want to run libvirtd as a dedicated user.

Is there any reason to prevent libvirt from being used like this?

On 4/29/19 1:06 PM, lameventanas@gmail.com wrote:
> I want to run libvirtd as a special user, and allowing users that belong
> to a special group to connect via qemu+unix:///system (eg: unix socket).
> 
> I did everything necessary to do so: created a libvirt user and group,
> added the libvirt user to the kvm group, added my normal user to the
> libvirt group, and made sure the socket is owned by libvirt:libvirt with
> permissions set to 770.
> 
> libvirtd starts successfully, but when I try to connect as the normal
> user I get this error:
> 
> bash$ virsh --connect qemu+unix://system
> error: failed to connect to the hypervisor
> error: invalid argument: using unix socket and remote server
'system' is
> not supported.
This is not valid URI.

https://libvirt.org/uri.html

You may want to use 'qemu+unix:///system' or simply
'qemu:///system'
which is the same because libvirt connects via unix socket by default.

Anyway, you'll need to run libvirtd privileged, otherwise it'll get 
EPERM when trying to do almost anything.

Michal

On 29/04/2019 22.01, Michal Privoznik wrote:
> On 4/29/19 1:06 PM, lameventanas@gmail.com wrote:
>> I want to run libvirtd as a special user, and allowing users that
belong
>> to a special group to connect via qemu+unix:///system (eg: unix
socket).
>>
>> I did everything necessary to do so: created a libvirt user and group,
>> added the libvirt user to the kvm group, added my normal user to the
>> libvirt group, and made sure the socket is owned by libvirt:libvirt
with
>> permissions set to 770.
>>
>> libvirtd starts successfully, but when I try to connect as the normal
>> user I get this error:
>>
>> bash$ virsh --connect qemu+unix://system
>> error: failed to connect to the hypervisor
>> error: invalid argument: using unix socket and remote server
'system' is
>> not supported.
> 
> This is not valid URI.
> 
> https://libvirt.org/uri.html
> 
> You may want to use 'qemu+unix:///system' or simply
'qemu:///system'
> which is the same because libvirt connects via unix socket by default.
Thanks, I missed that.

Now I get this:

$ virsh --connect qemu:///system
error: failed to connect to the hypervisor
error: internal error: unexpected QEMU URI path '/system', try
qemu:///session

But now I see virsh opening the socket, writing, etc.

The server log shows this:

2019-04-29 15:32:07.306+0000: 20863: info : libvirt version: 5.2.0
2019-04-29 15:32:07.306+0000: 20863: info : hostname: koji
2019-04-29 15:32:07.306+0000: 20863: error : virDBusGetSessionBus:169 :
internal error: Unable to get DBus session bus connection: Unable to
autolaunch a dbus-daemon without a $DISPLAY for X11
2019-04-29 15:32:24.534+0000: 20852: error : qemuConnectOpen:1127 :
internal error: unexpected QEMU URI path '/system', try qemu:///session
2019-04-29 15:32:24.534+0000: 20851: error : virNetSocketReadWire:1803 :
End of file while reading data: Input/output error

I also wonder if dbus is important, and if so, how to fix it.

> Anyway, you'll need to run libvirtd privileged, otherwise it'll get
> EPERM when trying to do almost anything.
I'm aware of that, I want to try and see the limitations, and maybe get
around them by using capabilities?