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.
I am sorry. I don't know what you mean by cooperation. This hasn't landed on the
meeting agenda since I have been putting more leadership around the project. Let's put
this back on the agenda.
"Bluntly failed" - implies there is greater communication and pushback in a way
that is irreconcilable. I don't see that.
The question now is how can we easily and efficiently provide a virtualized 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.
duplum is not a word that I know. I can only find "double the amount" as a
common latin transation. Can you explain what you mean here?
This is a complicated
Instead of Cockpit you could use an elaborate invocation of virsh,
but the effort will not
be less.
this is pretty well known using image-factory or kiwi. It's not too esoteric really. I
think the biggest complication will come in the form of building out the support model.
The typical configuration writes the filesytem directly to the volume since LVM isn't
typicall a best practice in most hyperscaler environments where the storage is already in
some sort of RAID configuration underneath.
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.
In the cloud efforts, that's expected. The underlying volumes can typically be
expanded to match the requirements of the user, but typically cannot be made smaller. Best
to start smaller and end up larger later. XFS works the same too.
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 Image Builder Tool / Cockpit module
The tool creates an elaborated image file. But in the current implementation it requires
I don't know what an elaborated image is.
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.
CAn you say more here?
(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.
on a typical image for use in a virtual environment where Cloud is used, firewall is not
necessary as it is typically handled at or above the hypervisor with NFV. You can easily
put it back, but you are adding overhead to the instance that isn't part of the
typical environment. Cockpit and packagekit don't work with RHUI implementations, but
they do work with Cloud. For individual instances or even an image that is expected to be
managed with Cockpit there is an easy path forward with cloud-init. Firewall will be
installed with Cockpit, so you get the bonus on that side. If you are saying that you can
start from the base Cloud image for that, I am not seeing it. Unfortunately, you can't
manage the underlying components yet, so you can't extend a storage volume or the like
in a just-in-time fashion without moving to another environment, but it would be awesome
to have that as a feature.
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.
How is that the case with CoreOS? I think they build their own OStree and then build the
images using a suite of tools that was originally developed externally.
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?
What is a "perfect image"?