Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0


  1. Leverage native HA capabilities for user VM HA for XS 6.2 and above. For sake of backward compatibility the existing option will also be available and a choice will be given to use any one. Once a specific option is chosen and VMs deployed, it shouldn't be changed as it can have undesired consequences. This essentially means there is no mixed mode support where in a cluster has some VMs using native HA and some using CS custom HA. For older versions of XS (prior to 6.2) there is no change. HA for system VMs would still be based on application logic.
  2. The hack for rebooting host (check script) in case of primary-storage(PS) failure will be removed as CS no longer needs to take any actions on user VMs as part of HA.
    1. Wiki MarkupThis will fix the problem described in \ [2\].

Jira ticket


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

Impacted scenarios

  1. User VMs created with HA enabled service offering will now be HAd using native XS HA (provided that option is chosen using global setting).
    1. Note: HA enabled VM deployment would still succeed even if HA is not configured in XS cluster.
  2. VM sync. will no longer do any operations on user VMs based on state mismatch, only the database state will be updated based on the state reported by HV.


For system VMs there is already application logic to do HA. Some of them will be enhanced further.


  1. SSVM/CPVM: These are monitored on a regular basis. If these are found to be stopped then the monitoring application restarts them, and if not found then recreated. In case the agent running on these VMs is not responding then only the agent state is updated to 'Disconnected' in the database but nothing else is done. Even in this case a new VM needs to be started. Created a bug for this \for this [3\].
  2. VR: For virtual router HA, the recommended way is to use redundant VR (RVR) functionality.


  1. Native HA needs to configured on the cluster.
  2. HA enabled user VMs must be manually modified to set the ha-restart-priority to restart.

Wiki Markup\[1\] [] (refer section 3.8)unmigrated-wiki-markup

\[2\] [] Wiki Markup

\[3\] []