Mixing Thick and Thin Hypervisors in a RHEV 3 Environment

If you’ve checked out both RHEV 3 as well as running KVM on RHEL 6, you’ve no doubt found pros and cons for going one way or the other with your hypervisors. RHEV-H offers a simple appliance approach that is already tuned and configured. KVM on RHEL 6 allows for customization while still offering the benefits of the high-speed KVM hypervisor. Which one should you use?

Simple. Use both.

Remember, RHEV can manage both thick and thin hypervisors. You don’t have to pick one or the other, especially when considering the use cases.

Thin Hypervisor (RHEV-H)

As mentioned previously, RHEV-H offers a clean and simple appliance approach to the KVM hypervisor. It can be deployed via DVD, USB key, or over the network. Once it’s installed, all of the configuration and management is handled from RHEV-M. The benefits are fairly clear:

  • Ease of management
  • No “one off” configurations
  • Ease of deployment & configuration
  • Pre-configured IPtables & SELinux
  • Pre-tuned KVM settings
  • Read only filesystems offer additional security

It’s easy for many use cases, but this comes at a cost for others. The appliance approach means that while the bad guys can’t install their nefarious packages, it also means that you can’t install other tools that you might need for some applications, such as a monitoring or backup agent. Here’s where the thick hypervisor comes to the rescue.

Thick Hypervisors (RHEL 6)

Having a thick hypervisor doesn’t mean deploying “bloatware”, if done correctly. Just remember to keep the install streamlined. No graphics packages, no dev packages, or anything else that doesn’t need to be there. If it doesn’t support, service, or protect the virtual machines, it doesn’t belong.

It’s not difficult to develop a golden image or template to ease the deployment and configuration. And this leaves plenty of room to install a monitoring agent, a backup agent, or anything else that a business requirement dictates is necessary on the hypervisor.

Illustrating the Point

Here’s a good example. In the graphic below, there are 12 web servers spread across 4 hypervisors. A backup agent runs only on the guest itself to quiesce the application and maybe the filesystem. They in turn talk to 4 database servers spread across 2 hypervisors.

For example’s sake, the database servers are critical and require extra care. Specifically, its not enough that the database gets quiesced, the virtual machine needs to be quiesced as well. This means that the hypervisor needs to run the backup agent. Additionally, the hypervisor runs a monitoring agent to collect different metrics.

In this scenario, we use the thin hypervisor to handle the masses, with the thick hypervisor to handle the extra requirements. RHEV-M still manages all of them, and the backup and monitoring applications still talk to their respective agents.You don’t need to run agents on all of the hypervisors, but you don’t want to be locked out of running them when you need them.

And most importantly, you’re not locked into one form factor.

Agree? Disagree? Something to add to the conversation?