Testing oVirt...
-
@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.
-
@DustinB3403 said in Testing oVirt...:
The clustering bit is just way more complex than any use case I'd ever expect to need.
It's true, the deployment and documentation are extremely complex and obtuse given that the whole system is so limited. It could me simplified a lot given that there is really just a handful of supposedly intended use cases. I think perhaps in their attempts to oversell it they've made it way too complex to try to make it seem like it's meant for way more use cases than it is.
-
No where on their main page does oVirt target the SMB.
So where is all this marketing you are talking about @scottalanmiller
-
@scottalanmiller said in Testing oVirt...:
@DustinB3403 said in Testing oVirt...:
The clustering bit is just way more complex than any use case I'd ever expect to need.
It's true, the deployment and documentation are extremely complex and obtuse given that the whole system is so limited. It could me simplified a lot given that there is really just a handful of supposedly intended use cases. I think perhaps in their attempts to oversell it they've made it way too complex to try to make it seem like it's meant for way more use cases than it is.
Even with my intended goal of wanting to setup my lab to be clustered, the documentation was difficult.
Between clarifying on where something should be run, to the basic install process.
It could be easily cleaned up with a simple "install this iso on your 3 standalone hosts, on the first host do XYZ on hosts 2 and 3 do ABC"
-
@dyasny said in Testing oVirt...:
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.
It does. I have broad exposure to enterprise environments and understand that in large organizations the "one way to skin a cat" is an absurd belief. It takes very little enterprise experience to know how non-plausible it is to suggest that any large company in the enterprise space could ever have one single, highly limited solution and use it for everything.
So to undermine a "duh, how obvious can it be" fact, you use ad hominen attacks to make it seem like I'm using some special "I know something you don't know because I'm special" insider knowledge when, in fact, I'm just stating something that absolutely everyone who has ever worked in a large business or just has common sense would already know. You are trying to defeat common sense with a logical fallacy.
-
@DustinB3403 said in Testing oVirt...:
@scottalanmiller said in Testing oVirt...:
@DustinB3403 said in Testing oVirt...:
The clustering bit is just way more complex than any use case I'd ever expect to need.
It's true, the deployment and documentation are extremely complex and obtuse given that the whole system is so limited. It could me simplified a lot given that there is really just a handful of supposedly intended use cases. I think perhaps in their attempts to oversell it they've made it way too complex to try to make it seem like it's meant for way more use cases than it is.
Even with my intended goal of wanting to setup my lab to be clustered, the documentation was difficult.
Between clarifying on where something should be run, to the basic install process.
It could be easily cleaned up with a simple "install this iso on your 3 standalone hosts, on the first host do XYZ on hosts 2 and 3 do ABC"
Yeah, and they use bizarre terms for no reason. Nodes, engines, etc. WTF. It's as if oVirt users aren't familiar with things like hypervisors and management consoles. It appears to be written with the assumption that the people using it will have never used anything else before. It's truly weird.
-
@JaredBusch said in Testing oVirt...:
No where on their main page does oVirt target the SMB.
So where is all this marketing you are talking about @scottalanmillerThey do not target the SMB, I stated that that use case evaluation was because of this thread which asked SMBs about oVirt in that context. Their website targets enterprises as a universal tool. So the one case is for the people on here trying to promote it for the SMB and not a statement about oVirt themselves. oVirt makes the second case.
-
@dyasny said in Testing oVirt...:
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.
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.
-
@dyasny said in Testing oVirt...:
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.
Enterprise storage I've seen, is SAS. Where do you see San in enterprise everywhere?
-
@dyasny said in Testing oVirt...:
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!".
Again, you are defining "wrong expectations" after the fact. 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. This is a fanboy approach. You didn't set expectations then find a product to match, you found the product and then set expectations around what you found it could do.
It's like going to the store and being asked to test a Ferrari to see how well it hauls 5 tons of gravel, reporting back that it sucks, then being attacked for being so foolish as to 1) test something so crappy that we should have known better without testing it and 2) believing the sales person for what they tried to sell it as being used for.
-
@Obsolesce said in Testing oVirt...:
@dyasny said in Testing oVirt...:
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.
Enterprise storage I've seen, is SAS. Where do you see San in enterprise everywhere?
Same in my experiences, which yes, include Wall St., but also include manufacturing and others. All use a mix. SAN is common, but only as "one of many" storage options.
-
@dyasny said in Testing oVirt...:
isolated, HA-focused, low performance clusters
Why low performance?
Because it requires Gluster and/or remote storage. It doesn't offer straight local (highest performance) or high performance local cluster options.
And while I constantly state that performance is rarely as important as people say it is (and this explains why oVirt works in so many cases where it isn't necessarily the best choice) people do often want to get NVMe cards and shared RAM and other blinding fast features. A few need it, many just want it, but even in the 300 person manufacturing space we see shops running databases with performance that oVirt doesn't support. So not just something that the enterprise is looking for.
-
@dyasny said in Testing oVirt...:
enterprise multi-purpose workloads or similar) it doesn't work well
Maybe you should define what you think of as "enterprise workloads".
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.
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?
This is BS as we've established. We are discussing oVirt as a "unified solution". Absolutely no one is arguing that enterprises don't use it, or can't use it, or shouldn't use it for isolated workloads that fit its niche. You are stating this "I can find examples" statement to try to imply to other readers that I or someone said that somewhere. But we didn't. It's an attempt at leading. I bet 80% of the F100 uses oVirt. Easily. But I bet 0% use it as stated as essentially a central, universal management platform for all (or reasonably "nearly all") workloads. And I include Red Hat themselves (part of IBM) in that, having been at IBM, I know that they can't use this for their backbone.
You are attempting to change the evaluation parameters time and time again. You add limits then claim that by falling within those limits means that the product is not limited.
So basically... first we find it has technical limits, so you define those limits as assumed so not limits. Then we show that enterprises can't unify on the platform, so you redefine the goals. You are moving the goalposts as we show that the original ones aren't met or met well.
No one has argued that oVirt isn't 1) good 2) good for its designed use case 3) viable 4) able to be used where appropriate 5) used in a limited fashion within organizations also using other things. But you seem to be arguing against people who aren't here.
