Product SiteDocumentation Site

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.
Migrate virtual machines to Atlantic
Figure 50. Migrate virtual machines to Atlantic

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.
Sort virtual machines by host
Figure 51. Sort virtual machines by host

To demonstrate virtual machine high availability when its process is killed
  1. 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.
      Enable SSH on hypervisor
      Figure 52. Enable SSH on hypervisor

      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.
      Access hypervisor shell
      Figure 53. Access hypervisor shell

    • 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.
  2. 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
    
  3. 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.
  4. 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.