Hi Arman, the future of the oVirt project is in the hands of the community to be shaped. As Red Hat started the offboarding from the oVirt project about a year ago everyone saw the number of contributions lowering over the time. A good report about it is available here: https://cauldron.io/project/7653?from_date=2022-07-12&to_date=2023-07... I tried to contact known downstreams and about 20 universities and research labs known to be using oVirt to some extent over the past 10 years asking if they were interested in getting engaged with the project and offering help with the onboarding process but nobody stepped in over the past 2 years. I also tried engaging with the Virtualization SIGs of the distributions compatible with oVirt but nothing happened so far in that direction as well. We had several people, groups and companies announcing their intention to contribute to the project at conferences and on mailing lists but no real commitment so far. So, the current status is: when someone in the community has a problem and the capacity to prepare a fix, they submit it (we had very good examples from https://github.com/dupondje ) and whenever someone find the time to review and merge the patches they get into oVirt master snapshot builds. So the general suggestion is to switch to oVirt master snapshot in order to get the system working on the latest el8 / el9 as the last stable release is already known to have troubles. The project is not dead but it's for sure in a very low maintenance mode until someone will invest in its development. Il giorno mer 12 lug 2023 alle ore 13:24 Arman Khalatyan <arm2arm(a)gmail.com&gt; ha scritto: -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING - Red Hat In-Vehicle Operating System Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

We still have a few oVirt and RHV installs kicking around, but between this and some core features we use being removed from el8/9 (gluster, spice / qxl, and probably others soon at this rate) we've heavily been shifting gears away from both Red Hat and oVirt. Not to mention the recent drama... In the past we toyed around with the idea of helping maintain oVirt, but with the list of things we'd need to support growing beyond oVirt and into other bits as well, we aren't equipped to fight on multiple fronts so to speak. For the moment we've found a home with SUSE / Apache CloudStack, and when el7 EOL's that's likely going to be our entire stack moving forward. On 2023-07-13 02:21, eshwayri(a)gmail.com wrote: > I am beginning to have very similar thoughts. It's working fine for > me now, but at some point something big is going to break. I already > have VMWare running, and in fact, my two ESXi nodes have the exact > same hardware as my two KVM nodes. Would be simple to do, but I > really don't want to go just yet. At the same time, I don't want to > be the last person turning off the lights. Difficult times. > _______________________________________________ > 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/EJFIRAT6TNC...

I would personally put CloudStack in the same category as OpenStack. Really the only difference is monolithic vs micro services. Both scale quite well regardless, just different designs. People can weigh the pros and cons of either to figure out what suites them. CloudStack is certainly an easier thing to wrap your head around initially. There is also OpenNebula, similar to CloudStack in design. However their upgrade tool is closed source, so i can't recommend them as much as i would like to as i think they have a decent product otherwise. ProxMox currently doesn't work as an oVirt replacement for us as it cannot scale beyond a single cluster and has limited multi tenancy support. I hear they have plans for multi cluster at some point, but currently i regard it as more akin to ESXi without vSphere. Where oVirt i would have compared closer to ESXi with vSphere. I think XCP-ng has a bright future at the rate they are going, just doesn't currently supply all the features of oVirt. OKD (OpenShift) virtualization is more or less just kubevirt. If all you need vm's for is a few server instances, works well enough. Feature wise it's not comparable to everything above, but if you can live with your vm's being treated more or less like containers workflow / life cycle wise and don't need much more then that, it probably gets the job done. Harvester is another consideration if you think the OKD solution will work, but don't like the complexity. It's based on k3s, provides kubevirt, and is a much more simple install. I think they even provide an ISO installer. Reality is, there is no great oVirt replacement so to speak. If you only needed oVirt to manage a single cluster, ProxMox probably fits the bill. XCP-ng as well if you are willing to do some leg work. Otherwise closest FOSS thing i have found (spent over a year evaluating) is CloudStack. I am still hopeful someone will step up to maintain oVirt (Oracle?), but it's clear to me at this point it will need rebased onto Fedora or something else to keep it's feature set fully alive. On 2023-07-13 11:10, Volenbovskyi, Konstantin via Users wrote: > Hi, > We switched from Gluster to NFS provided by SAN array: maybe it was > matter of combination of factors (configuration/version/whatever), > but it was unstable for us. > SPICE/QXL in RHEL 9: yeah, I understand that for some people it is > important (I saw that someone is doing some forks whatever) > > I think that ovirt 4.5 (nightly build __) might be OK for some time, > but I think that alternatives are: > -OpenStack for larger setups (but be careful with distribution -as I > remember Red Hat abandons TripleO and introduces OpenShift stuff for > installation of OpenStack) > -ProxMox and CloudStack for all sizes. > -Maybe XCP-ng + (paid?) XenOrchestra, but I trust KVM/QEMU more than > Xen __ > OpenShift Virtualization/OKD Virtualization - I don't know... > Actually might be good if someone specifically comments on going from > ovirt to OpenShift Virtualization/OKD Virtualization. > > Not sure if this statement below > https://news.ycombinator.com/item?id=32832999 is still correct and > what exactly are the consequences of 'OpenShift Virtualization is just > to give a path/time to migrate to containers' > "The whole purpose behind OpenShift Virtualization is to aid in > organization modernization as a way to consolidate workloads onto a > single platform while giving app dev time to migrate their work to > containers and microservice based deployments." > > > > BR, > Konstantin > > Am 13.07.23, 09:10 schrieb "Alex McWhirter" <alex(a)triadic.us > <mailto:alex@triadic.us>>: > > > We still have a few oVirt and RHV installs kicking around, but between > this and some core features we use being removed from el8/9 (gluster, > spice / qxl, and probably others soon at this rate) we've heavily been > shifting gears away from both Red Hat and oVirt. Not to mention the > recent drama... > > > In the past we toyed around with the idea of helping maintain oVirt, > but > with the list of things we'd need to support growing beyond oVirt and > into other bits as well, we aren't equipped to fight on multiple fronts > so to speak. > > > For the moment we've found a home with SUSE / Apache CloudStack, and > when el7 EOL's that's likely going to be our entire stack moving > forward. > > > On 2023-07-13 02:21, eshwayri(a)gmail.com <mailto:eshwayri@gmail.com> > wrote: >> I am beginning to have very similar thoughts. It's working fine for >> me now, but at some point something big is going to break. I already >> have VMWare running, and in fact, my two ESXi nodes have the exact >> same hardware as my two KVM nodes. Would be simple to do, but I >> really don't want to go just yet. At the same time, I don't want to >> be the last person turning off the lights. Difficult times. >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org <mailto:users@ovirt.org> >> To unsubscribe send an email to users-leave(a)ovirt.org >> <mailto:users-leave@ovirt.org> >> Privacy Statement: https://www.ovirt.org/privacy-policy.html >> <https://www.ovirt.org/privacy-policy.html> >> oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> <https://www.ovirt.org/community/about/community-guidelines/> >> List Archives: >> https://lists.ovirt.org/archives/list/users@ovirt.org/message/EJFIRAT6TNC... >> <https://lists.ovirt.org/archives/list/users@ovirt.org/message/EJFIRAT6TNC... > _______________________________________________ > Users mailing list -- users(a)ovirt.org <mailto:users@ovirt.org> > To unsubscribe send an email to users-leave(a)ovirt.org > <mailto:users-leave@ovirt.org> > Privacy Statement: https://www.ovirt.org/privacy-policy.html > <https://www.ovirt.org/privacy-policy.html> > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > <https://www.ovirt.org/community/about/community-guidelines/> > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/EFBHZ76GZ73... > <https://lists.ovirt.org/archives/list/users@ovirt.org/message/EFBHZ76GZ73... > > > > _______________________________________________ > 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/O6KPWG3HA6I...

