Purpose

Cloudstack relies on custom HA logic for user VMs running on Xenserver. The reason for doing it like this may be due the fact that native HA capabilities in XS was not mature enough during the initial days. Also in the custom HA logic, Cloudstack has to correctly determine the state of a VM from the hypervisor before it can take any action. In case there are any issues in determining the state, HA mechanism can get impacted. Since the hypervisor best knows the state of the VM it is a better approach to rely on native HA capabilities.

Suggested change

Leverage native HA capabilities for user VM HA for Xenserver 6.2 and above. For sake of backward compatibility the earlier option will be available as well and there will be a choice to use any one option. For older versions of XS (prior to 6.2) there is no change. HA for system VMs would still be based on application logic.

Prereqs

XS clusters needs to be configured for HA outside of Cloudstack. Without this HA for user VMs will not work. Earlier this was not required as HA was managed by Cloudstack. Refer to XS 6.2 admin guide 1 for setting up HA enabled clusters.

Impacted scenarios

• User VMs created with HA enabled service offering will now be HAd using native XS HA (provided that option is chosen using global setting).
• VM sync. will no longer do any operations on VM based on state mismatch, only the database state will be updated based on the state reported by HV.

Non-impacted scenarios

• Host maintenance would still be based on Cloudstack logic where all HA enabled VMs will get migrated to another host.

Changes

• VM creation logic will be modified for XS 6.2 and above. For HA enabled VMs, the ha-restart-priority on the VM will be set to restart. For non-HA VMs it is not set.
• Global config to enable native XS HA capabilities. If not the

Jira ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-5203

1 http://support.citrix.com/servlet/KbServlet/download/34969-102-704897/reference.pdf (refer section 3.8)