> On Tue, Feb 15, 2022 at 8:50 PM Thomas Hoberg <thomas(a)hoberg.net> wrote: > > For quite some time, ovirt-system-tests did test also HCI, routinely. > Admittedly, this flow never had the breadth of the "plain" (separate > storage) flows.
I've known virtualization from the days of the VM/370. And I immediately ran and bought the very first VMware [1.0] product, when they did this nice trick of using the SMM and binary translation to implement a hypervisor on an architecture that excluded VM (except the virtual 8086) [IMHO] on purpose. I did follow the hypervisor wars, but settled on OpenVZ because it delivered compliance, which wasn't firmly established for hypervisors at the time and much better consolidation. Redhat then took a very arrogant stance against containers at the time, perhaps because Parallels (OpenVZ) and LXC (Canonical) were competitors or simply because it had just "won" with Qumranet/KVM against Citrix/Xen: I could not convince my Redhat contacts that it wasn't an either/or choice, but that both approaches were complimentary. Well SuSE didn't listen either, nor did Oracle for that matter. It took Docker to break that lose and it took Google brushing up their let-me-containerise-that into Kubernetes to burn Redhat into action and ditch their first OpenShift (sorry, if I don't remember every detail). Nobody had a perfect grasp of where things were going nor the perfect product offer and there was quite a lot of politics involved as well: not every decision was based on technical merit. I came back to VM orchestration because I went from compliance driven production architecture to supporting our research labs, which needed GPU support for ML and the ability to run set of PoC machines, both stable and without (compliance oriented) production support teams. They also needed transportable setups, that could be shipped around the world and operated without local support. oVirt offered a turn-key HCI solution with a reasonable minimum of three nodes, which could be scaled up or out within one or two orders of computing power magnitude. Any single fault could reasonably survive a day or week-end, until a spare box could be obtained locally and put in place. Even a double fault wouldn't necessarily result in a complete loss or shutdown, just a define minimal operations mode, ready for self-recovery, once the hardware was replaced: so perfect, in theory, I was positively in love... That love is at the root of my current disillusionment, for sure, but it was you who showed the "entire enterprise" t*ts! At the same time it offered the ability grow into something much bigger with dedicated storage (and skills), because I understood well enough, that you won't run a cloud on HCI. oVirt was like a hybrid car and could run on batteries or fuel. Most importantly it offered running things in a "labs mode" using oVirt and CentOS and in a "production mode" using RHEL and RHV, so if one of your prototypes got customers, we could just switch it over to our production teams who know how to handle auditors looking into every nook and cranny. So the hybrid car could have air-bags and ESP all around for the Autobahn, or sand buggies in the dunes. These four options are gone now, rather suddenly and with little warning; there is only one variant left, which is in full metamorphosis. It's no longer hybrid, HCI is gone. And there is no longer a choice between a compliant safe version and the devil-may-care agile variant, that won't always run after every change and close any vulnerability before the cyberwar reaches you. OpenShift with kubevirt may well point much better in the direction of where the industry is going, but it's far from the turnkey fault resilient set of boxes, which you could just put everywhere and have fixed by people who'd just unpack a replacement box and rewire three cables, letting the HCI cluster heal itself. It's also a complete inversion where etcd runs VMs as if they were containers while oVirt ran VMs, ...that might have containers in them. And that may be a good thing to have, for those who want that. And that even includes me and my company, who is running OpenShift on RHEL in the big data centers. It's just that for the labs and in the field, this doesn't fit, an HCI setup is what we need below, while we'll happily run OpenShift and (nested) kubevirt on top, to ensure our software is keeping with the times as it evolves. Now that it's finally in the open that 3/4 oVirt/RHV/HCI options are gone, I'd like to help those who like me need one or three of them for their business. You should help and support that, because you shouldn't want happy oVirt'lers to be stranded and potentially angry. There isn't even an issue of competition any more, because the Xen guys aren't selling Kubernetes, just running that, with CoreOS, RHEL or whatnot inside VMs. > oVirt and Gluster teams did work in cooperation. > I am not sure that Nir's statement is actually that significant. It > clarifies more the organizational structure within Red Hat than the > intended quality of all relevant projects (and products). You can see > Red Hat's lifecycle pages for the relevant products to see Red Hat's > plans for them. > > I think it was already clear, but if not, clarifying: From Red Hat's > POV, the replacement of Gluster is Ceph, and the replacement of oVirt > is kubevirt/OpenShift Virtualization/OKD Virtualization. This > definitely does not mean that oVirt is intended to die - on the > contrary - quite a lot of what we did in recent months was in order to > make it easier to allow oVirt to survive after Red Hat's involvement > diminishes. Please put that on the home page, update the Wikis, tell the story. It's not a bad story, it's just a complete rewrite of the original book as a vSphere inspired Open Source blend. And I'd love to have an open discussion about why oVirt couldn't also be *the* HCI solution that everybody has at home running on three Raspberry PI for a bullet proof home edge. Better yet: How can it become that going forward? > > > Agreed. > > Best regards, _______________________________________________ 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/LLCYMVWNC6F5E4RYIOSKNGI7Z3D4GLLA/
