Deploying RHEV 3.6 pt2 (Hypervisors)

Hi folks,

In my last post, we deployed RHEV-M, the Web UI & brains for Red Hat Enterprise Virtualization (RHEV). This week, I’m pushing on to the next logical and required step in the process – deploying a hypervisor. I’ll actually be deploying 4 hypervisors in my lab, but for the sake of time, I’ll highlight what it takes to add 1. The you can rinse and repeat.. For the uninitiated, RHEV supports “thick” and “thin” hypervisors. “Thick” refers to using RHEL+KVM while “thin” refers to the small footprint RHEV-H. There are benefits to both.

Thin Hypervisors

The RHEV-H thin hypervisor is a (mostly) read-only image that has a predefined number of packages. The only writeable information has to do with host identity like IP information, DNS, hostname, etc. IPtables and SELinux are pre-tuned for virtualization and packages that don’t support or service virtualization are not included. A hacker/cracker might be able to get in, but he/she would be able to change very little. A quick reboot and it would go right back to where it was 2 minutes earlier. This equates to a much smaller attack vector and a very easy install/management aspect. The one downside is zero flexibility if you do actually need to add a package or two; adding packages is not an option.

Thick Hypervisors

In my particular lab, I use the thick hypervisor, but don’t take that as a recommendation. It’s really just a limitation of my particular hardware. I actually need to open a bugzilla against my Intel NUCs and RHEV-H, but that’s a different story/post. Thick hypervisors (RHEL+KVM) are a good use case for environments that do require extra packages like monitoring software, extra security software, or other custom packages. Once RHEV-M contacts the RHEL hypervisor, it will force it to grab the necessary RHEV related packages, and then do cool things like tune the security to look like RHEV-H. But it also allows you to add in extra packages if you need to. Of course it also allows you to leave in extra packages and services too, and that could be trouble if you’re not planning properly

Planning Properly

If you are going to use a thick hypervisor, you should have a plan. Actually, a standard operating procedure, then stick to it. In my consulting days, I used to have a basic one that I would hand out to customers that didn’t have one so that they could start building from it. In the case of the thick hypervisor, think “security 101”. If it doesn’t support or secure VMs, it probably doesn’t belong on the server. Essentially do a package dump and a service listing. Justify every package and every service. If you can’t justify it, disable and/or remove it. It’s as simple as that. And I mean really justify it. Not “well, I might need it to do X one day”. If it’s a utility that can be done offline or on a host behind the DMZ, then that is where it should be done.

Adding Hypervisors to RHEV

This is Seriously Easy stuff, folks. Here were my steps:

  1. Install RHEL 7.2
  2. Register server to Red Hat
  3. Update all installed packages
  4. Log into RHEV-M
  5. Add RHEL server to RHEV Data Center and RHEV Cluster

The video covers how to add the installed server to RHEV. Here’s the demo (best viewed in full screen mode):

That’s it. So why does it get its own post? Honestly, because adding the hypervisor is the first security cornerstone and it’s also required before we do anything else in the environment. We can’t add storage without a hypervisor, we can’t provision VMs without storage, etc.

Hope this helps

Captain KVM

Agree? Disagree? Something to add to the conversation?