Chapter 7. Virtualization and High Availability
Various virtualization platforms are supported in conjunction with Red Hat Enterprise Linux 6 using the High Availability and Resilient Storage Add-Ons. There are two supported use cases for virtualization in conjunction with Red Hat Enterprise Linux High Availability Add-on.
This refers to RHEL Cluster/HA running on bare metal hosts that are themselves usable as virtualization platforms. In this mode you can configure the cluster resource manager (rgmanager) to manage virtual machines (guests) as highly available resources.
7.1. VMs as Highly Available Resources/Services
Both RHEL HA and RHEV provide mechanisms to provide HA virtual machines. Given the overlap in functionality, care should be taken to chose the right product to fit your specific use case. Here are some guidelines to consider when choosing between RHEL HA and RHEV for providing HA of VMs.
For Virtual machine and physical host counts:
If a large number of VMs are being made HA across a large number of physical hosts, using RHEV may be the better solution as it has more sophisticated algorithms for managing VM placement that take into consideration things like host CPU, memory and load information.
If a small number of VMs are being made HA across a small number of physical hosts, using RHEL HA may be the better solution because less additional infrastructure is required. The smallest RHEL HA VM solution needs two physical hosts for a 2 node cluster. The smallest RHEV solution requires 4 nodes: 2 to provide HA for the RHEVM server and 2 to act as VM hosts.
There is no strict guideline for how many hosts or VMs would be considered a 'large number'. But keep in mind that the maximum number of hosts in a single RHEL HA Cluster is 16, and that any Cluster with 8 or more hosts will need an architecture review from Red Hat to determine supportability.
Virtual machine usage:
If your HA VMs are providing services that are used are providing shared infrastructure, either RHEL HA or RHEV can be used.
If you need to provide HA for a small set of critical services that are running inside of VMs, RHEL HA or RHEV can be used.
If you are looking to provide infrastructure to allow rapid provisioning of VMs, RHEV should be used.
RHEV VM HA is meant to be dynamic. Addition of new VMs to the RHEV 'cluster' can be done easily and is fully supported.
RHEL VM HA is not meant to be a highly dynamic environment. A cluster with a fixed set of VMs should be set up and then for the lifetime of the cluster it is not recommended to add or remove additional VMs
RHEL HA should not be used to provide infrastructure for creating cloud-like environments due to the static nature of cluster configuration as well as the relatively low physical node count maximum (16 nodes)
RHEL 5 supports two virtualization platforms. Xen has been supported since RHEL 5.0 release. In RHEL 5.4 KVM was introduced.
RHEL 6 only supports KVM as a virtualization platform.
RHEL 5 AP Cluster supports both KVM and Xen for use in running virtual machines that are managed by the host cluster infrastructure.
RHEL 6 HA supports KVM for use in running virtual machines that are managed by the host cluster infrastructure.
The following lists the deployment scenarios currently supported by Red Hat:
RHEL 5.0+ supports Xen in conjunction with RHEL AP Cluster
RHEL 5.4 introduced support for KVM virtual machines as managed resources in RHEL AP Cluster as a Technology Preview.
RHEL 5.5+ elevates support for KVM virtual machines to be fully supported.
RHEL 6.0+ supports KVM virtual machines as highly available resources in the RHEL 6 High Availability Add-On.
RHEL 6.0+ does not support Xen virtual machines with the RHEL 6 High Availability Add-On, since RHEL 6 no longer supports Xen.
For updated information and special notes regarding supported deployment scenarios, refer to the following Red Hat Knowledgebase entry:
The types of virtual machines that are run as managed resources does not matter. Any guest that is supported by either Xen or KVM in RHEL can be used as a highly available guest. This includes variants of RHEL (RHEL3, RHEL4, RHEL5) and several variants of Microsoft Windows. Check the RHEL documentation to find the latest list of supported guest operating systems under each hypervisor.
7.1.1. General Recommendations
In RHEL 5.3 and below, rgmanager utilized the native Xen interfaces for managing Xen domU's (guests). In RHEL 5.4 this was changed to use libvirt for both the Xen and KVM hypervisors to provide a consistent interface between both hypervisor types. In addition to this architecture change there were numerous bug fixes released in RHEL 5.4 and 5.4.z, so it is advisable to upgrade your host clusters to at least the latest RHEL 5.5 packages before configuring Xen managed services.
For KVM managed services you must upgrade to RHEL 5.5 as this is the first version of RHEL where this functionality is fully supported.
Always check the latest RHEL errata before deploying a Cluster to make sure that you have the latest fixes for known issues or bugs.
Mixing hosts of different hypervisor types is not supported. The host cluster must either be all Xen or all KVM based.
Host hardware should be provisioned such that they are capable of absorbing relocated guests from multiple other failed hosts without causing a host to overcommit memory or severely overcommit virtual CPUs. If enough failures occur to cause overcommit of either memory of virtual CPUs this can lead to severe performance degradation and potentially cluster failure.
Directly using the xm or libvirt tools (virsh, virt-manager) to manage (live migrate, stop. start) virtual machines that are under rgmanager control is not supported or recommended since this would bypass the cluster management stack.
Each VM name must be unique cluster wide, including local-only / non-cluster VMs. Libvirtd only enforces unique names on a per-host basis. If you clone a VM by hand, you must change the name in the clone's configuration file.
