Oracle Virtualization Manager 4.5 anyone?
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.
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@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-man...
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
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
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@agdsn.de Studentenrat der TU Dresden Helmholtzstr. 10 01069 Dresden
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@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@agdsn.de
Studentenrat der TU Dresden Helmholtzstr. 10 01069 Dresden_______________________________________________ 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/DHR3DJT6M7H2V5...
-- Att, Jorge Visentini +55 55 98432-9868
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-datacenter... -- Julian Fölsch Arbeitsgemeinschaft Dresdner Studentennetz (AG DSN) Tel.: +49 351 271816 69 E-Mail: julian.foelsch@agdsn.de Studentenrat der TU Dresden Helmholtzstr. 10 01069 Dresden
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.
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.
In the future... maybe... https://harvesterhci.io/ Em qua., 3 de jan. de 2024 às 02:14, <eshwayri@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@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/KSMO32EJKM62KN...
-- Att, Jorge Visentini +55 55 98432-9868
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.
Chance of a reprieve perhaps? On 12/03/2024 19:37, itsavant@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@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/VRTWU65BRXLICC...
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
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...
participants (8)
-
Alex Crow -
eshwayri＠gmail.com -
Gianluca Cecchi -
itsavant＠gmail.com -
John -
Jorge Visentini -
paktosan＠wh12.tu-dresden.de -
Thomas Hoberg