High Availability for RHV-M

Hi folks, so time ago (years?) I wrote about how to put together High Availability for RHV-M. At the time the actual configuration that I proposed was solid, if a little unorthodox. Still, it certainly left room for improvement. In this week’s post, I’m updating the configuration with something that Red Hat fully supports. They refer to the configuration as Self-Hosted Engine.

Why Hosted Engine?

The primary benefits to using the Self-Hosted Engine, or “HE”, is that it provides a fully supported HA configuration for RHV-M as well as a smaller overall footprint as compared to a traditional deployment of RHV. Also, RHV-M is delivered as an appliance for the HE configuration, so the entire process is streamlined. Who doesn’t like that?


Let’s go back to the smaller footprint statement a few times though.. First off, in a traditional deployment of RHV, you have RHV-M, plus hosts. That deployment of RHV may be on a bare-metal host or it may be on a VM in a different virtualization environment. Regardless, you’re already using up resources and software subscriptions that you may not want to use. Not to mention the fact that it may cause you to cross-deploy resource across tenant or administrative boundaries that you wouldn’t normally want to cross.

The HE configuration allows for a much “cleaner” and concise deployment in that not only do you deploy fewer resources, but administratively, they are self-contained as well.

The diagram below shows examples of non-HE deployments. In comparison, they aren’t as streamlined. I know the “red x’s” are a little dramatic, but the only truly awful configuration is the second configuration with the separate HA software.. truly unnecessary and added complication.


Secondly, from a footprint standpoint there is the option (read: recommendation) of the lightweight host for the HE configuration. I’ve posted several articles now on the “next generation node” (RHVH) and this is a fantastic use case – hosting the RHV-M appliance in an HE configuration as well as some other “infrastructure level” tools. If you have some other VMs that will service the environment such as PXE, DNS*, DHCP, LDAP, they would fit in nicely.

To that end, I would also suggest that the RHV-M appliance and any other infrastructure VMs be in their own RHV data center and cluster, separate from your other workloads. That’s for security, workload separation, and it just makes good sense.

So what is the general workflow? Glad you asked. Essentially, it works like this:

  1. Have a FQDN ready to go (backward and forward lookup must work!!)
  2. Install RHVH, configure the “performance profile” for “virtual host”
  3. Download the RHV-M appliance and transfer it to the RHVH
  4. Launch the `hosted-engine –deploy` command or launch from Cockpit web admin console

Yes, there are other things, but that’s the gist. And it’s still faster than deploying from scratch, and definitely faster than trying to create your own HA configuration..

What else should I know about the HE configuration?

If you’ve been running RHV for a while, then you know that RHV-M handles the HA parts for the VMs that need it.. In other words, if you configure a VM to be highly available, and the host underneath it goes down, that VM will automatically be restarted on another host in the cluster. So now you must be wondering then, if RHV-M handles HA, then how does it restart itself if it itself goes down????

Fantastic question. That is part of the special HE configuration. The HA configuration for RHV-M is actually handled by the hosts in an HE configuration, and as such if you need to do any work such as upgrades or even take RHV-M down, then you put the HA status into maintenance mode.

The other big consideration to be made is performance. Because the configuration has been streamlined and RHV-M has been deployed as an appliance in the HE deployment, most of the decisions have been made for you, but have no fear. If you need to have your PostgrSQL database, data warehouse, or websocket proxy broken out to separate hosts in order to eek out as much horsepower as possible, you can do so. Post deployment.

I plan to follow all of this up with a few demo’s around deployment as well as showing off the HA portion. If you want to find out more, check out the official docs: https://access.redhat.com/documentation/en/red-hat-virtualization/4.0/paged/self-hosted-engine-guide/

*DNS actually wouldn’t be a good candidate in this particular cluster… Losing DNS here would have far reaching implications. 😉

Hope this helps,

Captain KVM

6 thoughts on “High Availability for RHV-M”

  1. Since upgrading to 4.0 requires reinstalling RHV-M on a RHEL 7 host can migration to Hosted Engine be combined with a 3.6 to 4.0 upgrade? Is this something we might see a KB article on?

    1. Hi Jeff,

      Thanks for dropping by. Great question and the answer to your first question is…. YES!!!!! As a matter of fact, the fantastic folks in Red Hat CEE (fancy pants way of saying support) even put together a tool for upgrading from 3.6 to 4.0, and it EVEN SUPPORTS HOSTED ENGINE! And yeah, I might even put a post together on the process of upgrading. 😉

      You’ll find the “upgrade helper tool” at https://access.redhat.com/labs/rhevupgradehelper/

      Captain KVM

      1. Thanks for the response. That upgrade tool is great, but it doesn’t cover this exact scenario. It would be great if they could add upgrading from a non hosted engine environment to a hosted engine environment for the 3.6 to 4.0 upgrade. I’m sure I could figure it out, but it would be really nice to have a validated guide.

        1. Hi Jeff,

          That would actually be 2 separate processes; both of which are supported scenarios. I would do the upgrade first then the conversion.

          Captain KVM

  2. Hello,

    Thank you for the post, I was thinking about Disaster Recovery what would be the best practice on a self hosted engine if I have a two datacenter deployment with two independent clusters it is not streched cluster or anything just to datacenter within RHEV-M, and each one of them with a cluster. Would you manage this with just one manager? or would you run a manager in each cluster?

    Another thing I am worried about the self-hosted engine is the scalability and how it can grow if the enviroment gets quite large.

    Thak you and great blog!

    1. Hi Laura,

      Apologies for the delayed response. These are fantastic questions, by the way. Currently, you would manage separate physical datacenters as separate deployments of RHV, so each would have their own instance of RHV-M. We are looking at how to support stretch/distance clusters also, but it’s a “roadmap” item. If you needed a way to manage them from a single interface, look at CloudForms.

      As for scalability, I wouldn’t worry about that at all. Here is my recommendation: keep your ‘hosted engine’ cluster separate from your ‘production’ cluster. Your hosted engine cluster would obviously have your ‘hosted engine’ appliance, but it would also have any other VMs that provide services to the environment such as DHCP, PXE, DNS cache (don’t put your master here), etc. The your production cluster(s) are free to grow. That also means that if you have an app that is soaking up resources, it doesn’t affect RHV-M at all.

      As for the RHV-M appliance itself, look at the product documentation. See the “minimum” requirements vs the “recommended” requirements.. there is definitely a difference. If you think or know that you’re going to grow, definitely start with the “recommended” specs.

      hope this helps,

      Captain KVM

Agree? Disagree? Something to add to the conversation?