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 <tho...@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-manager-delivers-enhanced-monitoring-and-reporting > 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
_______________________________________________ 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/TLNHTDD4YBXWSIPJJSCJSJBPJFDTIG7I/
