> On Tue, Feb 1, 2022 at 7:55 PM Richard W.M. Jones <rjones(a)redhat.com&gt; 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...

> 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...

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/ELW5CNTXJNAZ4IS3ONMBDSQ7LFGQNGZI/