> 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 _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/IJW6BMDO2VWSPPW2PLZVWSISDQ6ZMNV7/
