F37 proposal: Supplement of Server distributables by a KVM VM disk image (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Supplement-server-by-kvm-vm-image

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Virtualization has long been a steadily growing use case of Fedora
Server Edition, but it is still time consuming and tedious for the
system administrator to create a Fedora Server VM. Supplementing the
downloads by a KVM VM image remedies the deficiency.

== Owner ==
* Name: [[User:pboy| Peter Boy on behalf of Server WG]]
* Email: pboy(a)uni-bremen.de


== Detailed Description ==
The creation of the VM disk image, uses the same kickstart files and
installation groups as the standard full installation,  except of
course for the hardware-specific items. The image is optimized for
KVM.

That way, the VM resembles a default server installation as closely as possible.

All administrative tools are available reliably from the beginning,
all administrative routines and helps (scripts) can be used in the
same way. All application services work in the identical  way.

A default VM installation takes 1-2 minutes instead of about 30 mins.

== Feedback ==
The change proposal is based on an extensive discussion of the server
WG and has become part of its work program. For example, the server
documentation on virtualization has already been significantly
expanded in parallel and will continue to be supplemented and updated
on an ongoing basis. This is a response to the importance of the
topic.


== Benefit to Fedora ==
Significantly improves usability for Fedora Server Edition
administrators when deploying a Fedora Server Edtion VM. It thus makes
Fedora Server Edition more attractive, especially for new users
without extensive experience with Fedora. It thus helps to expand our
user base.

Fedora finally provides an installation path for a Fedora Server VM
that is built entirely on Fedora Resources, subject to Fedora quality
control, and compliant with Fedora principles. Until now, if a system
administrator has to install a VM preferable without the hassles of a
full default installation, we could only recommend third party binary
blob (e.g. virt-builder), which is a violation of our own core
principles. In addition, the third party products do not provide a
'Fedora Server Edition', but their own different concept and vision of
a server, under the name Fedora Server.


== Scope ==
* Proposal owners:
A kickstart file for ImageFactory is completed and locally tested.

* Other developers:
n/a
* Release engineering: [https://pagure.io/releng/issues #10768]
* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)


* Alignment with Objectives:
n/a

== Upgrade/compatibility impact ==

none

== How To Test ==

Basically, the same test procedures as for the full install apply.

1. Install a Fedora Server Edition including virtualization, follow
the Server documentation

2. Import the Fedora Server disk image following the Server
documentation (staging), either using Cockpit or cli virt-install

3. Use the VM with your intendend server applications.

== User Experience ==

Users (system administrators) will have a VM install method available,
which saves them a lot of time and efforts.

== Dependencies ==

none



== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), No


== Documentation ==

N/A (not a System Wide Change)

Fedora Server documentation is available.

== Release Notes ==

TBD


--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Kevin Fenzi]

I'm definitely in favor, but a couple of questions... 

What format image is to be produced? qcow2? or raw.xz? or something
else?

I assume this will not be release blocking at least at first?

Thanks, 

kevin

[Neal Gompa]

On Mon, Jun 20, 2022 at 8:19 PM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  I'm definitely in favor, but a couple of questions...
>
>  What format image is to be produced? qcow2? or raw.xz? or something
>  else?
>
>  I assume this will not be release blocking at least at first?
>  
If it's for regular KVM, I assume qcow2. The only reason Fedora Cloud
images are raw instead of qcow2 is because cloud providers are bad at
handling QEMU's native format. I know if it were my choice, I wouldn't
ship raw images for Fedora Cloud. Too big and annoying to deal with.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Peter Boy]

>  Am 21.06.2022 um 02:18 schrieb Kevin Fenzi <kevin(a)scrye.com&gt;:
>  
>  ...
>  What format image is to be produced? qcow2? or raw.xz? or something
>  else? 
The current implementation creates compressed qcow2 file to make use of the dynamic
capabilities. The default max disk size is 40 GB, the image size is 595 MB. The server
documentation will describe how to adjust the properties
(https://docs.stg.fedoraproject.org/en-US/fedora-server/virtualization-vm-...,
currently incomplete first draft)

