9:55 a.m.
On Mon, Mar 14, 2022 at 9:34 AM Peter Boy <pboy(a)uni-bremen.de> wrote:
While testing F36, I ran into a problem installing virtualization support on Fedora
Server. Until now we installed qemu-kvm, libvirt, virt-install, and additionally
cockpit-machines. That combo installs about 338 packages, at least 200 packages graphical
desktop related (X11, wayland, gtk3, even poppler pdf renderer, see [1]). This breaks
Fedora Servers fundamental headless core concept and installs lots of unusable and thus
locally uncontrolled/unmaintained software.
== In this respect, a correction is urgently needed. ==
=== qemu-kvm ===
The cause of the problem is the use of package QEMU-kvm, which is aimed - hitherto
unnoticed - at installation on a graphical desktop and therefore completely correctly
assumes the appropriate packages. This in turn relies on the @virtualization group, which
is the only public group supporting virtualization installation and is described
accordingly in the Fedora documentation (without mentioning the graphical bias).
It does not install a graphical desktop. It installs graphical
environment support packages for guests and hosts. Installing a
graphical desktop is quite a different thing altogether.
In principle, the solution is quite simple. The qemu-kvm developers
were wise enough to create a qemu-kvm-core group at the same time, which omits all
graphical references and allows for an excellent installation on Fedora Server.
It's not quite that simple. The core version also doesn't install
support for guest hardware acceleration and other things that would be
useful for guests. For example, things like virglrender, spice, qxl,
etc. stuff all require host components that you deem "unwanted".
=== libvirt ===
Unfortunately, the maintainers of libvirt are far from this wisdom and insist that the
libvirt package still relies on qemu-kvm, thus installing all the packages that
QEMU-kvm-core omits again anyway. An analogous libvirt-core does not exist. Instead,
Daniel Berrange refers to the list of individually available single packages, from which
one (i.e. server WG) should please compile and test a suitable mix and watch the libvirt
development steps to see if changes to the mix are required (see bug report by Martin Pitt
[2]).
== So we need to find a way to reliably determine a working set of libvirt packages for
Fedora Server (or change the tool set). ==
Maybe we can find support in Debian/Ubuntu, whose libvirt maintainers have solved the
problem, at least according to my first impression.
You will not. The maintainers for the Debian packages are the same
group of folks that work on the RPM packages in Fedora. The split is
synchronized between the Fedora spec and the Debian packaging
upstream.
=== Group virtualization-headless ===
An initial approach to a solution could be the group ==@virtualization-headless==. This
is a hidden group (see 'dnf group list -v hidden') that currently does pretty much
the same as @virtualization, unfortunately. We could contact the owner and modify the
group as required (or create a new group @virtualization-server). We could use that as a
means to organize a suitable libvirt mix.
=== Cockpit-machines ===
As a further consequence, the cockpit-machines module is currently effectively unusable.
It also has QEMU-kvm defined as a dependency. Even if we fix the libvirt problem with a
suitable mix, cockpit-machines would currently undo this effort. Martin Pitt is on the
way to fix it, see [3]. But we have to find a solution for F36.
Instead of using the virtualization group, just use the
cockpit-machines package to pull in the headless components. It's not
useful without it anyway.
However, most people will want *all* the virtualization components
rather than the "core" version.
--
真実はいつも一つ！/ Always, there's only one truth!