The nested virtualization requirement really limits where we can run Contest - Testing Farm (both ranches) have difficulty providing hardware that would support it, or support it well (without 100x slowdowns).
Even on our HW, nested VMs run allegedly 2x slower than normal VMs, so we should at least try to avoid them.
The possible solution - Linux Namespaces, a.k.a. containers.
It should be possible to run Contest under podman, and pass /dev/kvm to the containers, allowing them to spin up libvirtd instances and create their own VMs inside the containers, utilizing HVM acceleration of the host. #399 is slightly related here, but since containers can have isolated networks, it isn't a pre-requisite.
There might be some use-case-specific issues, like osbuild composer daemon (/hardening/container) not liking the container environment, but that should be work-around-able, especially given that podman can run full booted systemd-based OS inside containers.
One chalenge would be - where to get the container images for the currently-installed OS? But perhaps we could build them (go see how Fedora builds their image) from /etc/yum.repos.d on the host OS itself, ie. dnf download or install into some root tree, and then pack into an image.
The containers don't have to be run unprivileged - we can start them under root on the host OS, but they should have "some" level of isolation, so a bad test can't insta-destroy the host OS (which would be persistent, like tethys/mimas).
This issue is mostly about experiments and exploration, to see if it would be possible.
The nested virtualization requirement really limits where we can run Contest - Testing Farm (both ranches) have difficulty providing hardware that would support it, or support it well (without 100x slowdowns).
Even on our HW, nested VMs run allegedly 2x slower than normal VMs, so we should at least try to avoid them.
The possible solution - Linux Namespaces, a.k.a. containers.
It should be possible to run Contest under podman, and pass
/dev/kvmto the containers, allowing them to spin up libvirtd instances and create their own VMs inside the containers, utilizing HVM acceleration of the host. #399 is slightly related here, but since containers can have isolated networks, it isn't a pre-requisite.There might be some use-case-specific issues, like osbuild composer daemon (
/hardening/container) not liking the container environment, but that should be work-around-able, especially given that podman can run full booted systemd-based OS inside containers.One chalenge would be - where to get the container images for the currently-installed OS? But perhaps we could build them (go see how Fedora builds their image) from
/etc/yum.repos.don the host OS itself, ie.dnf downloador install into some root tree, and then pack into an image.The containers don't have to be run unprivileged - we can start them under root on the host OS, but they should have "some" level of isolation, so a bad test can't insta-destroy the host OS (which would be persistent, like tethys/mimas).
This issue is mostly about experiments and exploration, to see if it would be possible.