3:43 a.m.
Redhat's decision to shut down RHV caught Oracle pretty unprepared, I'd guess, who
had just shut down their own vSphere clone in favor of a RHV clone a couple of years ago.
Oracle is even less vocal about their "Oracle Virtualization" strategy, they
don't even seem to have a proper naming convention or branding.
But they have been pushing out OV releases without a publicly announced EOL almost a year
behind Redhat for the last years.
And after a 4.4 release in September 22, a few days ago on December 12th actually a
release 4.5 was made public.
I've operated oVirt 4.3 with significant quality issues for some years and failed to
make oVirt 4.4 work with any degree of acceptable stability but Oracle's variant of
4.4 proved to be rather better than 4.3 on CentOS7 with no noticable bugs, especially in
the Hyperconverged setup that I am using with GlusterFS.
I assumed that this was because Oracle based their 4.4 in fact on RHV 4.4 and not oVirt,
but since they're not telling, who knows?
One issue with 4.4 was that Oracle is pushing their UE-Kernel and that created immediate
issues e.g. with VDO missing modules for UEK and other stuff, but that was solved easily
enough by using the RHEL kernel.
With 4.5 Oracle obviously can't use RHV 4.5 as a base, because there is no such thing
with RHV declared EOL and according to Oracle their 4.5 is based on oVirt 4.5.4, which
made the quality of that release somewhat questionable, but perhaps they have spent the
year that has passed since productively killing bugs... only to be caught by surprise
again, I presume, by an oVirt release 4.5.5 on December 1st, that no one saw coming!
Long story slightly shorter, I've been testing Oracle's 4.5 variant a bit and
it's not without issues.
But much worse, Oracle's variant of oVirt seems to be entirely without any community
that I could find.
Now oVirt has been a somewhat secret society for years, but compared to what's going
on with Oracle this forum is teaming with life!
So did I just not look around enough? Is there a secret lair where all those OV users are
hiding?
Anyhow, here is what I've tested so far and where I'd love to have some feedback:
1. Setting up a three node HCI cluster from scratch using OL8.9 and OV 4.5
Since I don't have extra physical hardware for a 3 node HCI I'm using VMware
workstation 17.5 on a Workstation running Windows 2022, a test platform that has been
working for all kinds of virtualization tests from VMware ESXi, via Xcp-ng and ovirt.
Created three VMs with OL8.9 minimal and then installed OV 4.5. I used the UEK default
kernels and then had an issue when Ansible is trying to create the (local) management
engine: the VM simply could not reach the Oracle repo servers to install the packages
inside the ME. Since that VM is entirely under the control of Ansible and no console
access of any type is possible in that installation phase, I couldn't do diagnostics.
But with 4.4 I used to have similar issues and there switching back to the Redhat kernel
for the ME (and the hosts) resolved them.
But with 4.5 it seems that UEK has become a baked-in dependency: the OV team doesn't
even seem to do any testing with the Redhat kernel any more. Or not with the HCI setup,
which has become deprecated somewhere in oVirt 4.4... Or not with the Cockpit wizard,
which might be in a totally untested state, or....
Doing the same install on OL 8.9 with OV 4.4, however, did work just fine and I was even
able to update to 4.5 afterwards, which was a nice surprise...
...that I could not repeat on my physical test farm using three Atoms. There switching to
the UEK kernel on the hosts caused issues, hosts were becoming unresponsive, file systems
inaccessible, even if they were perfectly fine at the Gluster CLI level and in the end the
ME VM simply would not longer start. Switching back to the Redhat kernel resolved things
there.
In short, switching between the Redhat kernel and UEK, which should be 100% transparent to
all things userland including hypervisors, doesn't work.
But my attempts to go with a clean install of 4.5 on a Redhat kernel or UEK is also facing
issues. So far the only thing that has worked was a single node HCI install using UEK and
OV 4.5 and upgrading to OV 4.5 on a virtualized triple node OV 4.4 HCI cluster.
Anyone else out there trying these things?
I was mostly determined to move to Proxmox VE, but Oracle's OV 4.5 seemed to be
handing a bit of a life-line to oVirt and the base architecture is just much more powerful
(or less manual) than Proxmox, which doesn't have a management engine.
7:46 a.m.
Thomas, your e-mail created too much food for thought... as usual I would
say, remembering the past ;-)
I try to reply to some of them online below, putting my own personal
considerations on the table
On Thu, Dec 21, 2023 at 11:44 AM Thomas Hoberg <thomas(a)hoberg.net> wrote:
Redhat's decision to shut down RHV caught Oracle pretty
unprepared, I'd
guess, who had just shut down their own vSphere clone in favor of a RHV
clone a couple of years ago.
I don't think so. I tried for quite some time their previous solution,
based on Xen, and simply it didn't work as expected in terms of many
enterprise class needed functionalities. Then I switched to oVirt and/or
RHV, depending on customer needs. And I think Oracle did the same. If I
remember correctly there was also a migration path.
Oracle is even less vocal about their "Oracle Virtualization" strategy,
they don't even seem to have a proper naming convention or branding.
I don't agree. Even if not crystal clear and somehow confusing for
newcomers, they called it Oracle Linux Virtualization Manager (OLVM) since
the beginning, making it clear that in their regard they see it as an
extension of the operating system (Oracle Linux). In fact if you buy the
Premier Support level of the OS, you automatically get also support for
OLVM. if you use it.
Their previous solution branding was Oracle VM (or sometimes Oracle VM
Server)
Here you can still find all the solutions described, including VirtualBox
(and recently Kata Containers):
https://www.oracle.com/virtualization/
But they have been pushing out OV releases without a publicly
announced
EOL almost a year behind Redhat for the last years.
In the past I asked and they told me that they planned to continue with
OLVM and its support even after RHV EOL.
And the 12th December announcement seems to confirm that.
Their product is a fork of oVirt.
And after a 4.4 release in September 22, a few days ago on December 12th
actually a release 4.5 was made public.
Great news, in my opinion
I didn't spot it yet, but you are right and here you can find the announce
page:
https://blogs.oracle.com/virtualization/post/oracle-linux-virtualization-...
I've operated oVirt 4.3 with significant quality issues for some
years and
failed to make oVirt 4.4 work with any degree of acceptable stability but
Oracle's variant of 4.4 proved to be rather better than 4.3 on CentOS7 with
no noticable bugs, especially in the Hyperconverged setup that I am using
with GlusterFS.
The whole point here is that in my opinion GlusterFS is totally not ready
for enterprise use, based on my past tests in oVirt context.
In other terms, possibly the problems you are describing was more dependant
on GlusterFS configuration/tuning/bugs than on oVirt/OLVM versions
themselves
Just my opinion
I assumed that this was because Oracle based their 4.4 in fact on RHV
4.4
and not oVirt, but since they're not telling, who knows?
I don't think that. Based on licensing they have to let their sources
publicly available.
And in fact here you find all you need in case you want to crosscheck:
https://yum.oracle.com/oracle-linux-8.html
In the link above you can find both 4.4 and 4.5 sources, together with the
OS and UEK kernels ones, because as said above, they consider OLVM an
extension of the operating system functionalities
One issue with 4.4 was that Oracle is pushing their UE-Kernel and
that
created immediate issues e.g. with VDO missing modules for UEK and other
stuff, but that was solved easily enough by using the RHEL kernel.
They support both Red Hat Compatible kernels and UEK ones. In case of
problems I think you can submit bugs.
The correct entry point for that for not paying customers should be this
one if I'm not wrong:
https://github.com/oracle/oracle-linux/issues
With 4.5 Oracle obviously can't use RHV 4.5 as a base, because there is no
such thing with RHV declared EOL and according to Oracle their 4.5 is based
on oVirt 4.5.4, which made the quality of that release somewhat
questionable, but perhaps they have spent the year that has passed since
productively killing bugs... only to be caught by surprise again, I
presume, by an oVirt release 4.5.5 on December 1st, that no one saw coming!
I think you well understand that sw developer processing is not an easy
one, and that it comprises feature freezes and such...
If Oracle well before planned to come out with a 4.5 release based on a
fork of a well established 4.5.4 release, it is not so important to rebase
all the work on the just released oVirt 4.5.5. They had better release it
anyway after their quality testing and then update inside the normal
maintenance phase. And based on what oVirt 4.5.5 contains, it could be that
some of oVirt 4.5.5 features/fixes are already there in OLVM 4.5
At the moment, from release notes we know that:
"
Release 4.5 of Oracle Linux Virtualization Manager is based on oVirt
community release version 4.5.4, which includes a number of bug fixes and
support for new features:
"
Long story slightly shorter, I've been testing Oracle's 4.5
variant a bit
and it's not without issues.
Please report them, eventually both here and in the github link above.
But much worse, Oracle's variant of oVirt seems to be entirely without any
community that I could find.
Here I totally agree with you. They have specific forums but not so well
organized, at least for OLVM related problems.
And also here in this list they didn't give much information regarding
roadmaps and nothing regarding their just released 4.5 OLVM (if I didn't
miss it).
Now oVirt has been a somewhat secret society for years, but compared
to
what's going on with Oracle this forum is teaming with life!
I don't understand what you mean here. As said many times it has always
been a Red Hat sponsored open source project (with almost only Red Hat paid
developers working on it) and a base for their commercial offering of RHV.
Something similar to OKD for OCP, RDO for OSP, ...
[snip]
But with 4.5 it seems that UEK has become a baked-in dependency: the OV
team doesn't even seem to do any testing with the Redhat kernel any more.
Or not with the HCI setup, which has become deprecated somewhere in oVirt
4.4... Or not with the Cockpit wizard, which might be in a totally untested
state, or....
If it is so, it is a bug, because inside the release notes of 4.5, for both
the Engine Host and the Hypervisor Host there is clearly stated that the
requirement is:
"
Unbreakable Enterprise Kernel Release 6, Unbreakable Enterprise Kernel
Release 7, or Red Hat Compatible Kernel
"
I didn't go through all the documentation but I didn't find any information
regarding Red Hat Compatible Kernel being deprecated.
Please point me to it if you have one.
Doing the same install on OL 8.9 with OV 4.4, however, did work just
fine
and I was even able to update to 4.5 afterwards, which was a nice
surprise...
In theory paying customers are expected to be able to upgrade from OLVM 4.4
to 4.5. So it should not be a surprise.
...that I could not repeat on my physical test farm using three Atoms.
There switching to the UEK kernel on the hosts caused issues, hosts were
becoming unresponsive, file systems inaccessible, even if they were
perfectly fine at the Gluster CLI level and in the end the ME VM simply
would not longer start. Switching back to the Redhat kernel resolved things
there.
Again: I don't consider GlusterFS ready for prime time enterprise customers
in the virtualization context.
And also the GlusterFS support community, when required in the past, was
not able to provide timely support, unfortunately
Why do you think they only support Ceph in both OCP and OSP?
See also here their support for their Gluster based commercial product
(RHGS aka Red Hat Gluster Storage):
https://access.redhat.com/articles/2356261
only supported for RHV and OCP only up to version 3. no support for OCP 4.
https://access.redhat.com/articles/3403951 (this one requires login)
But again, it is only my opinion
In short, switching between the Redhat kernel and UEK, which should be
100% transparent to all things userland including hypervisors, doesn't work.
What are the technical considerations that let you argue that swapping from
a RH EL 8.9 kernel (based on upstream 4.18 + backports) to an UEK R7 one
(based on upstream 5.15) should be totally transparent? And considering
also that KVM, at the base of the hypervisor functionalities, is a kernel
module?
Perhaps you are oversimplifying a bit
But my attempts to go with a clean install of 4.5 on a Redhat kernel or
UEK is also facing issues. So far the only thing that has worked was a
single node HCI install using UEK and OV 4.5 and upgrading to OV 4.5 on a
virtualized triple node OV 4.4 HCI cluster.
Anyone else out there trying these things?
Unfortunately I changed my job and I'm not so active in the context of
oVirt and its variants at the moment
I can try in a lab used for other things and report back, anyway, if I have
time.
Good news you have informed the community and that there is this possible
choice now
I was mostly determined to move to Proxmox VE, but Oracle's OV
4.5 seemed
to be handing a bit of a life-line to oVirt and the base architecture is
just much more powerful (or less manual) than Proxmox, which doesn't have a
management engine.
I never worked with Proxmox, so I have no opinion here.
Gianluca
6:42 p.m.
Thomas, your e-mail created too much food for thought... as usual I
would
say, remembering the past ;-)
I try to reply to some of them online below, putting my own personal
considerations on the table
Hi Gianluca, nice to meet you again!
On Thu, Dec 21, 2023 at 11:44 AM Thomas Hoberg
<thomas(a)hoberg.net> wrote:
I don't think so. I tried for quite some time their previous solution,
based on Xen, and simply it didn't work as expected in terms of many
enterprise class needed functionalities. Then I switched to oVirt and/or
RHV, depending on customer needs. And I think Oracle did the same. If I
remember correctly there was also a migration path.
Xen is in dire straits.
Which is a shame, given its history and its sometimes unique qualities e.g in the area of
Library operating systems...
The biggest technical issue I see is x86 architecture deficits, but in the mean-time
it's simply eco-system size and some choices like OCAML that have turned into one big
technical debt that nobody is going to pay.
I think the Xcp-ng guys are heros, on older (supported) hardware Xcp-ng runs like a charm,
but there are on an extiction branch of virtualization evolution.
I don't agree. Even if not crystal clear and somehow confusing for
newcomers, they called it Oracle Linux Virtualization Manager (OLVM) since
the beginning, making it clear that in their regard they see it as an
extension of the operating system (Oracle Linux). In fact if you buy the
Premier Support level of the OS, you automatically get also support for
OLVM. if you use it.
Their previous solution branding was Oracle VM (or sometimes Oracle VM
Server)
Here you can still find all the solutions described, including VirtualBox
(and recently Kata Containers):
https://www.oracle.com/virtualization/
Not a fight I want to pick, but Google fails me.. and I don't think it's
Google's fault
In the past I asked and they told me that they planned to continue with
OLVM and its support even after RHV EOL.
And the 12th December announcement seems to confirm that.
Their product is a fork of oVirt.
Without a roadmap and committed life cycles,
nothing is a product.
And with oVirt lacking both, Oracle's "fork relation" is nothing to build
on.
Great news, in my opinion
I didn't spot it yet, but you are right and here you can find the announce
page:
https://blogs.oracle.com/virtualization/post/oracle-linux-virtualization-...
It breathes life into what is potentially a carcass with lots of potential... But
for how long?
The whole point here is that in my opinion GlusterFS is totally not ready
for enterprise use, based on my past tests in oVirt context.
In other terms, possibly the problems you are describing was more dependant
on GlusterFS configuration/tuning/bugs than on oVirt/OLVM versions
themselves
Just my opinion
It was Redhat who spread the fiction of GlusterFS as the one
solution without any scaling limits.
Your opinion seems to resonate even with Redhat, who decided to discontinue any commercial
product based on GlusterFS.
But I need HCI, and Redhat/Oracle/oVirt isn't providing an [integrated] alternative.
Ceph seems ok for that, but nobody is working on instrumentation.
I don't think that. Based on licensing they have to let their sources
publicly available.
And in fact here you find all you need in case you want to crosscheck:
https://yum.oracle.com/oracle-linux-8.html
In the link above you can find both 4.4 and 4.5 sources, together with the
OS and UEK kernels ones, because as said above, they consider OLVM an
extension of the operating system functionalities
I've round Oracle Linux
sources on Githubu, but their fork of oVirt is nowhere to be found...
They support both Red Hat Compatible kernels and UEK ones. In case of
problems I think you can submit bugs.
The correct entry point for that for not paying customers should be this
one if I'm not wrong:
https://github.com/oracle/oracle-linux/issues
I've seen that, and it looks like
it's being monitored. But the equivalent for oVirt or OV is missing!
I think you well understand that sw developer processing is not an easy
one, and that it comprises feature freezes and such...
If Oracle well before planned to come out with a 4.5 release based on a
fork of a well established 4.5.4 release, it is not so important to rebase
all the work on the just released oVirt 4.5.5. They had better release it
anyway after their quality testing and then update inside the normal
maintenance phase. And based on what oVirt 4.5.5 contains, it could be that
some of oVirt 4.5.5 features/fixes are already there in OLVM 4.5
At the moment, from release notes we know that:
"
Release 4.5 of Oracle Linux Virtualization Manager is based on oVirt
community release version 4.5.4, which includes a number of bug fixes and
support for new features:
"
I'd be more than happy with QA lasting a year: I'm not going to
deploy leading edge hardware for hosting VMs. What I still need is a roadmap and
comittment.
Please report them, eventually both here and in the github link above.
I'll
try, but I'd really need the oVirt equivalent.
One of the negative experiences here has been that any issue that was KVM, Gluster, VDO,
Ansible, Cockpit or just RHEL wasn't dealt with here: they were entirely focused on
oVirt and just what *was* oVirt wasn't immediately recogniseable to a newcomer.
And in a *product* it should not matter anyway...
Here I totally agree with you. They have specific forums but not so well
organized, at least for OLVM related problems.
And also here in this list they didn't give much information regarding
roadmaps and nothing regarding their just released 4.5 OLVM (if I didn't
miss it).
Not so much an understatement we don't see any more from the likes of
a Boris Johnson or a Nigel Farage...
I'd say "total information blackout" seems a better fit!
I don't understand what you mean here. As said many times it has always
been a Red Hat sponsored open source project (with almost only Red Hat paid
developers working on it) and a base for their commercial offering of RHV.
Something similar to OKD for OCP, RDO for OSP, ...
Considering that Oracle's
oVirt is an oVirt fork and they are at least referencing oVirt on their web-site: there
has been zero participation of Oracle on this forum.
It's a critique purely aimed at Oracle, certainly not at the Redhat guys doing most of
the oVirt work!
If it is so, it is a bug, because inside the release notes of 4.5, for both
the Engine Host and the Hypervisor Host there is clearly stated that the
requirement is:
"
Unbreakable Enterprise Kernel Release 6, Unbreakable Enterprise Kernel
Release 7, or Red Hat Compatible Kernel
"
I didn't go through all the documentation but I didn't find any information
regarding Red Hat Compatible Kernel being deprecated.
Please point me to it if you have one.
That's just it: to my understanding the
100% interface compatibility has been a major UEK selling point, personally underlined
(and signed in blood) by Wim Coekaerts.
That's why I was quite annoyed to find that switching kernels wasn't transparent
and that one of the first things I discovered upon trying to migrate from oVirt 4.3 to OV
4.4 failed for lack of VDO support.
Even Oracle's RHEL kernels sometimes failed to keep VDO support working, which created
huge issues as I was blindly applying patches around Christmas 2022 or 2021: I don't
tend to forget having to undo updates when I should be singing Christmas carols with my
kids!
Again, what I need is an OV community on top of UEK.
In theory paying customers are expected to be able to upgrade from OLVM 4.4
to 4.5. So it should not be a surprise.
Should even apply to non-paying ones, like
me!
Again: I don't consider GlusterFS ready for prime time enterprise customers
in the virtualization context.
And also the GlusterFS support community, when required in the past, was
not able to provide timely support, unfortunately
Why do you think they only support Ceph in both OCP and OSP?
See also here their support for their Gluster based commercial product
(RHGS aka Red Hat Gluster Storage):
https://access.redhat.com/articles/2356261
only supported for RHV and OCP only up to version 3. no support for OCP 4.
https://access.redhat.com/articles/3403951 (this one requires login)
But again, it is only my opinion
To me it's one of the pretty near 'criminal' offenses of oVirt: they
advertised oVirt as a solution "for your entire enterprise" and that included
HCI (using GlusterFS as the *only* storage based for that).
It took me years to understand that the Israeli KVM, SPICE and oVirt teams originally
launched by Moshe Bar would not look or comment on any issue cause by KVM, VDO, Ansible,
GlusterFS or just Linux, because it was outside their "purvue": how would anyone
who hat just followed the promising jargon on the oVirt home-page know what's from
which Redhat acquisition?
GlusterFS was a miracle in terms of limitless scaling nad oVirt HCI integration... until
you had an issue or it was siltently sidelined.
That may not have been an oVirt team decision, but imagine Linus Torvalds suddenly
disowning file systems or claiming that any virus or trojan propagating via Linux APIs
wasn't his responsability, unless you paid him personally to make it that.
Open source is built on trust and if you don't take your responsibility seriously, the
damage to the eco-system is "significant" to say the least.
Redhat under IBM leadership has made some significantly bad turns.
What are the technical considerations that let you argue that swapping from
a RH EL 8.9 kernel (based on upstream 4.18 + backports) to an UEK R7 one
(based on upstream 5.15) should be totally transparent? And considering
also that KVM, at the base of the hypervisor functionalities, is a kernel
module?
Perhaps you are oversimplifying a bit
Perhaps I do, but the marketing around UEK is
that it's the same, only much better.
Just as Redhat promises API backward compatibility for any major release kernel, UEK
promises that UEK is like the Redhat kernel, "only better". That's Wim's
message, not mine.
Admittedly it's been a few years since I heard it from his own mouth and we shook
hands on it (and he also left Oracle for some time in-between), but I consider that as
much of a guarantee poured into concrete as you'd ever get in IT.
Unfortunately I changed my job and I'm not so active in the context of
oVirt and its variants at the moment
I can try in a lab used for other things and report back, anyway, if I have
time.
Good news you have informed the community and that there is this possible
choice now
More than happy to have done so and I'll continue my testing as
well: I really do wish oVirt well, even with all the huge disappointments I've lived
through with it.
I have kids, disappointments and loyalty somehow do not seem to correlate.
I never worked with Proxmox, so I have no opinion here.
It is much, much simpler,
very straight forward and it just works. Albeit with its functional limitations.
It's extremely quickly to set up and operate and the main magic is in KVM and QEMU, so
it can't be bad and a week-end may be sufficient to explore it rather well.
Gianluca
Ciao e vi auguro un meraviglioso Natale!
Thomas
11:56 a.m.
Hi,
Definitely surprising news.
What I am very curious about: I could not find any mention of managed block
storage with Ceph in Oracles documentation.
We are currently using that in our Ovirt 4.5.5 cluster and seeing Oracle
releasing something gives me hope that our issues with it may be fixed and we
would not need to migrate to a different solution.
--
Julian Fölsch
Arbeitsgemeinschaft Dresdner Studentennetz (AG DSN)
Tel.: +49 351 271816 69
E-Mail: julian.foelsch(a)agdsn.de
Studentenrat der TU Dresden
Helmholtzstr. 10
01069 Dresden
8:01 a.m.
Hi Julian,
As far as I know, Ceph with managed block storage is not supported by
oVirt...
Out of curiosity, did you use any documentation? Can you briefly describe
us or give us a step-by-step guide on how you did the configuration? This
interests me a lot.
I would like to use managed block storage here.
Cheers!
Em qua., 27 de dez. de 2023 às 06:16, <paktosan(a)wh12.tu-dresden.de>
escreveu:
Hi,
Definitely surprising news.
What I am very curious about: I could not find any mention of managed
block
storage with Ceph in Oracles documentation.
We are currently using that in our Ovirt 4.5.5 cluster and seeing Oracle
releasing something gives me hope that our issues with it may be fixed and
we
would not need to migrate to a different solution.
--
Julian Fölsch
Arbeitsgemeinschaft Dresdner Studentennetz (AG DSN)
Tel.: +49 351 271816 69
E-Mail: julian.foelsch(a)agdsn.de
Studentenrat der TU Dresden
Helmholtzstr. 10
01069 Dresden_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/DHR3DJT6M7H...
--
Att,
Jorge Visentini
+55 55 98432-9868
3:33 a.m.
Hi,
Am Mittwoch, 27. Dezember 2023, 16:01:49 CET schrieb Jorge Visentini:
Hi Julian,
As far as I know, Ceph with managed block storage is not supported by
oVirt...
During Engine installation, you are asked if you want to enable Cinderlib
(this is in Technology Preview)
Out of curiosity, did you use any documentation? Can you briefly
describe
us or give us a step-by-step guide on how you did the configuration? This
interests me a lot.
High level "documentation" is available in a design
document[0].
More concrete examples are given in a blog post[1].
I would like to use managed block storage here.
As it stands
right now, Cinderlib is usable but has some issues with VM
migration where vdsm has some false assumptions about state.
In my opinion, if we see any meaningful development of ovirt or its forks
again, Cinderlib and Ceph would be the big features that can keep the software
relevant for the future.
[0] https://www.ovirt.org/develop/release-management/features/storage/
cinderlib-integration.html
[1] https://blogs.ovirt.org/2021/07/using-ceph-only-storage-for-ovirt-datacen...
--
Julian Fölsch
Arbeitsgemeinschaft Dresdner Studentennetz (AG DSN)
Tel.: +49 351 271816 69
E-Mail: julian.foelsch(a)agdsn.de
Studentenrat der TU Dresden
Helmholtzstr. 10
01069 Dresden
7:20 p.m.
In theory, if oVirt supports it, the Oracle variant would do it to... unless they manage
to break it.
And since there is zero information on what they test, that could happen at any time.
Same for HCI with GlusterFS or VDO. HCI has been removed as "a tested feature",
but if you use the Cockpit GUI, it will just continue to work quite happily. I haven't
actually tried it in combination with VDO, though.
I've used oVirt deployed Gluster storage in Proxmox w/o any issue and I'm tempted
to do the opposite, too (use Proxmox provided Ceph storage in oVirt).
oVirt is all abstractions, so it *should* work. But until somebody actually tests,
validates and fixes it (if necessary), it's simply a house of cards that can break
with every change.
Ich würde meine Hoffnungen nicht allzu hoch schrauben, momentan sehe ich das Projekt quasi
dank seines Trägheitsmoments weiter laufen, aber ohne daß jemand das so richtig treibt
oder gar Budget bereithält... was ausgesprochen schade ist, denn da steck eine riesige
Menge Arbeit und weit mehr Potential (für die Anwender, weniger für die Hersteller) drinn.
10:14 p.m.
If Oracle is smart they would poach all the oVirt programmers from IBM and take the lead
in development. With Broadcom destroying VMWare, we are in a real need for an alternative
to Xen and Proxmox. I wouldn't have included Proxmox a few months ago, but at least
it's being actively developed.
1:51 p.m.
In the future... maybe...
https://harvesterhci.io/
Em qua., 3 de jan. de 2024 às 02:14, <eshwayri(a)gmail.com> escreveu:
If Oracle is smart they would poach all the oVirt programmers from
IBM and
take the lead in development. With Broadcom destroying VMWare, we are in a
real need for an alternative to Xen and Proxmox. I wouldn't have included
Proxmox a few months ago, but at least it's being actively developed.
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/KSMO32EJKM6...
--
Att,
Jorge Visentini
+55 55 98432-9868
1:37 p.m.
Oracle employee here, don't be surprised if you see an uptick in development activity,
with the changes going in the virtualization market. That is all I can say.
8:06 a.m.
Chance of a reprieve perhaps?
On 12/03/2024 19:37, itsavant(a)gmail.com wrote:
> Oracle employee here, don't be surprised if you see an uptick in development
activity, with the changes going in the virtualization market. That is all I can say.
> _______________________________________________
> Users mailing list -- users(a)ovirt.org
> To unsubscribe send an email to users-leave(a)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/VRTWU65BRXL...
6:58 a.m.
Hi all,
The one big question I have, is: is Oracle contributing back to oVirt or
do they plan to do so?
It seems there are still some talented people working on both, so why
not pool that talent?
Best
Alex
7:56 a.m.
oVirt isn't exactly a trivial piece of software.
Actually I'd say it's not even a piece of software, as the integration of the
various companies whose fully independent products now make up oVirt, never fully
happened.
oVirt is Redhat Linux, Qumranet (KVM+Spice), Ansible (Ansible), GlusterFS (Z Research),
VDO (Permabit), and I don't know how many others, and you currently need knowledge,
perhaps even control over all of them to deliver the product.
Oracle has somewhat duplicated RHEL and oVirt, but even for those two components I
don't see how they could continue them without the upstream project.
RHEL isn't going away very soon, but you've all watched the CentOS battle and how
Redhat is turning [IBM] blue.
VDO has been upstreamed, the fate of Gluster isn't publicly known but without a
commercial product earning some revenue, it just can't survive for long.
And all this is in a niche that even with Broadcom raising the stakes high enough to cause
a stampede, is going up in clouds, unless the political fragmentation of the IT space
becomes much, much stronger.
oVirt needs a strong sponsor, but anyone but IBM making big bucks from oVirt cannot
happen, because Redhat has both means and motivation to block that.
Of course, that's just me thinking aloud and I could be all wrong...
8
days inactive
138
days old
12 comments
8 participants
participants (8)
-
Alex Crow -
eshwayri＠gmail.com -
Gianluca Cecchi -
itsavant＠gmail.com -
John -
Jorge Visentini -
paktosan＠wh12.tu-dresden.de -
Thomas Hoberg