VMware ESXi and vSphere Cluster Management

Configure Per-VM Restart Priority with vSphere HA VM Overrides

Learn how to configure VMware vSphere HA VM Overrides, set per-VM restart priority, and verify exceptions to cluster-wide recovery settings.

vSphere HA is VMware's high-availability capability for helping recover virtual machines when an ESXi host fails. By default, HA behavior is configured at the cluster level. A VM Override is a virtual-machine-specific exception to an HA setting that would otherwise be inherited from the cluster.

VM Overrides are useful when one workload needs different recovery behavior from the rest of the cluster. This lesson focuses on overriding VM restart priority, while also describing another setting that can be overridden: the host isolation response.

Prerequisites

  • Basic vSphere inventory navigation
  • Familiarity with vSphere clusters and ESXi hosts
  • vSphere HA enabled and configured on the target cluster
  • Knowledge of application dependencies and workload business criticality
  • Permission to modify cluster HA settings

Cluster Defaults and VM Overrides

A cluster is a collection of ESXi hosts managed together for services such as vSphere HA. HA settings normally apply to all virtual machines in that cluster. The setting applied at this level is the cluster default: the normal HA behavior used unless a VM has a specific exception.

For example, a cluster might use Medium as its default VM restart priority. Every VM without an override follows that policy. If you add a VM Override for one VM and set its priority to Low, that VM uses Low instead of Medium. The VM-specific setting takes precedence over the corresponding cluster default.

Setting scope — Configured restart priority — Affected virtual machines — Effective behavior

Cluster default — Medium — All VMs without an override — VMs normally use Medium during HA recovery

VM Override — Low — The selected VM only — The selected VM uses Low and does not inherit the cluster's Medium priority

What VM Restart Priority Means

VM restart priority is the relative importance vSphere HA uses when deciding the order in which virtual machines should be restarted after a host failure. It does not make a VM restart faster, guarantee a specific start time, or provide application-level dependency management. It expresses relative recovery importance.

A higher-priority workload is considered before a lower-priority workload during HA restart processing. A VM assigned Low priority can therefore be restarted after more important VMs, such as workloads using the cluster's Medium or higher priority. The exact recovery sequence can also depend on available host resources, admission control, VM configuration, and other HA conditions.

vSphere versions and interfaces can present several priority choices. Low and Medium are commonly relevant values; some versions also provide higher or additional levels. Use the choices displayed by your vSphere Web Client and apply them consistently with your recovery plan.

Choose priority based on application dependency and business criticality, not merely on the apparent size of a VM. A small database, authentication service, or message broker may be more important to application recovery than a large but noncritical reporting VM.

Host Isolation Response as an Override-Capable Setting

Host isolation response is the action associated with an ESXi host becoming isolated from the management network. Depending on the vSphere configuration and version, the VM Overrides area can be used to adjust this behavior for an individual VM as well as other per-VM HA settings.

Host isolation response is separate from restart priority. Keep the procedure below focused on restart priority, and change isolation behavior only after evaluating network design, datastore access, application clustering, and the risk of duplicate workloads.

Navigate to VM Overrides

  1. In the vSphere Web Client, select the target cluster in the inventory.
  2. Open the cluster's management area, commonly labeled Manage.
  3. Open Settings.
  4. Locate and open VM Overrides.
  5. Review existing overrides before adding a new one.
  6. Choose Add to open the add-override workflow.

Interface labels can vary slightly between vSphere releases, but the workflow remains cluster selection followed by cluster management settings and VM Overrides.

Add a VM Override for Restart Priority

  1. Open the add-override workflow from the cluster's VM Overrides section.
  2. Use the VM selection control to find and select the individual virtual machine.
  3. Confirm that the selected VM is the intended workload before changing any values.
  4. Locate the VM restart priority setting.
  5. Set the priority to the required value, such as Low.
  6. Leave other settings at their inherited or intended values unless the workload also requires another exception, such as a different host isolation response.
  7. Confirm and save the override.
