quickstart should be runnable without privileged access

[larsks]

Currently, the quickstart requires root privileges on the target host and makes a number of system configuration changes. This makes some folks (understandably) nervous and may inhibit the adoption of the tool.

Most of the privileged access is required to configure networking.

We ought to be able to complete just about everything through the use of qemu user mode networking. There are a few options:

• An unprivileged user can attach to pre-configured host bridges through the use of the qemu-bridge-helper tool. With the packages shipped in RHEL/CentOS/Fedora/etc, this will Just Work with the virbr0 bridge created by the libvirt default network. We can take advantage of this to create inbound access into the virtual environment.
• danpb suggested mcast networks. These are simple to setup, but getting them to work does require administrative access on the host to (a) enable multicasting on the loopback interface (ip set multicast on dev lo) and (b) to add the necessary routes so that the multicast traffic uses the lo interface.
• An unprivileged user can create tunneled networks between guests. There are various options for this, but the best may end up being tcp tunnels. These are point-to-point networks between individual guests, so you need one interface per guest. In this model, we would probably treat the undercloud node as a "switch"; we would create a bridge in the undercloud for each virtual network, and then plug all the the other guests in as necessary.
• qemu also supports "user" networks. With libvirt there can be only one. User networks provide outbound access from the guest to the host or to the internet, but do not provide for any inbound access.

I kind of like the tcp model.

[larsks]

https://review.gerrithub.io/#/c/265256/ is sort of step 1 of this process. That change makes it so that we no longer care about the physical location of the libvirt storage pool, which means we don't care if it is in /var/lib/libvirt/image or $HOME/myimages or whatever.

[larsks]

I've been playing with this a bit over the weekend. Here are some more thoughts:

• Networking is a pain the derriere. TCP networking works but apparently doesn't recover if the "server" side of the connection restarts, and also requires something to act as a virtual router, which can be the undercloud but adds a substantial chunk of network configuration.
• UDP unicast networks don't have the problem with restarts (yay, stateless protocols) but still suffer from the point-to-point nature of the connections and require specifying two endpoints. And they're not supported until libvirt 1.2.20, which rules them out on EL7 distributions anyway.
• Multicast network are easier (because they're not point-to-point, so they act much more like a bridged network), but as noted earlier they really require root privileges at some point to get things set up correctly.

We need root privileges anyway for certain tasks, specifically:

• Package installation
• Kernel module configuration

So as long as we need root anyway, I think the easiest solution is just set up some bridges on the host and whitelist them in /etc/qemu/bridge.conf so that they can be used by an unprivileged user. This removes all the annoying complexity that would be introduced by the tunnel networks.

What we need to do is to clear separate "tasks that absolutely require privileges" from "tasks that can actually be run as anybody". I think we can start by moving the libvirt/setup/install role up one level, to libvirt/install, and isolate all the root-requiring tasks in that role. People who already have a virt-capable machine can then skip that part and run everything else as an unprivileged user.

[trown]

+1 to this approach. Having all of the privileged steps in a single place makes it easier for someone to audit what steps are need privileges as well.

[larsks]

I've opened a gerrit topic to explore this issue. So far it's mostly prep work, some of which I'm not entirely happy with it. Comments welcome.

[larsks]

This was resolved by https://review.gerrithub.io/#/c/265712/