High Availability for Red Hat Virtualization Manager 4.1

Hi folks, if you missed Red Hat Summit 2017 last week, it was great time in Boston. As promised, I’m uploading my presentation on HA for RHV-M 4.1 – hosted engine. Although, I’m doing it a little differently this time. I took the time this week to actually re-record it including the demos! This way you get a flavor of how I actually presented it last week.It turned out a little shorter in the re-recording, as it only clocked out at about 30 minutes and my session was about 10 minutes longer. But it’s all good. I walk through what hosted engine is, how it compares to standard deployment, why you would care if RHV-M goes down, and how to actually deploy hosted engine.

The embedded demos walk through the deployment of RHVH, the deployment of hosted engine via Cockpit, then a forced failover courtesy of a guest Velociraptor. Ok, not really, I just yanked the power on the underlying host.. but watch the demo anyway..

(best viewed in full screen, give it a moment to get in focus..)

One of the things that I really tried to emphasize in both the original presentation and the re-recording is that while hosted engine is a great solution, your end use case should determine whether or not it’s the best layout for your particular environment.

As always, your comments and questions are welcome!

hope this helps,

Captain KVM

5 thoughts on “High Availability for Red Hat Virtualization Manager 4.1”

    1. Hi Lisa,

      It *used* to be that if you needed optimal performance out of RHV-M, we would tell you to put the Postgres database on a separate host. However, there have been many, many improvements over the last few releases such that we’re very confident in leaving the database as part of the deployment. Beyond that, look at things in this order for the RHV-M appliance (and virtualized applications in general):
      Amount of memory
      Storage performance
      Network bandwidth/performance
      CPU speed

      CPU speed is (most of the time) the lowest priority for “general” virtualization. Yes, there are certainly CPU-bound apps and workloads, but by and large memory is the big deal for virt, then storage. Keeping things flowing in the network is just as important, so don’t be afraid to go crazy with VLANs. If you can afford 10GbE, do it. Otherwise, look at LACP for 1GbE.. And keep your management traffic separate from VM traffic, and your storage traffic separate from everything.

      hope this helps,

      Captain KVM

    1. Hi Frank,

      It’s been a few years since I did anything with UCS.. There is an official kbase article for RHEV 3, but it should not be any different for RHV 4. That article also has links to the official Cisco docs. The hosted-engine setup itself shouldn’t be any different as the VM-FEX is really the “special sauce” for the VMs.

      hope this helps,

      Captain KVM

      1. Since VMFEX requires some special tweaks to the libvirt network definitions and the domxml of the guest, I’d venture to say VMFEX support for hosted engine would be a good RFE to request. It’s not as trivial as setting up yet another bridge, so some work would probably have to be invested in making this happen. The VMFEX vdsm hook documentation describes the steps needed pretty well

Agree? Disagree? Something to add to the conversation?