On Tue, Feb 1, 2022 at 7:55 PM Richard W.M. Jones <rjones@redhat.com> wrote:

On Tue, Feb 01, 2022 at 12:14:37PM -0500, Neal Gompa wrote:

...

On Tue, Feb 1, 2022 at 12:00 PM Richard W.M. Jones <rjones@redhat.com> wrote:

...

I'm still struggling to get oVirt installed. It absolutely will not install on RHEL 8, the documentation here is flat out wrong:

https://www.ovirt.org/documentation/installing_ovirt_as_a_standalone_manager...

javapackages-tools is not a module that exists in RHEL 8. Apparently it's a CentOS PowerTools module.

It should exist in the RHEL 8 CodeReady Builder repository.

That did in fact work, thanks.

Would you like to file a doc bug about this? oVirt on RHEL is not such a common combination... In CI we only test on Centos Stream (8, hopefully soon also 9, we'll see), and RHV on RHEL. The documentation, if you check the source, is generated for both oVirt and RHV. I didn't check, but guess that only the RHV flow gets RHEL instructions re channels etc.

...

...

Since original CentOS no longer really exists either, does anyone have any opinions or experience with installing oVirt on any of:

- CentOS Stream 8

- Alma Linux 8.5

- Rocky Linux

Alma in particular looks like a straight replacement for old CentOS.

I've used CentOS Stream 8 reasonably okay for this, but AlmaLinux would work too.

I didn't actually try Alma, but I suspect we might have problems with ansible playbooks / random scripts which match "centos".

I didn't try it either, but we did fix a few relevant locations recently - most recent IIRC was: https://gerrit.ovirt.org/c/ovirt-engine/+/118229 We'll be happy to get success/failure (with details) reports of attempts to install/setup both engine and hosts on other OSes. Next step is probably for someone to try and build an oVirt node image based on a different OS...

I did build an alma-8.5 virt-builder template today though.

Perhaps I am missing something - is this oVirt-specific, or relevant? Thanks and best regards, -- Didi

you have 16 developer self support subscriptions from RH, those are more than enough to use with ovirt as a cluster/s.

you have 16 developer self support subscriptions from RH, those are more than enough to use with ovirt as a cluster/s.

I'd consider that an off-topic post. And whilst we are off-topic, one of the main attractions of using TrueCentOS (the downstream Community ENterprise Operating System) even when my employer has a fat Redhat support contract that covers everything I do, is that I just didn't have to bother with license management at all. It's a whole set of processes, activities and knowledge I could simply strike off the list and in the context of a lab environment with lots of machines and VMs getting created and deleted every day, that is a huge benefit. Well RHEL not supporting OpenVZ containers was another reason never to bother with it and why we ran CentOS userlands even in PCI-DSS production. I consider the benefit of zero license and subscription management still so significant, that I am rather investing into Alma, Rocky, Liberty, OracleLinux or VzLinux than dealing with RHEL. And BetaCentOS aka SomethingStream just isn't an acceptable match for a hypervisor or a management engine "for the entire enterprise": Beta is for the VMs, if your work is low-level, but 99% of what we do is application level or in fact the science above it, where Beta just adds work and risks without any benefit. Sorry for the rant, but posting stuff like that is asking for it.

Il giorno ven 4 feb 2022 alle ore 09:52 Thomas Hoberg <thomas@hoberg.net> ha scritto:

...

On Tue, Feb 1, 2022 at 7:55 PM Richard W.M. Jones <rjones(a)redhat.com> wrote:

Would you like to file a doc bug about this?

oVirt on RHEL is not such a common combination.. Well IBM seems bent on changing that (see the developer license post below)

In CI we only test on Centos Stream (8, hopefully soon also 9, we'll see), and RHV on RHEL. Which is exactly why BetaStreamOS (upstream to RHEL) based oVirt is breaking the value proposition of TrueCentOS (downstream of RHEL) based oVirt as a solution "for the entire enterprise".

AFAIK there is no "developer license" of RHV so if you want to run a lab environment where the experimentation is done at app or science level (not OS), this new beta(OS)-on-beta(VM orchestration) stack just becomes too fragile to use, not that oVirt HCI has ever proven better than hardware level fault resilience to me, which I believe was its design goal.

...

We'll be happy to get success/failure (with details) reports of attempts to install/setup both engine and hosts on other OSes.

I have been working on just that, going through Alma, Rocky and Oracle (RHEL, Liberty and VzLinux might be added) using a nested VMs on VMware for two scenarios: 1. Installing oVirt on a new hardware node (a CentOS8 VM switched to each new EL8 brand) 2. Switching a pre-existing oVirt HCI node to a new EL8 brand

In all cases the virtual hosts wind up running a single node HCI gluster, to keep things reasonable simple.

All of these worked fine,with some tiny glitches, but that was before the gluster8 repos got archived. Currently I am awaiting that being fixed to continue testing and hopefully posting a somewhat bigger report here.

But there is another new issue that bothers me quite a bit: The oVirt management appliance:

I managed to still get one of the latest CentOS8 based appliances during my tests and that could evidently be switched to one of the other EL8 variants, once the repo issues are sorted out.

But newer versions of the appliance are built on the UpStreamBeta, which cannot (easily?) be switched to a downstream EL8, while the RHEL appliance most likely can't be used legally.

Using a Beta engine without the RHEL benefit of vulnerability management is a no-go in PCI-DSS or similar compliance heavy environments, so for oVirt to be a "solution for the entire enterprise" there needs to be an EL8 based engine, too.

But AFAIK there is not even a publicly available build script for the appliance so someone outside RH could build a matching bot. And forced downgrades of the engine to one of the EL8 variants might well break the engine...

All the build scripts for oVirt Appliance are publicly available: https://github.com/oVirt/ovirt-appliance If you want to rebuild an appliance with Rocky instead of CentOS Stream you can just download this source then: - adjust repos in https://github.com/oVirt/ovirt-appliance/blob/master/engine-appliance/data/d... to math Rocky's - adjust makefile pointing to Rocky's boot iso in https://github.com/oVirt/ovirt-appliance/blob/master/engine-appliance/Makefi... - run make rpm.

...

Next step is probably for someone to try and build an oVirt node image based on a different OS... I would love trying (if I can find the time...), but I'm not sure where I could find build scripts...

For oVirt Node it's almost the same from https://github.com/oVirt/ovirt-node-ng-image adjusting repos in https://github.com/oVirt/ovirt-node-ng-image/blob/master/data/distro-defs.ym... and boot.iso in https://github.com/oVirt/ovirt-node-ng-image/blob/master/configure.ac#L46 or just passing it to configure command line. We have no capacity to build and test for all the variants but there's no secret on how to build node and appliance. I'm pretty sure I was discussing this with someone either on Alma or Rocky chat about a year ago and kindly asked to reach out to $preferred_distribution to build oVirt Node and ship it in their mirrors too.

One of the reasons I could never use these node images was that the 2.5Gbit USB Realtek driver is broken in EL7+EL8, which I used on my Atom based 3 node HCI. Building node images would allow adding drivers and putting in nested virt support...

...

Perhaps I am missing something - is this oVirt-specific, or relevant?

Thanks and best regards,

_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ELW5CNTXJNAZ4I...

-- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*