>  I assume this will not be release blocking at least at first? 
Admittedly, not thought and not decided explicitly about it in WG. In the long run it
should have the same status as the other three server distribution files (full install,
net install, aarch64 SBC image). Virtualization is one of the core features. But, if we
don’t get it built and booted problem-free during beta, we would postpone it anyway (the
current kickstart file builds fine in a local ImageFactory environment,
https://pboy.fedorapeople.org) 




--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
pboy(a)fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)


Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast

[Florian Weimer]

* Ben Cotton:

>  The creation of the VM disk image, uses the same kickstart files and
>  installation groups as the standard full installation, except of
>  course for the hardware-specific items. The image is optimized for
>  KVM.
>
>  That way, the VM resembles a default server installation as closely as
>  possible. 
Will the image still attempt to download instance metadata over the
network (via cloud-init or some other mechanism), or is this excluded?

I think the cloud-init part is the most problematic (even dangerous)
aspect of using the existing cloud images under KVM.

Thanks,
Florian

[Neal Gompa]

On Tue, Jun 21, 2022 at 3:28 AM Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  * Ben Cotton:
>
>  > The creation of the VM disk image, uses the same kickstart files and
>  > installation groups as the standard full installation, except of
>  > course for the hardware-specific items. The image is optimized for
>  > KVM.
>  >
>  > That way, the VM resembles a default server installation as closely as
>  > possible.
>
>  Will the image still attempt to download instance metadata over the
>  network (via cloud-init or some other mechanism), or is this excluded?
>
>  I think the cloud-init part is the most problematic (even dangerous)
>  aspect of using the existing cloud images under KVM.
>  
cloud-init doesn't *have* to do that. It generally doesn't if it
doesn't recognize the hypervisor platform.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Peter Boy]

>  Am 21.06.2022 um 09:28 schrieb Florian Weimer
> <fweimer(a)redhat.com&gt;:
>  
>  
>  Will the image still attempt to download instance metadata over the
>  network (via cloud-init or some other mechanism), or is this excluded? 
No, it will not. Currently, it uses FirstBoot. It’s a bit cumbersome, I know, but that is
what we have and already use with the SBC image. Alternatively, the documentation
describes how to use guestfs-tool’s virt-customize for initial configuration and disabling
FirstBoot.


>  I think the cloud-init part is the most problematic (even dangerous)
>  aspect of using the existing cloud images under KVM. 
Cloud-init provides a "no-cloud“ option. But there are several long-standing bugs
with it (especially network configuration). Naturally, in a cloud specific development, a
no-cloud option does not necessarily rank high on the list of priorities. And it does not
support setting up Fedora Server Edition's default configuration in a =simple= way,
e.g. disabled root account. You have to provide a full meta data config file instead of
using CLI parameters or Cockpit UI options.

[Zbigniew Jędrzejewski-Szmek]

Hi,

I tried to use the image, and I have a small suggestion:
please add links to where the resulting images can be found to the Change page.
W/o that it's entirely non-obvious where to look for it.

Zbyszek


On Thu, Jun 02, 2022 at 03:28:21PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Supplement-server-by-kvm-vm-image
> 
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
> 
> == Summary ==
> Virtualization has long been a steadily growing use case of Fedora
> Server Edition, but it is still time consuming and tedious for the
> system administrator to create a Fedora Server VM. Supplementing the
> downloads by a KVM VM image remedies the deficiency.
> 
> == Owner ==
> * Name: [[User:pboy| Peter Boy on behalf of Server WG]]
> * Email: pboy(a)uni-bremen.de
> 
> 
> == Detailed Description ==
> The creation of the VM disk image, uses the same kickstart files and
> installation groups as the standard full installation,  except of
> course for the hardware-specific items. The image is optimized for
> KVM.