Largely package / feature support. RHEL is clearly betting the farm on OpenShift / OKD. Which is fine, but the decision to depreciate / remove things in RHEL (spice qxl, gluster) are also reflected in CentOS Stream. Even if you want to backport things to Stream as rebuilds of old / existing packages to re-enable some of those features you are now fighting a moving target. Would be easier to target RHEL than Stream if that is the goal. Fedora has no such depreciation of features, has a larger package library, and more room to grow oVirt into something more compelling. If the decision is made to base on CentOS Stream, might aa well base on Fedora instead as neither is going to have the full enterprise life cycle of RHEL and both will break things here and there. At least with Fedora you don't have to maintain an ever growing list of things to maintain to keep oVirt's feature set in tact. In short, targeting RHEL over Fedora made sense when CentOS existed as a downstream rebuild, when RHV was a product still, and when the entire oVirt feature set was supported by RHEL. None of those things are true today, and instead of targeting a psuedo RHEL where you still have to maintain a bunch of extra depreciated packages without the lifecycle commitment, Fedora makes more sense to me. My two cents anyways, for my use case not having Gluster or spice is a breaking change. While i wouldn't mind contributing to oVirt here and there as needed if someone picks up the pieces, i don't have the resources to also maintain the growing list of depreciated / cut features in the base OS. On 2023-07-14 02:27, Sandro Bonazzola wrote: Links: ------ [1] https://www.redhat.com/

Feel free to post patches to build oVirt on Fedora for example? What is needed for it? Is it a big change? Can't we just support FC and CS if the need is that high? The SPICE argument is a non-issue imo, there are already some people that rebuild the qemu packages for CS9 with SPICE enabled, which will then just work on oVirt afaik. Honestly, to me it looks like just another excuse to just not take things into your own hands and start fixing things/work on the project. Which I totally understand, but don't blame other things :) On 21/07/2023 08:43, Sandro Bonazzola wrote:

All, I'd rather base against either Rocky or Alma in the shorter term, or Ubuntu/Debian for a longer view. oVirt IMHO is a superior product to anything else if you know your way around it. Fantastic and informative GUI, a great set of APIs, and pretty solid in terms of storage support. I'm running it hyperconverged over ZFS+DRBD with Corosync and Pacecmaker in a 2 node cluster. I'm currently running a cluster on Rocky 8 and it's working perfectly at the moment. I'm not a fan of Gluster for its small I/O performance but I'm sure it's still a useful option for running VMs with heavy storage requirements with lesser small I/O performance requirements. Fedora would get you fired from a lot of SME or enterprise environments. And with the mess around IBM/RH who knows if they'll drop OpenShift next and pull the devs out of OKD?

Thanks Neal, your insight is very much appreciated. A lot of people forget about SuSE, but it's got the same ethos that RH had a few years ago, and it's worth looking into. I can imagine Fedora being a choice in CI/CD deployments but I'd be surprised is more old-fashioned companies would accept the risk. Going through a whole risk vs cost thing right now. It does seem that OpenShift is a potent platform, and pulling out of OKD would be a horrible mess, so here's hoping that if oVirt dies that OKD is a viable platform for both containers and Virtualisation (ah, legacy workloads!). It's just a shame that oVirt no longer has the sponsorship, I've been relentlessly ragged on on Reddit for admitting to using it (mostly from Hyper-V fanbois), but it's far, far better than Hyper-V and much less restrictive than VMWare. Hyper-V had me pulling my remaining hair out almost every single day. Five clicks to get the MAC address of a VM? Dynamic MAC addresses not being cluster-wide and pinned to a VM, so they change after a migration? Yuck. I will read that link now! Best regards Alex