9:58 p.m.
To your question "Is it worth building a new virtualization platform based on
ovirt?" Sandro answered "currently there's no change in the Red Hat's
support of the oVirt project".
That may technically be true, but it doesn't really answer your question, I'd
believe.
oVirt is a management layer which has carried the motto "oVirt is a free open-source
virtualization solution for your entire enterprise" on its head page for years.
In my experience oVirt hasn't been nearly ready and stable enough to run an enterprise
workload, unless you are ready to maintain a fully redundant team of engineers to do QA on
all your use cases.
The CentOS base, however, has been enterprise quality, just as good as RHEL without the
extra hassle of registration servers: I don't think we ever rolled back an update in
over 10 years because it broke any of our workloads. And that was including OpenVZ on
dozens of machines and thousands of containers.
With oVirt 4.3 and CentOS 7 you knew which part you could trust and where to look for
errors (I found more than I believed possible).
With the de-facto elimination of CentOS as a functional RHEL clone, oVirt 4.4 becomes
upstream-on-upstream and you know how fault probabilities don't add but *multiply*
when you combine them.
With that you now need three QA teams, one for CentOS-Stream, one for oVirt and another
for the integration.
Not even oVirt 4.4 on RHEL 8 will be a proper choice, because that combination is also no
longer a part of what little test automation oVirt receives.
Only RHV on RHEL will be properly tested and CentOS/oVirt as a dev/QA/home/hobby ramp to
RHV/RHEL is lost.
And CentOS 8 seems to decay before they even switch to upstream. I've just done an
update on my single-node HCI oVirt 4.4 infrastructure the other day, which installed a new
kernel on the host (4.18.0-240.10.1.el8_3 vs. 4.18.0-193.19.1.el8_2). It turns out that
kernel broke VDO because of kernel/library mismatch caused by repository issues you'd
need to manually resolve, while VDO is a key ingredient to the HCI stack (error #1). VDO
is still treated as an "external" contribution I don't know how many years
after the aquisition. So on top of the mismatching userland and kernel versions, the VDO
module isn't signed (error #2), which can throw a wrench in your system if e.g. after
a BIOS update your system is reset to secure boot.
Error #1 should show on RHEL, too, unless CentOS is no longer downstream of RHEL already,
while error #2 indicates that the CentOS process is broken because VDO is only signed for
RHEL.
In other words, the "enterprise quality" of CentOS is already going up in smoke,
while CentOS8 isn't yet officially dead.
I might count myself lucky, that I haven't done the oVirt 4.4 migration of my HCI
clusters yet, mostly beacuse it's far from seamless, extremely risky and very
disruptive.
Now I just won't do that because oVirt 4.4/CentOS 8 is EOL this year, while CentOS 7
still has a couple of years left. By then, I'll hopefully have found a new home for
the non-production workloads I manage.
My hope of replacing the VMware production environment with a combination of oVirt and RHV
has been erased: My confidence that IBM will let oVirt will survive another ten years is
practically zero.
Redhat should know that nothing is as important as the size of the user base for software
to survive. oVirt/RHV's biggest chance would lie in everybody building their home
clusters using 3-node HCI running on Raspberry PI 4 nodes or Atoms... with seamless K8
integration.