Best Practices for RHV 4

Hi folks, one of the many things that I’ve been working on behind the scenes has finally seen the light of day: Best Practices for Red Hat Virtualization 4. This takes over where the product documentation leaves off.What I mean by that is this:

The product documentation is (mostly) great about telling you “how” to do the many activities related to deploying Red Hat Virtualization.

This new document tells you “why” to do many of the activities related to deploying Red Hat Virtualization. It does NOT have code examples, but it DOES have lots of things to consider. Things like:

  • “Standard” deployment or “Hosted Engine” deployment
  • RHEL host or RHV host
  • NAS or SAN
  • Lager or Ale (just kidding)

In other words, when you go to plan out your deployment, this is the document that you want to read before you paint yourself into a corner. Many of the items are best practices, like “don’t turn off SELinux”. Others are more considerations and implications, like “NAS or SAN”.

If this is something you’re interested in, you can download it here:

Best Practices for Red Hat Virtualization 4

Hope this helps,

Captain KVM

 

4 thoughts on “Best Practices for RHV 4”

  1. I found this really useful.

    You recommend that application data disks be accessed directly by the VM, separate from the os disk. For ISCSI would you recommend configuring the guest to connect to the SAN, or using a Direct LUN through the RHVM?

    Attaching a direct lun seems like it would be the simpler configuration (no iscsi config in guest, no extra networking config), but I wonder how it performs against guest direct access to the SAN.

    1. Hi Ryan,

      Thanks for stopping by.. That’s actually a fantastic question, and the answer really depends on the workload and the backup requirements. As with anything, I heavily recommend testing both for your particular application. If you just have a single LUN for the one application, then maybe Direct LUN is the way to go.. if you have several apps, then I would lean towards having a centralized storage device that hopefully offers snapshots and a centralized means of backups.. but again, test the performance for your needs.

      Captain KVM

Agree? Disagree? Something to add to the conversation?