Testing oVirt...
-
@FATeknollogee said in Testing oVirt...:
@scottalanmiller said in Testing oVirt...:
Yeah, way too much overhead and complexity. It make simple tasks hard and it is totally focused on clustering which rarely has any place in the SMB. Deploying it was a huge headache. Had some neat features, but none that we cared about. We ran into some issues with it that were enough that we questioned the logic of trying to use it.
Tested virt-manager instead and it was flexible, simple, and worked perfectly, instantly. The real thing was that in the end oVirt just offered nothing of particular value, but had a lot of negatives.
I disagree about oVirt having lots of negatives.
You guys were attempting to use the wrong tool for the job.@scottalanmiller said in Testing oVirt...:
Remote management of multiple KVM sites.
Perfect job for virt-manager :thumbs_up:
Its the wrong tool for the job because of its negatives
Had it not had those negatives it would have been the better tool.
-
The idea behind oVirt is superior. Central web based management would be great. oVirt simply was too complex and inflexible making it worth abandoning a superior approach because it just wasnt that good at what it should be best at.
oVirt isnt bad, but it absolutely has huge negatives that are glaring and unnecessary.
-
oVirt is the RH equivalent of vSphere.
oVirt was not made to manage standalone instances of virt-manager.
-
@FATeknollogee said in Testing oVirt...:
oVirt is the RH equivalent of vSphere.
oVirt was not made to manage standalone instances of virt-manager.
Thats a massive weakness and goes totally against their stated purpose of being a central management infrastrutcture for the enterprise. Thats also totally different than vSphere.
oVirt is supposed to be exactly what you say it is not for.
-
What good is oVirt to an enterprise if it is for isolated low performance HA instances only? That makes no sense.
-
You do realize some type of "shared" storage is necessary unless you opt for the single node install option (which it sounds like you guys didn't choose)?
-
@FATeknollogee said in Testing oVirt...:
You do realize some type of "shared" storage is necessary unless you opt for the single node install option (which it sounds like you guys didn't choose)?
We wanted single node but in testing found it unnecessarily complex and limited for its stated purpose. If it has bad requirements, that would itself be quite a weakness.
-
A major limitation of oVirt is that across the board is that it is just so limited. It is designed around a massively niche use case. Its a use case not really viable in the SMB or enterprise. Having to use oVirt for just a portion of management is a huge linitation. Even where it fits, it seems to fit poorly. The whole point is that it is very limited. Poibting out that it IS limited is my point. Then on top, it is overly complex.
Basically in response to the issue of it being too limited is that it is meant to be limited. Sure, accepted. So it is limited by design. That doesn't change the fact that it is limited. Intentional or not, its a big negative.
-
@scottalanmiller said in Testing oVirt...:
The idea behind oVirt is superior. Central web based management would be great. oVirt simply was too complex and inflexible making it worth abandoning a superior approach because it just wasnt that good at what it should be best at.
oVirt isnt bad, but it absolutely has huge negatives that are glaring and unnecessary.
Odd. I got it up and running very easily not very long ago.
What were the issues you had if you don't mind me asking something you probably already answered somewhere.
-
@scottalanmiller a limitation is that it is limited. perfect!
ovirt is a system designed to manage a large cluster of kvm hosts using shared storage. standalone hosts with local storage are not part of the use case. the fact that support for local stprage was added is besides the point and was done because it was a low hanging feature, not because it is really needed or used much.
whatever you think enterprise needs, you are not the final authority on that. fact is, RHV has a good install base in enterprise, including your favourite Wall Street.
-
@dyasny said in Testing oVirt...:
ovirt is a system designed to manage a large cluster of kvm hosts using shared storage.
Yes, very much so, but they don't promote it that way, they promote it as being for a different use case.
-
@dyasny said in Testing oVirt...:
the fact that support for local stprage was added is besides the point and was done because it was a low hanging feature, not because it is really needed or used much.
But obviously core to their stated use case - central enterprise KVM management.
-
@dyasny said in Testing oVirt...:
whatever you think enterprise needs, you are not the final authority on that.
No, but the enterprise is and there is a reason why RVH isn't being used as intended basically anywhere. You are confusing "being used" with "being used as intended". Basically any enterprise shop will have local storage for workloads where appropriate, and so oVirt ends up being a "onesy twosy" installation rather than a central management tool.
You don't have to resort to trying to make it personal - which shows an emotional response that makes no sense here, it suggests that you know it's a bad fit and that my point is correct. This is super simple, it is extremely limited and while that is by design, it goes against the way that the product is intended. And trying to play off "enterprises can deploy it" as "enterprises use only it" doesn't hold up. You are ignoring what we are talking about to try to make oVirt look way better than it is.
That's not to say that it is bad, but looking into using it for the use case it is promoted for, then discovering that it's not really built to be the broadly useful tool that everyone seems to push it as, simply leaves it as a sad, limiting experience.
-
@Obsolesce said in Testing oVirt...:
Odd. I got it up and running very easily not very long ago.
getting it up and running isn't hard. Getting it up and running in a disparate, broad, centrally managed way is hard. That's basically my point over and over - if you use it in one very specific way it's easy and does a great job (isolated, HA-focused, low performance clusters) and if you use it in any other way (enterprise multi-purpose workloads or similar) it doesn't work well. Now it's stated that it's not meant to work that way, and that's fine, but it's also pushed for those cases, when obviously it shouldn't.
Basically, you can see that lots of people see it as a pet project and want to promote it for everything, and act like you need to change your entire business to fit around oVirt, rather than having a tool that fits around real world workload needs. If oVirt was promoted more clearly for very niche use cases, it would not come across the same way.
Here is the stated case: "oVirt is an open-source distributed virtualization solution, designed to manage your entire enterprise infrastructure." Obviously, as people have pointed out, this is total crap. It's meant only for very niche workloads within any large business, and only for extremely isolated small businesses for whom all workloads fit into that niche.
The issue isn't oVirt as a techology, but oVirt as it is being promoted. It seems a lot like FreeNAS, but not quite as bad. basically a big cult following that are pushing it recklessly by ignoring the use cases and acting like it's a magic box that fixes all needs like it's not a real world system or something. FreeNAS always overstates its case, in the real world, it's essentially useless. oVirt seems way better than that, but nowhere near the universal tool it promotes itself, and others promote it as being.
-
@scottalanmiller said in Testing oVirt...:
Yes, very much so, but they don't promote it that way, they promote it as being for a different use case.
In my day the message was pretty clear - an alternative to the typical vsphere cluster with shared storage.
But obviously core to their stated use case - central enterprise KVM management.
What's wrong with that? Enterprises is where you get to see the large SAN installations, SMBs usually don't have the money for those
a reason why RVH isn't being used as intended basically anywhere
RHV is being used as intended almost everywhere I've supported or installed it. No reason to use it anywhere else.
Basically any enterprise shop will have local storage for workloads where appropriate, and so oVirt ends up being a "onesy twosy" installation rather than a central management tool
Local storage "where appropriate" usually means extremely datapath latency sensitive workloads, and if those require local storage, they probably also require baremetal, and should not be virtualized. FC latencies compared to local SAS are negligible, and you will lose more by virtualizing such workloads than by placing their data on a fast SAN.
You don't have to resort to trying to make it personal - which shows an emotional response that makes no sense here, it suggests that you know it's a bad fit and that my point is correct.
No, I simply know by now that you will resort to the "I worked on Wall street argument", so I simply want to show you it will not fly.
This is super simple, it is extremely limited and while that is by design, it goes against the way that the product is intended.
How is it limited again? I already told you what the intended use case it, everything added later on is an afterthought, chasing after some of that openstack market really. If you want to manage a bunch of localhosts instead of an actual cluster, you don't run oVirt.
And trying to play off "enterprises can deploy it" as "enterprises use only it" doesn't hold up. You are ignoring what we are talking about to try to make oVirt look way better than it is.
This is BS. I don't argue that in this particular case, oVirt may not be the best tool for the job. Then I do tell you what it is really for, you even agree with that, and then you tell me I'm wrong. After agreeing with me. Your argument is "it is limited because it is limited", very persuasive, obviously.
That's not to say that it is bad, but looking into using it for the use case it is promoted for, then discovering that it's not really built to be the broadly useful tool that everyone seems to push it as, simply leaves it as a sad, limiting experience.
You had the wrong expectations, were disappointed, and you're blaming the product. Sounds like "I bought this dam expensive Ferrari, but I can't haul 5 tons of gravel with it, Ferraris obviously suck!".
isolated, HA-focused, low performance clusters
Why low performance?
enterprise multi-purpose workloads or similar) it doesn't work well
Maybe you should define what you think of as "enterprise workloads". And just to jump ahead, lets just say I'm absolutely certain I can find examples of F100 enterprises running the exact workload types oVirt is perfect for. Will that mean you don't consider them enterprises, because they don't fit your definition?
It's meant only for very niche workloads within any large business, and only for extremely isolated small businesses for whom all workloads fit into that niche.
Any large business will run multiple solutions anyway. You don't run a single vsphere setup for an F100 corporation, you don't even ONLY run vsphere, you probably will have multiple virtualization solutions, public and private clouds, baremetal, container management systems etc etc etc. oVirt cannot cover all of that. No solution can in fact. Your conclusion - oVirt is limited. Mine - they are all limited, so we should be using the best solution for the job, and a real enterprise can have more than one job, don't expect a single tool to fit all the niches.
-
@dyasny said in Testing oVirt...:
Yes, very much so, but they don't promote it that way, they promote it as being for a different use case.
In my day the message was pretty clear - an alternative to the typical vsphere cluster with shared storage.
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. 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.
-
@dyasny said in Testing oVirt...:
But obviously core to their stated use case - central enterprise KVM management.
What's wrong with that? Enterprises is where you get to see the large SAN installations, SMBs usually don't have the money for those
Nothing "wrong" with it, if they were honest about that being the use case rather than suggesting the opposite. 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.
If we created our own "but we only want this one insanely limited use case" then compare oVirt against it, it shines.
So basically, if the oVirt fan club looks at oVirt and creates a niche set of desires based on what oVirt does and nothing else, then evaluates oVirt based on oVirt itself, of course it looks good. But that's crazy. Obviously that's choosing the answer then figuring out the question to ask to get it.
-
@dyasny said in Testing oVirt...:
a reason why RVH isn't being used as intended basically anywhere
RHV is being used as intended almost everywhere I've supported or installed it. No reason to use it anywhere else.
This is only true if you define "how it is intended" after the fact.
-
@dyasny said in Testing oVirt...:
Basically any enterprise shop will have local storage for workloads where appropriate, and so oVirt ends up being a "onesy twosy" installation rather than a central management tool
Local storage "where appropriate" usually means extremely datapath latency sensitive workloads, and if those require local storage, they probably also require baremetal, and should not be virtualized. FC latencies compared to local SAS are negligible, and you will lose more by virtualizing such workloads than by placing their data on a fast SAN.
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. But "being sold" doesn't suggest it was "appropriate". SAN is expensive and risky. While you can minimize those negatives, it's only "appropriate" when you can make it better, not "less worse."
Arguing that SAN 'isn't too bad' makes it look like a use case is justified, but is a sales tactic. It makes humans feel compassionate towards a solution and forget that it has to be the "best" option in a use case to be "appropriate" to be selected. It's the same as the "it works for me" tactic but with a different approach.
-
I tested oVirt and was really just generally confused by it, as it really makes the case of "we're great for SMBs who only have 2-3 hosts".
Which in my lab would be a good fit to test with, but in practical implementation of it, it's anything but, the documentation is split and the setup was just overly difficult.
It has a use case for sure, but I'd much rather use stand alone hosts and just have them setup to be able to be used as fail over targets like with XenServer/XCP-ng, Hyper-V.
The clustering bit is just way more complex than any use case I'd ever expect to need.
