Am 15.03.2022 um 01:49 schrieb Neal Gompa
<ngompa13(a)gmail.com>:
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 ===
>>> ...
>
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.
Agreement on the benefits of paravirtualization. But
They also make it possible to do things like clipboard redirection,
remote USB device attach, etc.
How can I do clipboard redirection on a headless hosting server? How will I attach a USB
stick in a server rack?
What am I doing with clipboard redirection on a VM providing a Web server, mail hub, and
similar services, that are the "bread and butter" applications on VMs. In these
cases we don’t need those 200+ graphic related packages, that libvirt pulls in without
regard to whether they are needed.
My intention is just to provide lean server installation for the 'bred and butter'
use case. And of course, virtualization for the desktop is untouched by this and remains
as it is. And we may extend the server virtualization support for use cases, where a
remote desktop system (e.g. kind of Citrix) should run on a VM and needs enhanced graphics
support. I don’t know if this would be feasible with Fedora resources, but just in case.
> 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.).
Possible yes, but not doable for now. There is no way to install cockpit-machines without
accepting 200+ packages not usable. I hope, Martin can change that and can do that in not
a too distant future.
And you can’t use libvirt without accepting those 200+ packages, because we have no group
or meta package and no valid information which packages are required. Support by
developer/maintainer as well as documentation are sparse, a system administrator must try
and test back and forth. Not a good state of affairs for a reliable product.
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.
I understand that. As a very gentle reminder, you applied for Server WG membership and
committed to contribute N hours of work per week on it's chores (a short version of my
favorite quote from Stephen Smoogen in the revitalization discussion last year).
Perhaps you could use your knowledge and experience to suggest, for example, a set of
libvirt individual packages that we may start with to emulate a libvirt-core metapackage.
And you could coordinate with Martin that we use the same or compatible set of dependant
packages. Not that we end in the same situation as currently.
Just 2 concrete suggestions that I hope are within your time allotment.
Best
Peter