On Mon, Mar 14, 2022 at 8:31 PM Peter Boy <pboy(a)uni-bremen.de> wrote:
> Am 14.03.2022 um 15:55 schrieb Neal Gompa <ngompa13(a)gmail.com>:
>> === 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
> 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.
I hope, my wording is not that misleading. I wrote "installation =on= a graphical
desktop“ and not "installation =of= a graphical desktop“.
We don't want „graphical environment support packages" for server hosting VMs,
that’s the idea of headless. Using virtualization on a desktop is different, there we need
"graphical environment support packages“, indeed. And therefore we need different set
of packages for installation. Therefore, qwmu-kvm and qemu-kvm-core is a great combination
and libvirt and libvirt-core would be if our libvirt maintainers could get around to it.
>> 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".
What I "deem unwanted" is unused software installed. Do you really need poppler
on a headless Server hosting virtual machines in a datacenter?
And what hardware acceleration? The typical server, even tagged with 10T or more, has a
lot of expensive and high-performance equipment, but no graphics hardware with significant
acceleration potential. And for those use cases that can make use of graphics hardware
acceleration (and equipped with the latest Nvidia gizmo), you may have to install the full
set of packages and not just the core. It could be as simple as that.
Paravirtualized hardware eliminates performance drops caused by
emulating hardware. That's done by doing "guest hardware acceleration"
with hypervisor-oriented hardware (virtio, qxl, etc.) which passes
through straight to the host.
You can knock out a virtual host with high IP traffic with an emulated
network card because it will peg the CPU, for example. I've done that
enough times to know that you don't want that. Same goes for
"graphics", "input", etc.
They also make it possible to do things like clipboard redirection,
remote USB device attach, etc.
>> 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
Even better. At least Debian / Ubuntu are able to install libvirt on a headless server
without installing about 200+ unused packages. We are (currently) not.
It's *always* been possible with Fedora to do that. Both distributions
also (sensibly) default to providing a fully featured stack. The
difference is that our stack uses metapackages instead of weak
dependencies because that makes it easier for project/product
dependency mixes (oVirt, OpenStack, KubeVirt, Cockpit, etc.).
>> === 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 . 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'snot
> useful without it anyway.
Why (or what) is it „not useful without (Cockpit) anyway“?
Currently it doesn’t help, because cockpit-machines pulls in the same set of software.
And in the long term we must be able to provide virtualization support without depending
> However, most people will want *all* the virtualization components
> rather than the "core" version.
Of the 4 discussants here so far, you are the only one. That is not exactly „most“.
You are right about desktops. But we talk about server here. And most server system
administrators don’t want wayland or X11 or GTK installed on their headless servers. Many
of them consider even cockpit superfluous. And they don't need a hardware accelerated
terminal, from 9600 baud to 14,400 or lightning fast 19200 baud (sorry, just kidding on a
What I really miss - unfortunately - is a constructive proposal which of the 200+
software packages we can use on a hosting server and for what purpose or use case. And
which we will definitely not.
And it would be great if you would contribute your knowledge and expertise to our server
WG, and put such a differentiation into practice.
I have extensive knowledge of the virtualization stack, how it's
packaged, and why because I have worked with it for many years.
However, I am personally stretched so thinly right now that I
literally cannot do more than I'm doing now for Fedora.
真実はいつも一つ！/ Always, there's only one truth!