Re: libvirtd via unix socket using system uri

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/29/19 5:42 PM, lameventanas@xxxxxxxxx wrote:


On 29/04/2019 22.01, Michal Privoznik wrote:
On 4/29/19 1:06 PM, lameventanas@xxxxxxxxx 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.

This happened because qemu driver for /system doesn't initialize unless libvirtd's EUID == 0.



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?


Is there any problem running libvirtd as root?

Michal

_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users



[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux