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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to server-leave(a)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