I do disagree with you on the usage of cockpit not being a "suitable solution". I believe that the tool is an easy to use one that allows users to feel confident in what they are deploying and creating. If we do come to a decision where we create our own tool for the server VMs how can we ensure that it would not be too hard to use for users and be an option that represents our core values:

(Freedom, Friends, Features, and First)
We could provide documentation on the fedora wiki on how to use the new software to manage the server VM's and images via LAN, yes however I just doubt it will be as solid as cockpit is among the community. 

Thanks,
Ahmed Almeleh
Fedora QA Tester






On Fri, 29 Oct 2021 at 20:43, Peter Boy <pboy@uni-bremen.de> wrote:
On our agenda there is the project "Facilitated and improved support for Fedora Server Edition VMs". Once started as a prospective cooperation with cloud WG, this prospect has bluntly failed.

The question now is how can we easily and efficiently provide a virtualised version of Fedora Server for a bare-metal Fedora Server with virtualisation support installed. This question becomes urgent given the power of current hardware.

Currently there are 4 Options ready to use:

(1)
Usage of Cockpits 'Create VM' which launches Anaconda installation support and guides you through the standard installation process.

You get a perfect duplum of Fedora Server in virtualized form, but at the price of a significant amount of work.

Instead of Cockpit you could use an elaborate invocation of virsh, but the effort will not be less.

That's not exactly the goal of our project.

(2)
Installation of guestfs-tools (f35, libguestfs-tools-c in f34) and use virt-builder to create a partly customized disk image (e.g. root password) that you can import using virsh

You get a disk image file pretty quickly and importing it into KVM is easy and fast as well.

You will not get a duplum of Fedora Server virtualized, contrary to the description in virt-builder. Cockpit is not installed, filesystem is without LVM, many software packages are missing (vim, tar , sshfs, etc), firewall without Fedora Server zone - just to name a few.

The qcow2 image file created by default has a capacity of 10 GiB and also occupies 10 GiB in the file system - so no use of dynamic capability of qcow2 format. The image is generated on an external server and imported as a binary.

With all the effort we put into Fedora to build even the smallest rpm package completely from source on Fedora infrastructure, it seems pretty absurd to use a complete VM binary from a third party source or to rely on an external binary image.

Overall, this is not a suitable solution.

(3)
Usage of mage Builder Tool / Cockpit module

The tool creates an elaborated image file. But in the current implementation it requires almost a similar effort as an Anaconda installation. And as in the case of virt-builder, a binary is imported from an external source.

So it is a similarly limited suitable solution.

(4)
Usage of cloud base image

This solution would be Fedora controlled after all. Importing via virsh is simple and fast. But the result is far from being a duplum of Fedora Server - no firewall, no cockpit, different file system, missing software, just to name a few. And a duplum is explicitly not intended by cloud WG.

Altogether, this option is not a solution either.


= Conclusion =

Unless I have overlooked an adequate tool, our only option is to supply our own image file - similar to what CoreOS does.

We already provide a perfect image file for Arm64 SBC devices - including initial configurability, similar in scope to Anaconda. Could this serve as a template?

Maybe that would be a realistic goal for F36 release?


Feedback and other possible alternatives are very much appreciated.


Best
Peter



_______________________________________________
server mailing list -- server@lists.fedoraproject.org
To unsubscribe send an email to server-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure