Testing oVirt...
-
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.
-
@Emad-R said in Testing oVirt...:
Let us talk about Gluster, how do you feel safe with it ?
Safe, yes, for sure. Gluster is battle tested and well known. It's mature. Not super fast, but not meant to be.
-
@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.
-
@DustinB3403 said in Testing oVirt...:
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".
No way, oVirt is exactly the wrong solution for a tiny setup. It starts to shine when you really scale the hypervisor count.
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.
I tell everyone to just use the official RHV docs, they are much better. I really don't know what's going on with the upstream documentation in oVirt, I've been away from the project for 6 years now, but the downstream stuff is always up to date and in order.
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.
In a tiny SMB - certainly. One of the use-cases where I replaced the existing setup with RHV in 2010-2011-ish, was a cluster of 300 Xen hosts, each paired in a 2-node failover cluster. A huge waste of hardware and a nightmare to manage. For the cost of 150 servers they could get rid of, they managed to buy a really nice SAN. And that's before the actual benefits of consolidating the resources of so many hosts.
The clustering bit is just way more complex than any use case I'd ever expect to need.
Clustering in oVirt is very simple - standard fencing mechanisms. What exactly was complex?
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"
I agree, documentation is always bad, especially when talking about large multi-node systems. Did you open a documentation BZ for the stuff that was hard to properly understand?
-
@dyasny said in Testing oVirt...:
I agree, documentation is always bad, especially when talking about large multi-node systems. Did you open a documentation BZ for the stuff that was hard to properly understand?
No because I was so fed up with the instructions I close abandoned the test.
-
@Obsolesce said in Testing oVirt...:
Enterprise storage I've seen, is SAS. Where do you see San in enterprise everywhere?
Pretty much everywhere really. HCI did not fly as the SAN killer, SDS is cheap to start with, but it can turn into hell at scale (ans scale is where it is supposed to shine). New companies like Infinidat are having a blast selling SANs, despite the pervasive notion that SAN is dead and gone. It's just like with tape - it's still out there, getting developed, sold and used, no matter how much we all hate dealing with it.
-
@DustinB3403 said in Testing oVirt...:
No because I was so fed up with the instructions I close abandoned the test.
Well, oVirt is an opensource and free project. You want it to be better, get involved, even by reporting bugs. I really don't get people who expect to just have everything perfectly served up and for free.
Really, every time someone tells me this or that OSS project is bad, I ask for the links to the opened issues.
-
@dyasny said in Testing oVirt...:
@DustinB3403 said in Testing oVirt...:
No because I was so fed up with the instructions I close abandoned the test.
Well, oVirt is an opensource and free project. You want it to be better, get involved, even by reporting bugs. I really don't get people who expect to just have everything perfectly served up and for free.
Really, every time someone tells me this or that OSS project is bad, I ask for the links to the opened issues.
Hey I didn't say I wouldn't, I just said I didn't because I was frustrated.
Also I feel like the most popular instructions were a blog post, rather than official documentation.
-
@DustinB3403 said in Testing oVirt...:
Also I feel like the most popular instructions were a blog post, rather than official documentation.
I'm not even sure they have a dedicated techwriter. This is why it is better to just follow the official RHV docs. You'll have to filter out the Red Hat specific details, like subscription-manager, but you'll definitely have a better experience
