RHEV Clustering and RHEL Hypervisors Installation – Part 5

In this part we are going to discuss some important points related to our RHEV series. In Part-2 of this series, we’ve discussed RHEV Hypervisor deployments and installations. In this part we will discuss another ways to install RHEV Hypervisor.

The First way was done by using dedicated RHEVH which customized by RedHat itself without any modification or change from admin side. The other way, we will use a normal RHEL server [Minimal installation] that will act as a RHEV Hypervisor.

Virtual Machine Specification

and make sure you checked the virtualization option in vm processor settings.

Hint : Make sure your system is subscribed to redhat channels and up-to-date, if you don’t know how to subscribe to redhat subscription channel, you may read the article Enable Red Hat Subscription Channel.

Tip : To save your resources you can shutdown one of the both currently up and running hypervisors.

2. To turn your server into hypervisor {use it as a hypervisor} you may need install the RHEVM agent on it.

The main advantage of clustering in RHEV is to enable and manage virtual machines migration between hosts that belong to the same cluster.

So, How virtual machines migrate between hosts ?

RHEV has two strategies:

1. Live Migration2. High Availability

1. Live Migration

Live Migration used in non-critical situation which mean everything is working fine in general but you have to do some load balancing tasks (e.g. you found there is host is loaded by virtual machine over another. So, you may Live migrate virtual machine from host to another to achieve load balancing).

Note : There is no interruption to services, application or users running inside VM during Live Migration. Live migration also called as resources re-allocation.

Live migration can be processed manually or automatic according to pre-defined policy:

Manually: Force selecting the the destination host then migrate VM to it manually using WUI.

Automatic : Using one of Cluster policies to manage Live migration according to RAM usage, CPU utilization, etc.

Switch to Clusters tab and select Cluster1 the click on edit.

Clustering Tab

From window tabs, switch to Cluster Policy tab.

Cluster Policy

Select evenly_distributed policy. This policy allows you to configure Max threshold for CPU utilization on the host and the allowed time for the load before starting Live migration.

Hint

As shown I configured the max threshold to be 50% and duration to be 1 min.

1. From Host tab : Check Manual and Automatic Live Migration is allowed for this VM.

Cluster Migration Options

2. From HA tab : Check the Priority degree of your virtual-machine. In our case, its not very important as we are playing with only one vm. But it will be important to set priorities for your vms in large environment.

Cluster VM Priorities

Then start Linux VM.

First, we will use the Manually Live Migration. Linux VM in now running on rhel.mydomain.org.

Linux VM Status

Lets run the following command over vm console, before starting migration.

# ls -lRZ /

Then select Linux VM and click Migrate.

Linux VM Migrate

If you select automatically, system will check the most responsible host to be destination under the cluster policy. We will test this without any interference from administrator.

Migrate Virtual Machines

So, after selecting manually and choose the destination, Click OK and go to console and monitor the running command. You can also check the vm status.

Monitor VM Status

You may need to monitor Task events.

Monitor Task Events

After a few seconds, you will find a change in he vm Hostname.

Confirm VM Changes

Your VM is manually Live migrated successfully !!

Lets try automatic Live Migration, our target is to make CPU Load on the rhevhn1 Host is exceeded 50%. We will do that by increasing the load on the vm itself, so from console write this command:

# dd if=/dev/urandom of=/dev/null

and monitor the load on Host.

Monitor VM Load

After few minutes, the load on Host will exceeds 50%.

VM Load Alert

Just wait another few more minutes then live migration will start automatically as shown.

VM Live Migration

You can also check the tasks tab, and after little waiting, your virtual machine is automatically Live Migrated to rhel Host.

Monitor VM

VM RHEL Migration

Important: Make sure that one of your hosts have resources more than the other one. If the two hosts are identical in resources. VM won’t be migrated because there will be no difference !!

Hint: Putting Host into Maintenance Mode will automatically Live Migration Up and running VM’s to other hosts in the same cluster.

Hint: Live Migration between different clusters isn’t officially supported expect one case you can check it here.

2. High Availability

In the against of Live Migration, HA is used to Cover Critical Situation not just load balancing tasks. The common section that your VM will also migrated to another host but with rebooting down time.

If you have Failure, Non-Operational or Non-responsive Host in your cluster, Live Migration Cannot help you. HA will power-off the virtual-machine and restart it on another up and running host in the same cluster.

To Enable HA in your environment, you must have at least one power management device [e.g. power switch] in your environment.

Remember: Live Migration and High Availability are working with hosts in the same cluster with same type of CPU and connected to shared Storage.

Conclusion:

We reached peak point in our series as we discussed one of the important features in RHEV Clustering as we described it and its importance. Also we discussed the second type [method] to deploy RHEV hypervisors which based on RHEL [at least 6.6 x86_64].

In next article, we will be able to make some operations on virtual-machines such as snapshots, sealing, cloning, exporting and pools.