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

 

6 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

  2. Hi CaptainKVM,

    I know is not relevant to to subject after lot of search did not found answer knocking you drop..

    We are running Ovirt3.8 version in our prod, we want to upgrade to 3.8 to
    4.2.
    At present we have 2 (hyp A & hyp B)physical host ovirt 3.8 is running with
    self hosted engine with data domain and iso one cluster and data center.
    What we were thing do this migration in following fashion.
    Plan A.
    1. Attach export domain present infra.
    2. Take backup all of running vm as export.
    3. Detach export domain
    4. Detach hyp B from cluster and data center
    5. Install fresh ovirt 4.2 iso on hyp B
    6. Install self hosted engine
    7. Attach Data Domain
    8. Attach Export Domain which was use in ovirt 3.8
    9. Import all vm’s from there to new ovirt 4.2
    10. Once all the vm’s got up and running poweroff hyp A
    11. Install fresh ovirt 4.2 iso on hyp A and attach cluster.

    Plan B.
    1. Attach export domain present infra.
    2. Take backup all of running vm as export.
    3. Detach export domain
    4. Detach hyp B from cluster and data center
    5. Install fresh ovirt 4.2 iso on hyp B
    6. Install self hosted engine
    7. Attach Data Domain
    8. Export from ovirt 3.8 to ovirt 4.2
    9. Once all the vm’s got up and running poweroff hyp A
    10. Install fresh ovirt 4.2 iso on hyp A and attach cluster.

    Thank a ton in advance we may be wrong with above step help us to win this
    migration.

    Regards
    Techieim
    techieim@gmail.com

    1. Hi Techieim,

      It’s been a long time since I did work in the upstream oVirt. However, Plan A looks better. I would post the options in the oVirt list to be sure.

      Captain KVM

Agree? Disagree? Something to add to the conversation?