@scottalanmiller said in Testing oVirt...:
And in that use case it makes sense. But since then, they've changed their official message and now it fails pretty hard at the thing that it claims to be.
Are you sure it's the message and not they way you perceive what it says?
I was aware of oVirt and avoiding it in those days because it met no need I would run into anywhere. It was off the radar. But they've gotten enough attention, and changed what their claim their use case to be, so it seemed like they had broadened their use cases and were ready for much more common use cases. But appears to just be disingenuous marketing.
What they added was integration with a bunch of projects - several openstack modules, OVN, Foreman, Ansible etc. The main concept and the sweetspot for the use case remains the same. However, with these integrations, you can share the deployment, which I've done quite a lot of. Deploy RHV and Openstack side by side, let openstack deal with the cloud-oriented use cases and RHV deals with the more old fashioned non-ephemeral workloads (e.g. run the company's AD and Exchange), all under the same SDN provided by Neutron, and image store on Cinder etc. Again, a specific use-case, but there are no generic ones out there.
The issue being... when testing for either how we'd want something in the majority of use cases or how it is stated as being intended to be used how do we evaluated oVirt - and judging against all reasonable expectations, it falls very short. It is extremely limited
and again - the majority of what usecases? Where did you get the statistics, can you prove that that is the majority?
The classic virtualized DC was always run on shared storage. Live migration and HA don't make sense without it.
This is only true if you define "how it is intended" after the fact.
No, that is what you are doing here. You defined your own use case, which doesn't match oVirt's, and then you claim that is the "enterprise" and the "majority" use case. Without providing any proof. oVirt was designed to cover the pretty standard virtualized DC use case, that's a bunch of hypervisors using shared storage and providing VM HA and other features around that. That isn't a "niche" use case, it's quite common, from SMBs to large enterprises. Of course distributed workloads with local storage and N replicas on every node don't fit that bill, but those are niche, and should be run on specialized management systems. When I want to run my standard company infrastructure, e.g. my email servers, directory, file dumps and the like, I'll pick a solution that fits. Now please tell me how those are niche and uncommon, and should be using local storage because they are so latency-sensitive.
Not in the real world. SAN is a legacy technology in nearly all use cases, even in the enterprise. Common, yes. But mostly because salesman drive more sales than IT decision making does.
Right. Because you say so, as the "ultimate authority". HC has flunked as much as VDI did. SDS solutions are also a maintenance nightmare. SANs are old, clunky and damn expensive, but they work well, and THAT is the reason they are still being sold.
You made up that use case based on the limitations. It's so limited that you had to make a use case specifically to address them.
No, you made up the use case, and you base the limitations on it (btw, what are the limitations? You keep failing to actually state them).
You are setting your expectations by what the product does, not what it is supposed to do and/or by what the thread asked about it.
No, I set the expectations, then came up with the product. Remember, I was there when oVirt wasn't even oVirt yet. There was plenty of market research done, and weeks spent in customer meetings defining what they would like to see as a replacement for vmware.
Because it requires Gluster and/or remote storage. It doesn't offer straight local (highest performance) or high performance local cluster options.
So you are saying SAN performance cannot be high? Have you heard of this very new tech called "fibre channel" or this even newer one called "SSD"? How about infiniband? You're in for a surprise!
we see shops running databases
- databases have resided on SANs since the 80s, never been a problem
- virtualization usually is the factor that slows a db down much more than good storage ever could.
- you just brought in a niche use case (databases) and are trying to show it is the one and only common use case for a virtualization management system to be the wrong choice. Well, of course it is the wrong choice, a distributed NoSQL would be best on baremetal with local disks, with as much CPU and RAM as it can have. An old monolith SQL would also be best served on baremetal, and with fast local or remote disks attached. For the classical failover to work, that would need to be shared storage. SQL replication and sharding are a nightmare, but that's also besides the point. As you can see, a virtualization system such as oVirt isn't even mentioned in the use case.
The most important definition of enterprise workloads would include "broad disparity in needs." Something that "only good for a niche" solutions of any type can't fulfill when looking for a central, unified option.
That's as good as saying "I have no answer". Don't evade, just describe your use case, or even better - give me an example of a system that can manage all that broadness you are trying to escape into
This is BS as we've established
We only established the fact you have no concrete answers, just vague "limitations" with nothing to back your words.
We are discussing oVirt as a "unified solution"
Unified with what? I already describe how you can unify it with Openstack, to create a joint system. There are other solutions, like MIQ that can unify different types of infrastructure. Define what you understand as "unified"
I bet 0% use it as stated as essentially a central, universal management platform for all (or reasonably "nearly all") workloads
I'm not sure where you got that. I never said it was meant for all workloads, I keep saying it is not. You are saying it's niche is non-existent because it is so "limited". Please, PLEASE just say what you want implemented, and we can find the right solution. Bashing on oVirt because it doesn't fit your specific niche is not productive.