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