Allow running kvm backend without libvirt priviliges

[uzytkownik]

Currently kvm backend is using global libvirt daemon instead of user one. It would be nice if it was possible to run under user one (this would require exposing ports as network forwarding via user stack).

[afbjorklund]

I don't think that this is doable, there's a lot of ports to forward... That is why we gave up on having a qemu driver, it went away about the same time as localkube*. What is the problem with the libvirtd group ?

• #2399

[uzytkownik]

Reasons I requested:

• Older versions of NetworkManager did not played nicely with the bridges and tried to override configuration (seems to be fixed now but may still be present on older distros)
• In default configuration minikube command repeatedly asks for password (minikube docker-env asks 4 times) via pkexec.
• While this is not my usecase this is likely to be not possible for multi-user systems (think university labs)
• I'm just starting with Kubernets but it sounds like something following least privileges

[afbjorklund]

Yeah, the above reasons was why I did the qemu-kvm driver. But nowadays everyone is fine with running everything with admin privileges (think docker group), so I guess we'll just go with libvirtd and sudo...

https://wiki.libvirt.org/page/FAQ#What_is_the_difference_between_qemu:.2F.2F.2Fsystem_and_qemu:.2F.2F.2Fsession.3F_Which_one_should_I_use.3F

All 'system' URIs (be it qemu, lxc, uml, ...) connect to the libvirtd daemon running as root which is launched at system startup. Virtual machines created and run using 'system' are usually launched as root, unless configured otherwise (for example in /etc/libvirt/qemu.conf).

All 'session' URIs launch a libvirtd instance as your local user, and all VMs are run with local user permissions.

You will definitely want to use qemu:///system if your VMs are acting as servers. VM autostart on host boot only works for 'system', and the root libvirtd instance has necessary permissions to use proper networkings via bridges or virtual networks. qemu:///system is generally what tools like virt-manager default to.

qemu:///session has a serious drawback: since the libvirtd instance does not have sufficient privileges, the only out of the box network option is qemu's usermode networking, which has nonobvious limitations, so its usage is discouraged.

[afbjorklund]

I don't think we want to support this in minikube, sorry. Other setups might be able to make it work. So I think we will go with qemu:///system as the supported option, and recommend "getting root".

For multi-user systems there are other alternatives, than trying to run Kubernetes in user-mode... For instance you could have a shared Kubernetes cluster, or use cloud-provided virtual machines ?

[offlinehacker]

But nowadays everyone is fine with running everything with admin privileges (think docker group)

I think many people are not ok with running everything with sudo. Rootless containers can prove this. We just got used to, as we don't have good alternatives. I just wish there was a simple Linux native way to run kubernetes without having root.

[afbjorklund]

The “usernetes” project is doing this, you might to check there instead ?