4. High Availability - Virtual Machine Interruption
In the previous section, you demonstrated virtual machine high availability when a host becomes non-responsive and then rebooted. This section simulates a virtual machine crash. The expected outcome is for the highly available virtual machines to restart automatically, while the non-highly available ones will remain shut down until they are manually restarted.
In your current environment, the host that you restarted in the previous section (Atlantic
) should be running again. The highly available virtual machine (RHEL6Thames
) has been restarted on another host (Pacific
), while the non-highly available virtual machine (RHEL6Congo
) is still powered down.
For this demonstration, restart RHEL6Congo
. The Atlantic
host is automatically selected to run this virtual machine as its workload is currently lighter than Pacific
's. Next, live migrate two more virtual machines to the Atlantic
host so the workload is equally balanced. Select RHEL6RioGrande
and RHEL6Thames
, and click Migrate. On the Migrate Virtual Machine(s) dialog, leave the option as Select Host Automatically and click OK.
To recap, you now have three virtual machines running on each host. Click on the
Host label to sort the virtual machines according to host in alphabetical order.
To demonstrate virtual machine high availability when its process is killed
To simulate a virtual machine crash, you have to terminate the virtual machine's process from within its host. This example uses the Atlantic
host, and provides instructions for remote access to both hypervisor and Linux hosts.
If you are using a Red Hat Enterprise Virtualization Hypervisor host, you must first enable remote login. On the hypervisor management console, navigate to the Security tab and tick the Enable ssh password authentication checkbox. Enter your password in the fields listed, then click Apply.
Note that SSH login to the hypervisor is not recommended for security reasons, however to best demonstrate the procedures in this lab, enable remote login temporarily. Once you are done with this lab you can disable SSH login to the hypervisor.
To log in to the hypervisor via SSH, open a terminal and run:
# ssh admin@atlantic.demo.redhat.com
Accept the authentication key and enter the password for the hypervisor. When you are on the management console, press the
F2
key and select
Drop to Shell. You can now perform commands as the root user.
If you are using a Red Hat Enterprise Linux host, by default you can log in remotely to your host. Open a terminal and run:
# ssh root@atlantic.demo.redhat.com
Accept the authentication key and enter the password for the host.
Once you have established a remote connection to your host, you can use the vdsClient utility which directly accesses the Red Hat Enterprise Virtualization Manager daemon that runs within the hosts. Run:
[root@atlantic ~]# vdsClient -s 0 list table
This lists the GUID, process id, name and status of each virtual machine on the host. For example:
6aba36aa-d0a9-4d51-bcf3-73544bc95964 2783 RHEL6Congo Up
6f8bd3cc-3c54-413a-9a28-0bd2f65eeede 3341 RHEL6RioGrande Up
4e1e0e4f-63e1-4a24-b1a6-76d7ae46e8c4 3015 RHEL6Thames Up
Send the termination signal to two virtual machines - one which is highly available, and one which is not. This example uses RHEL6RioGrande
and RHEL6Congo
.
[root@atlantic ~]# kill -9 3341
[root@atlantic ~]# kill -9 2783
You have now simulated an environment where a virtual machine has unexpectedly crashed, and is inaccessible to users.
Back on the administration portal on the Virtual Machines tab, you can see that RHEL6RioGrande
's status is Powering Up. As it was marked as highly available, it instantly restarts when it experiences a crash.
In contrast, the status of RHEL6Congo
remains at Down because it had not been marked as highly available. It remains turned off until it is manually restarted.
This demonstrates that if the virtual machine process is interrupted — whether due to user error, insufficient memory on hosts or other issues — highly available virtual machines will be restarted, while non-highly available ones require manual input. Therefore, if your environment has machines which must be accessible at all times, it is good practice to configure them as highly available, so they will automatically restart if they experience unexpected interruptions.