Where Does oVirt Make Sense
-
Having looked at oVirt and talking to some of the people who seem to like it most, they seem to agree that its good use cases are extremely limited (by describing how it is meant to be used.) So I wanted to look at where it does make sense, because it seems like it must never make sense since it is being discussed in a community where it essentially never does. But that's more an aspect of being a primarily SMB community.
So first, what oVirt is meant to do:
- Be used as a platform level high availability (failover) mechanism.
- Manage KVM clusters, not individual / stand alone machines.
- Be in clusters of at least three nodes in size.
- Use shared storage, either via SAN, NAS, or Gluster.
- Be deployed as a unit, not deployed to manage existing resources.
So with this list, this helps us get a good understanding of what oVirt is, and what it wants to be. Things which seem to be almost polar opposites of what it is promoted as (a universal tool for any shop of any size to manage every workload.) Let's break these down. (Remember that most shops implement what is sold to them, not what is right for them - stating that there are lots of companies of any type using a tool only confirms what we already know and suspect: that companies rarely do good IT evaluations.)
-
HA Only Workloads: As we discuss constantly both in the community and at conferences. The average SMB has no business having any workload with HA, let alone all of them. It's decently rare to have an actual business justification for HA. Many do it anyway because hubris, mistakes, etc. We find it deployed where it should be all of the time. But when actual business evaluation processes are followed, it is a pretty rare need. When it is needed, it is always workload by workload and many workloads that need it, like databases, have their own mechanisms for this and can't or shouldn't use HA from the platform layer. So the average SMB should rule out any tool like oVirt right away. In the enterprise, workloads are evaluated and some get HA and some not, those that do sometimes get it at one layer, some at another. So having a tool like oVirt might make sense for special case SMBs who need HA, or for those isolated workloads in an enterprise that need platform HA.
-
oVirt is KVM only, for now at least. So environments needing non-KVM workloads like containers or Xen will be limited. In the SMB this is rare, so the KVM focus would make oVirt broadly applicable for most SMBs based on this one filter. In larger shops, a need to manage multiple workload platform types becomes more common (a simple factor of scale.) So as a universal tool it becomes more limited, but if we focus solely on it as a KVM tool, it remains useful.
-
Clusters must be three nodes or larger. This is a pretty huge factor. Today almost no SMBs have a need for more than two nodes, even when needing HA. And every day the workload volume that can be handled by just two nodes increases. And the ratio of in house workloads decreases. So this is an increasingly problematic limitation for oVirt in the SMB. And it requires, because of #2, that each cluster be three nodes or more, so even many SMBs large enough to need a capacity that would push them to three or more servers are often challenged that those workloads may not be co-located. So this limitation which may seem trivial is actually pretty staggering. In the enterprise, it would be pretty rare for this to affect a decision, but this, combined with #1, makes oVirt effectively impossible to make sensible use of in an SMB setting. It's simply focused on a niche that basically doesn't exist in the SMB.
-
This limitation of underlying storage is in some ways an artefact of points 1 & 3 so is not very limiting on its own. However it creates a bottleneck requirement that is a problem. All of the intended use technologies add either a lot of cost/complexity or a performance issue, or often both, to implement. Needing external storage like iSCSI or NFS carries one set of problems (and essentially has no viable use case in either SMB or enterprise today) or requiring slow Gluster for locally replicated storage means that any niche workloads that meet all of the former requirements must also accept a relatively slow storage layer. In the real world, workloads that meet all of these requirements very often also demand very fast storage. So while overall this limitation might seem trivial, it actually becomes a pretty heavy filter when we view it in the light of only applying to workloads already filtered above. It easily eliminated oVirt from proper decision making for the majority of workloads that are still in consideration by this point.
-
This point is pretty major outside of the SMB. Inside the SMB it is very common to forklift infrastructure and to replace everything at once because there is only a need for one physical server or cluster in total. But in the enterprise this really doesn't happen. Workloads need a flexibility of being deployed in different ways, at different times. This doesn't prevent something like oVirt from being used in isolated areas, but makes it essentially impossible to use it across the board in a unified management environment. Some SMBs are effected by this, and MSPs (the closest thing to "enterprise" in the SMB space) have really no way to use it because they would have to forklift all customers universally in order to be able to consolidate them, something that might sound plausible on paper but is completely ridiculous to discuss in practice. In the real world, MSPs have to manage what exists already and cannot coordinate all upgrades to all customers at once. So where oVirt might seem the most logical, as a centralization tool for disparate environments, it really doesn't work for.
Now with any product, we expect that "most" people shouldn't choose it. IT is so diverse that basically all solutions should be "less than half the time." So that oVirt's use cases are decently limited is not surprising and should not be to anyone. but I do think that it is surprising how limited it turns out to be. But for those that fall through all of the above filters, and there are many workloads that do, oVirt seems like a really great tool.
-
Sandro Bonazzola reached out to me to add a major correction to the list... oVirt supports a single node deployment mode. Getting more information on that now.
-
@scottalanmiller said in Where Does oVirt Make Sense:
Sandro Bonazzola reached out to me to add a major correction to the list... oVirt supports a single node deployment mode. Getting more information on that now.
I told you about single node deployment in the other thread!
https://mangolassi.it/post/468419 -
@FATeknollogee said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
Sandro Bonazzola reached out to me to add a major correction to the list... oVirt supports a single node deployment mode. Getting more information on that now.
I told you about single node deployment in the other thread!
https://mangolassi.it/post/468419Hmm... not at the point in the thread where that goes to. Will have to dig around for it. What's the storage situation when you do that?
-
@scottalanmiller said in Where Does oVirt Make Sense:
@FATeknollogee said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
Sandro Bonazzola reached out to me to add a major correction to the list... oVirt supports a single node deployment mode. Getting more information on that now.
I told you about single node deployment in the other thread!
https://mangolassi.it/post/468419Hmm... not at the point in the thread where that goes to. Will have to dig around for it. What's the storage situation when you do that?
It's local storage on the host since its a single node!
-
@FATeknollogee said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
@FATeknollogee said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
Sandro Bonazzola reached out to me to add a major correction to the list... oVirt supports a single node deployment mode. Getting more information on that now.
I told you about single node deployment in the other thread!
https://mangolassi.it/post/468419Hmm... not at the point in the thread where that goes to. Will have to dig around for it. What's the storage situation when you do that?
It's local storage on the host since its a single node!
So with a single node deployment, you can have many single node deployments, all with local storage, all managed by a single oVirt? That's very, very contrary to what someone was promoting in the other thread.
-
@scottalanmiller said in Where Does oVirt Make Sense:
So with a single node deployment, you can have many single node deployments, all with local storage, all managed by a single oVirt? That's very, very contrary to what someone was promoting in the other thread.
Yes sir.
I've only tried & installed 1 single node deployment.
According to folks like Sandro & Sahina, you can manage multiple single node deployments.
One slight problem is when you have to update oVirt, you need to shutdown your vm's since there's no other hosts to migrate to. -
@FATeknollogee said in Where Does oVirt Make Sense:
One slight problem is when you have to update oVirt, you need to shutdown your vm's since there's no other hosts to migrate to.
But only the oVirt Node, not the oVirt Engine, correct? The engine has to be able to lose connectivity. If so, that's not really a slight problem, as that's just part of any single node pattern.
-
@scottalanmiller said in Where Does oVirt Make Sense:
@FATeknollogee said in Where Does oVirt Make Sense:
One slight problem is when you have to update oVirt, you need to shutdown your vm's since there's no other hosts to migrate to.
But only the oVirt Node, not the oVirt Engine, correct? The engine has to be able to lose connectivity. If so, that's not really a slight problem, as that's just part of any single node pattern.
You shut the vm's down, update the engine, then you can also update the host, reboot the host & then re-start the engine.
-
Here is my procedure to update a single node
put host in global maintenance # hosted-engine --set-maintenance --mode=global run yum update on hosted engine # yum update -y run engine-setup on hosted engine # engine-setup shutdown all VMs and hosted engine run yum update on physical host reboot start hosted-engine disable global maintenance # hosted-engine --set-maintenance --mode=none -
@FATeknollogee so if you have 100 Nodes, and one engine, you have to shut down all 100 Nodes all at the same time just to patch the Engine?
-
@scottalanmiller said in Where Does oVirt Make Sense:
@FATeknollogee so if you have 100 Nodes, and one engine, you have to shut down all 100 Nodes all at the same time just to patch the Engine?
In a multi-node system, the vm's would continue to run while you patch & reboot the hosted engine.
Not sure how your example would work.
-
@FATeknollogee said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
@FATeknollogee so if you have 100 Nodes, and one engine, you have to shut down all 100 Nodes all at the same time just to patch the Engine?
In a multi-node system, the vm's would continue to run while you patch & reboot the hosted engine.
Not sure how your example would work.
Seems hard to believe that it would kill all nodes if the Engine updates then, because how would it work for clusters and not individual nodes? Logically I can't think of any way that that would get connected.
-
If I understood it correctly you can only run 3, 6, 9 or 12 nodes in a hyperconverged cluster.
https://access.redhat.com/documentation/en-us/red_hat_hyperconverged_infrastructure_for_virtualization/1.6/html/deploying_red_hat_hyperconverged_infrastructure_for_virtualization/rhhi-requirements#rhhi-req-pmIt makes it complicated to say the least.
If you use multi-node servers most are also based on even numbers of nodes such as two, four or eight. So if you are going high-density servers to save on rackspace things get complicated.
-
@Pete-S said in Where Does oVirt Make Sense:
If I understood it correctly you can only run 3, 6, 9 or 12 nodes in a hyperconverged cluster.
https://access.redhat.com/documentation/en-us/red_hat_hyperconverged_infrastructure_for_virtualization/1.6/html/deploying_red_hat_hyperconverged_infrastructure_for_virtualization/rhhi-requirements#rhhi-req-pmIt makes it complicated to say the least.
If you use multi-node servers most are also based on even numbers of nodes such as two, four or eight. So if you are going high-density servers to save on rackspace things get complicated.
That is definitely what it says:
Initial deployments of Red Hat Hyperconverged Infrastructure for Virtualization are either 1 node or 3 nodes.
1 node deployments cannot be scaled.
3 node deployments can be scaled to 6, 9, or 12 nodes using one of the following methods:
Add new hyperconverged nodes to the cluster, in sets of three, up to the maximum of 12 hyperconverged nodes.
Create new Gluster volumes using new disks on new or existing nodes.
Expand existing Gluster volumes to span 6, 9, or 12 nodes using new disks on new or existing nodes. -
@scottalanmiller said in Where Does oVirt Make Sense:
@FATeknollogee said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
@FATeknollogee said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
Sandro Bonazzola reached out to me to add a major correction to the list... oVirt supports a single node deployment mode. Getting more information on that now.
I told you about single node deployment in the other thread!
https://mangolassi.it/post/468419Hmm... not at the point in the thread where that goes to. Will have to dig around for it. What's the storage situation when you do that?
It's local storage on the host since its a single node!
So with a single node deployment, you can have many single node deployments, all with local storage, all managed by a single oVirt? That's very, very contrary to what someone was promoting in the other thread.
This is how I deployed it in testing.
-
Found my old thread...
-
@Obsolesce said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
@FATeknollogee said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
@FATeknollogee said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
Sandro Bonazzola reached out to me to add a major correction to the list... oVirt supports a single node deployment mode. Getting more information on that now.
I told you about single node deployment in the other thread!
https://mangolassi.it/post/468419Hmm... not at the point in the thread where that goes to. Will have to dig around for it. What's the storage situation when you do that?
It's local storage on the host since its a single node!
So with a single node deployment, you can have many single node deployments, all with local storage, all managed by a single oVirt? That's very, very contrary to what someone was promoting in the other thread.
This is how I deployed it in testing.
According to oVirt, whom I asked directly, even for this you need shared storage.
-
@scottalanmiller said in Where Does oVirt Make Sense:
@Obsolesce said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
@FATeknollogee said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
@FATeknollogee said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
Sandro Bonazzola reached out to me to add a major correction to the list... oVirt supports a single node deployment mode. Getting more information on that now.
I told you about single node deployment in the other thread!
https://mangolassi.it/post/468419Hmm... not at the point in the thread where that goes to. Will have to dig around for it. What's the storage situation when you do that?
It's local storage on the host since its a single node!
So with a single node deployment, you can have many single node deployments, all with local storage, all managed by a single oVirt? That's very, very contrary to what someone was promoting in the other thread.
This is how I deployed it in testing.
According to oVirt, whom I asked directly, even for this you need shared storage.
In what context? I obviously did not use it when I had oVirt running and working.
-
@Obsolesce said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
@Obsolesce said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
@FATeknollogee said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
@FATeknollogee said in Where Does oVirt Make Sense:
@scottalanmiller said in Where Does oVirt Make Sense:
Sandro Bonazzola reached out to me to add a major correction to the list... oVirt supports a single node deployment mode. Getting more information on that now.
I told you about single node deployment in the other thread!
https://mangolassi.it/post/468419Hmm... not at the point in the thread where that goes to. Will have to dig around for it. What's the storage situation when you do that?
It's local storage on the host since its a single node!
So with a single node deployment, you can have many single node deployments, all with local storage, all managed by a single oVirt? That's very, very contrary to what someone was promoting in the other thread.
This is how I deployed it in testing.
According to oVirt, whom I asked directly, even for this you need shared storage.
In what context? I obviously did not use it when I had oVirt running and working.
In the context of "what is supported." They said later that there are tricks to getting it to work, but it is officially unsupported.
