VMware ESXi and vSphere Cluster Management

Configure Per-VM vSphere HA Restart Priority Overrides

Learn how to configure, edit, remove, and validate per-VM vSphere HA overrides for restart priority and host isolation response.

VMware vSphere High Availability (vSphere HA) normally applies recovery behavior at the cluster level. A cluster default is appropriate for most workloads, but not every virtual machine has the same recovery importance or isolation requirements.

A VM Override is a per-virtual-machine setting that supersedes an applicable vSphere HA cluster default. For example, you can assign a critical application VM a higher restart priority, give a development VM a lower priority, or configure a different host isolation response when the workload requires it.

What VM Overrides Do

vSphere HA detects certain ESXi host failures and attempts to recover affected VMs on surviving hosts. This recovery is a failover: the VM is restarted elsewhere rather than continuing execution from the exact point at which it was running.

Cluster HA settings provide the normal policy for the VMs in that cluster. VM Overrides let you create justified exceptions without changing the behavior of every workload. They are useful when:

  • A business-critical application component should be considered earlier during recovery.
  • A development, test, or low-impact utility VM can wait until more important workloads are restarted.
  • A workload has special storage, data-consistency, or availability requirements during host isolation.
  • A temporary exception is required during a controlled migration or operational change.

Overrides should be deliberate and documented. Keep the cluster default suitable for the majority of VMs, and reserve per-VM settings for exceptions with a clear business reason and an identified owner.

Cluster Defaults Versus Per-VM Settings

A cluster default is the HA setting applied broadly to VMs in the cluster. If a VM has no explicit override, it inherits that default. If an explicit VM Override exists, the VM-specific value takes precedence for the setting covered by the override.

For example, if the cluster default restart priority is Medium, most VMs use Medium automatically. A VM with a Low override uses Low instead, while a VM with no override continues using Medium.

Setting: VM restart priority

Configured at cluster level: Yes. Set the normal priority for VMs in the cluster.

Can be overridden per VM: Yes, when supported by the applicable vSphere version.

What the override changes: The selected VM's relative position in HA restart sequencing.

Key caution: Priority does not guarantee successful or immediate recovery; capacity, storage, networking, admission control, and other dependencies still apply.

Setting: Host isolation response

Configured at cluster level: Yes. The cluster defines the normal action for VMs when their host is considered isolated.

Can be overridden per VM: Supported in applicable vSphere versions and configurations.

What the override changes: The selected VM's action when its host is isolated, rather than confirmed to have failed.

Key caution: An incorrect action can create availability, storage, or data-consistency problems. Test and approve changes before production use.

Understanding VM Restart Priority

VM restart priority is the relative importance assigned to a VM for HA restart sequencing after a host failure. It controls which VMs vSphere HA attempts to restart earlier or later compared with other affected VMs.

Depending on the vSphere version and applicable configuration, the client may present choices such as:

  • High: Attempt recovery earlier than normal-priority VMs.
  • Medium: The normal or general-purpose priority for many workloads.
  • Low: Attempt recovery after higher-priority workloads.
  • Disabled: Do not automatically restart the VM through the applicable HA restart policy, where this option is available.

Exact labels and available choices can vary between vSphere releases. Always use the values displayed by your vSphere client.

Planning priorities

VM category: Critical application component

Cluster default or override: VM-specific override

Assigned priority: An appropriate higher priority, if justified

Reason: Recover an important application tier earlier than ordinary workloads.

Dependency considerations: Confirm database, storage, network, licensing, and application startup dependencies. Earlier VM boot does not necessarily mean earlier application readiness.

VM category: General production VM

Cluster default or override: Cluster default

Assigned priority: Medium, or the approved cluster standard

Reason: Use the policy intended for the majority of workloads.

Dependency considerations: Verify adequate failover capacity and access to required datastores and networks.

VM category: Development or noncritical utility VM

Cluster default or override: VM-specific override

Assigned priority: Low

Reason: Allow more important workloads to be attempted first.

Dependency considerations: Confirm that delayed recovery is acceptable and that the VM does not provide a service required by higher-priority systems.

Host Isolation Response Overrides

Host isolation occurs when an ESXi host loses management-network communication with the HA cluster while it may still be running its workloads. A host isolation response is the configured action for a VM when HA considers its host isolated.

Isolation is different from a confirmed host failure. In a host failure, the host is generally unavailable and HA attempts to restart affected VMs on surviving hosts. During isolation, the original host might still be running the VM. An inappropriate response can therefore cause duplicate execution, interrupt a workload unnecessarily, or create storage and data-consistency risks.

Some workloads may need isolation behavior different from the cluster standard. For example, a workload with special storage semantics or an application that cannot tolerate duplicate execution may require a carefully reviewed policy. Configure a per-VM isolation response only when its consequences are understood, supported by the vSphere version, and approved for the workload.

Review management-network redundancy, datastore heartbeats, storage access, and application behavior before changing isolation policy. Use a controlled test environment or an approved maintenance window to validate the result.

