libvirt: move to user session, instead of system

[gbraad]

https://github.com/code-ready/machine-driver-libvirt/blob/f4233f67b9694ed8a77ae130540ff18158a51ebe/constants.go#L7

[cfergeau]

The disk image will need to go to another place, not /var/lib/libvirt/images and some changes to /etc/qemu/bridge.conf will be needed during preflight

[gbraad]

the images are already under the user's home directory as .crc/machines/crc/...
and the VM is bound to a specific network, called crc, but this is not created by the driver... just the preflight checks.

[cfergeau]

In qemu:///session, neither qemu nor libvirtd have enough priviledges to attach to the bridge that you created, so they use the suid qemu-bridge-helper binary for that. This binaries looks for a whitelist of bridges in /etc/qemu/bridge.conf, so tt0 will have to be added there.

[felipeborges]

Another compelling reason to move to user session is to distribute CRC in image-based read-only operating systems such as Fedora Silverblue, EndlessOS, or CoreOS. These technologies are getting popular and are likely going to be used by a significant group of developers in the near future.

In these systems, you would need to overlay tons of packages to be able to setup a CRC environment. Or alternatively (what we probably want), CRC could be distributed in a container format such as Flatpak.

A Flatpak would allow to easily distribute CRC accross multiple distributions, create single file bundles to distribute, setup a repository so maintainers can deliver updates at their own pace, etc...

GNOME Boxes is distributed as a Flatpak and bundles the whole virtualization stack with it in a container. In Boxes, libvirtd, qemu, and everything runs inside the container sandbox.

I know that lots of the setup/preflight operations performed by CRC depend on running privileged applications in the host (nmcli, systemctl, etc...). For that, I was thinking of writing a Flatpak Portal that can run in the host and bridge the requests from within the container to the host outside. Think of it as a "runc" type of utility that can spawn processes in the host.

Besides that, lots of the IPC could be done with D-Bus. NetworkManager, for one, has a very complete D-Bus API that could create/setup interfaces and all.

[zeenix]

Thanks @felipeborges . The main hurdle I see in this is the networking bits. The setup we currently do on the host is not possible through D-Bus AFAIK but we'll not need to do that if we can figure out how to get this WIP PR of mine to work. i-e I think this is entirely dependent on crc-org/crc#591.

[zeenix]

Actually never mind what I wrote above (woke up much earlier today then usual). :)

I know that lots of the setup/preflight operations performed by CRC depend on running privileged applications in the host (nmcli, systemctl, etc...). For that, I was thinking of writing a Flatpak Portal that can run in the host and bridge the requests from within the container to the host outside. Think of it as a "runc" type of utility that can spawn processes in the host.

Cool. I think that's the main hurdle then. Once setup is done (and what @cfergeau wrote in #20 (comment) should be part of that), crc start can launch the VM on session libvirt I believe.