Am 01.11.2021 um 20:17 schrieb David Duncan
> 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,
> 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.
It came up during the „Server reboot“ meeting December 2020. It was the idea of Matthew,
server and cloud are the same (basic concept), but (implemented) in different contexts. We
had various short discussions in the first quarter this year and a longer discussion with
Dusty, March 3
and some discussion in various contexts. I wrote a short paper about various options of
possible cooperations and possible synergy effects (e.g. creating / maintaining
documentation and other).
I wrote a Fedora Magazine article about using cloud generic image als VM in Fedora Server
March 29) and a corresponding guide as part of Server documentation
But that’s history and current opinion is that the two are completely different products.
"Bluntly failed" - implies there is greater communication
and pushback in a way that is irreconcilable. I don't see that.
Well, I’m not a native speaker, maybe some formulations have a connotation not seen by me.
Anyway, I (and also Matthew) were accused by some Cloud-WG members that we wanted to
"kill“ Cloud and/or cloud wg. And those members have explicitly stated there should
be and will be no cooperation at all.
Maybe "Bluntly failed“ is not exactly a correct phrasing for that. And of course,
nothing is irreconcilable in my opinion.
> 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.
> question becomes urgent given the power of current hardware.
> Currently there are 4 Options ready to use:
> Usage of Cockpits 'Create VM' which launches Anaconda installation support
> 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?
The word means a replica, but in a different context. So I mean an as perfect a rebuild of
Fedora Server as possible, not bare metal but in a virtual environment (the details of „as
perfect a rebuild“ have yet to be decided).
(It’s originally Latin and denotes in the ancient music the opposite voice to the tenor in
a higher register - sorry, sometimes I get carried away)
> Instead of Cockpit you could use an elaborate invocation of virsh, but the effort
> 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.
> 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.
Yes, I agree. In a server admin you may want to start with kind of thin provisioning. So I
think, a VM disk image should be distributed as small as (reasonable) possible and let the
admin choose an initial size (as cloud base image does, if I remember correctly).
> 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
> from a third party source or to rely on an external binary image.
> Overall, this is not a suitable solution.
> Usage of Image Builder Tool / Cockpit module
> The tool creates an elaborated image file. But in the current implementation it
I don't know what an elaborated image is.
I mean, there are many and detailed configuration options, so the resulting disk image can
be customized very precisely.
> 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?
The tool has similar issues as virtual-builder. The disk image is created on non-Fedora
infrastructure and imported as binary (what we avoid on package level at all costs). And
it involves a significant amount of work for sysadmin, at least the first time. It is
probably faster to do an Anaconda installation via Cockpit.
> Usage of cloud base image
> This solution would be Fedora controlled after all. Importing via virsh is simple
> 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
> 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.
Yes, cloud is a different context with different requirements, of course. Cloud WG creates
several variants, including a base image as a generic VM image for a generic virtual
machine (according to the download page description). If we were to cooperate, we could
build this variant or another one to fit Fedora Server perfectly - using Cloud WG's
knowledge and skills instead of building something ourselves. And in return server wg
could do something that would be useful for cloud as well.
That was the basic idea at the beginning of the year. But that "has bluntly failed“ -
so far at least.
> = Conclusion =
> Unless I have overlooked an adequate tool, our only option is to supply our own image
> - 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.
As far as i know they distribute several deliverables, for cloud, for VM and for bare
> We already provide a perfect image file for Arm64 SBC devices -
> configurability, similar in scope to Anaconda. Could this serve as a template?
What is a "perfect image"?
It perfectly replicates a standard installation with Anaconda. You get a Fedora server
build as VM like a full Anaconda installation, same software, same file system, same
management tools, firewall, cockpit, etc.. If you don't know, Sysamin doesn't
notice if he is on the server installation or in the VM.
Many thanks for all your information and hints.