Cluster: Production-HA
Cluster default VM restart priority: Medium
VM Override: Reporting-VM
VM-specific restart priority: Low

After saving, the selected VM no longer uses the cluster default for restart priority. Other VMs continue to use the cluster default unless they have their own overrides.

Example: Medium Cluster Default and Low VM Override

Assume a production cluster has a cluster-wide default restart priority of Medium. Most application, database, and infrastructure VMs should use that baseline. A noncritical reporting VM can be configured with a Low VM Override.

Workload type — Cluster default or override — Restart priority — Rationale

Core application service — Cluster default — Medium — Receives the standard recovery preference

Database service — Cluster default — Medium — Remains part of the normal application recovery baseline

Reporting VM — VM Override — Low — Can restart after more important production workloads

During HA recovery, workloads using the Medium cluster default receive preference over the reporting VM configured with Low. This preserves a common policy for most VMs while making a justified exception for a less important workload.

Planning a Maintainable Priority Policy

Classify workloads before assigning priorities

  • Critical: Services required for core business operation or for starting other applications.
  • Supporting: Services that are important but can recover after core services.
  • Noncritical: Workloads that can tolerate delayed recovery, such as test, reporting, or batch systems.

Account for dependencies

Map application dependencies before setting priorities. Starting a web server before its database, identity provider, storage service, or message queue may not produce a usable application. VM restart priority provides relative ordering, but it is not a complete dependency orchestration system. Validate whether the selected priorities support the order in which services become useful.

Prefer a clear baseline with few exceptions

Review the existing cluster-level HA defaults before adding overrides. If most VMs require a different policy, changing the cluster default may be clearer than creating many VM-specific exceptions. Use overrides only for genuine workload differences, and document the business or dependency reason for each exception.

Record the decision

For each override, record the VM name, selected setting, date, owner, reason, related application dependency, and review date. Documentation helps operators understand why a VM differs from the cluster baseline and prevents accidental removal of an important exception.

Verify the Configuration

  1. Return to the cluster's VM Overrides list.
  2. Confirm that the intended VM appears in the list.
  3. Check that the displayed restart priority is the planned value.
  4. Compare the VM-specific value with the cluster default.
  5. Confirm that the override is attached to the correct VM, especially if names are similar.
  6. Review any other settings shown for the override, including host isolation response, to ensure they were not changed unintentionally.

For the example policy, verification should show the cluster default as Medium and the selected reporting VM with a Low restart priority. Standard VMs without overrides should continue to inherit Medium.

Troubleshooting

The intended VM does not appear in the selection dialog

  • Confirm that the correct cluster is selected.
  • Confirm that the VM currently belongs to that cluster.
  • Check inventory visibility and administrative permissions.
  • Refresh the inventory view if the VM was recently moved into the cluster.

The VM still uses an unexpected restart priority

  • Review the cluster-wide default restart priority.
  • Confirm that the override was saved for the correct VM.
  • Check whether an existing override already defines a different effective value.
  • Reopen the VM Overrides list after saving and verify the displayed setting.

Too many exceptions make the policy difficult to understand

  • Reassess whether the cluster default should be changed.
  • Remove overrides that no longer represent a real workload requirement.
  • Retain overrides only for genuine exceptions.
  • Document the business or application-dependency reason for every remaining override.

Exam-Relevant Notes

  • vSphere HA settings normally apply at the cluster level.
  • A VM Override is an exception for a selected virtual machine.
  • A VM-specific restart priority takes precedence over the corresponding cluster default.
  • Low priority means the VM may be restarted after more important workloads during HA recovery.
  • Host isolation response is another HA behavior that may be configurable through VM Overrides.
  • Restart priority expresses relative importance; it does not guarantee a precise restart sequence or application readiness.

For related configuration work, review vSphere HA VM Overrides and apply the same baseline-versus-exception approach to other per-VM HA settings.