Add a VM Override in the vSphere Client

  1. Select the target cluster in the vSphere inventory.
  2. Open the cluster's management or configuration settings.
  3. Open the vSphere HA VM Overrides section. Exact tab names can vary by vSphere client version.
  4. Choose the command to add a new override entry.
  5. In the VM selection dialog, select the target virtual machine and confirm the selection.
  6. Set the desired restart priority, such as High, Medium, Low, or Disabled where available.
  7. Configure any other supported per-VM HA settings, including a host isolation response if the option is available and approved.
  8. Save the change.
  9. Return to the VM Overrides list and confirm that the VM appears with the intended settings.

The standard workflow requires no ESXi shell command. The general configuration sequence is:

Enable and configure vSphere HA at the cluster level
Set an appropriate cluster-wide restart-priority default
Add the VM to the VM Overrides list
Choose the VM-specific restart priority and supported isolation options
Save the change and verify the override

Edit or Remove an Override

Edit an existing override

  1. Open the cluster management or configuration settings.
  2. Navigate to the vSphere HA VM Overrides list.
  3. Select the existing VM entry.
  4. Choose the edit action and change the restart priority or other supported setting.
  5. Save the change, then verify the updated value in the list.

Remove an override

  1. Open the VM Overrides list for the correct cluster.
  2. Select the VM-specific entry.
  3. Choose the remove or delete action and confirm the operation.
  4. Verify that the entry is no longer listed.

Removing the override does not remove the VM from the cluster. It returns the VM to the cluster-level HA configuration, so the VM inherits the cluster default and other applicable cluster settings again.

Validation and Recovery Planning

  • Confirm that vSphere HA is enabled and healthy for the cluster before expecting HA recovery behavior.
  • Review the VM Overrides list after saving to verify the target VM and selected values.
  • Check that the VM is actually associated with the selected cluster.
  • Review HA tasks, events, alarms, and failed restart details after a test or actual failure.
  • Use an approved maintenance window and failure-testing procedure when validating host-failure or isolation behavior.
  • Confirm that surviving hosts have enough CPU and memory and that admission control permits the planned failover.
  • Verify datastore availability, network access, VM configuration compatibility, and required external services.
  • Document application startup order and dependencies. Restart priority only sequences VM recovery; it does not orchestrate databases, middleware, DNS, licensing, or application readiness.

For capacity planning, review HA admission-control policies. For isolation diagnosis, see datastore heartbeating. For planned host work, use maintenance mode and appropriate migration procedures instead of treating planned maintenance as an HA failure test.

Practical Examples

Lower priority for a noncritical VM

The cluster default is Medium. Add a development VM or low-impact utility VM to VM Overrides and assign Low. That VM is treated as lower priority during HA restart sequencing, while VMs without overrides continue using Medium.

Higher priority for a critical component

Most workloads use the cluster default, but a business-critical application tier requires earlier recovery. Assign an appropriate higher per-VM priority after confirming its dependencies and available failover capacity. HA considers it earlier, subject to resource and recovery constraints.

Return a VM to the standard policy

A VM no longer needs special treatment. Remove its VM Override entry. The VM then inherits the cluster-wide restart priority and other applicable HA defaults.

Use different isolation handling

A special workload has requirements that justify an isolation response different from the cluster standard. Configure the supported per-VM isolation override only after reviewing duplicate execution, storage access, network partitioning, and application behavior. Validate it in a controlled procedure before changing production behavior.

Troubleshooting VM Overrides

The VM does not appear in the selection dialog

  • Confirm that the correct cluster is selected.
  • Verify the VM's current host and cluster placement.
  • Check that your permissions allow you to view and modify the VM and cluster HA settings.
  • Refresh the inventory and reopen the add-override dialog.

The restart priority change has no apparent effect

  • Review the VM Overrides list to confirm that the change was saved.
  • Confirm that the entry belongs to the intended VM and cluster.
  • Check that the VM has an active override rather than relying on the cluster default.
  • Confirm that vSphere HA is enabled and functioning for the cluster.
  • Review recent tasks, events, and HA alarms.

A High-priority VM was not restarted as expected

  • Review HA events and failed restart tasks.
  • Check surviving-host CPU and memory capacity and the HA admission-control policy.
  • Verify access to the VM's datastore and required networks.
  • Check VM configuration, compatibility, and other placement constraints.
  • Determine whether the VM restarted but its application remained unavailable because dependencies or startup order were not ready.

An isolation response produced an unexpected application result

  • Determine whether the event was host isolation or confirmed host failure.
  • Compare the cluster isolation policy with the VM-specific override.
  • Investigate management-network connectivity and datastore-heartbeat conditions.
  • Assess the workload's sensitivity to duplicate execution, storage access, and network partitioning.
  • Test the policy in a controlled environment before changing production behavior.

Exam-Relevant Notes

  • A VM Override is an exception to an applicable cluster HA default.
  • A VM with no override inherits the cluster-level setting.
  • Restart priority controls relative restart order after host failure; it does not guarantee successful recovery.
  • Admission control and surviving-host capacity can prevent or limit restart even for a High-priority VM.
  • Host isolation is not the same event as confirmed host failure.
  • Removing a VM Override returns the VM to the cluster policy.
  • Application readiness and dependency recovery require planning beyond VM restart priority.