VMware ESXi and vSphere Cluster Management

Advanced Options in vSphere HA

Learn how to configure, validate, and troubleshoot vSphere HA advanced options for isolation detection, admission control, VM restart behavior, and datastore heartbeating.

vSphere High Availability (vSphere HA) is a cluster service that restarts virtual machines on surviving ESXi hosts after qualifying host failures. Standard HA controls cover common policies, while HA advanced options are cluster-level key/value pairs for specialized behavior.

Advanced options are powerful overrides, not a replacement for correct network design, capacity planning, or normal HA configuration. Supported keys and behavior can change between vCenter Server and ESXi releases. Verify every option against documentation for the exact installed version. An obsolete key, spelling error, or unsuitable value can change failover, isolation, admission-control, or restart behavior.

Prerequisites and change preparation

An existing vSphere cluster with vSphere HA enabled.
vCenter Server, because HA configuration is managed at the cluster level.
Permissions that allow editing the cluster configuration and vSphere HA settings. The exact privilege names depend on the vSphere release and assigned role.
Working knowledge of ESXi VMkernel management networking, shared datastores, and VM CPU and memory reservations.

Before changing an advanced option, record the current cluster HA settings and every existing key/value pair. Capture the intended value, reason, owner, validation plan, and rollback procedure. Use normal operational change control and schedule changes when an unexpected isolation response or admission-control change can be safely investigated.

Review admission control, vCenter and ESXi communication, and basic ESXi configuration before working with specialized settings.

Host failure and host isolation

A host failure is an outage or loss of availability that prevents an ESXi host from continuing to run its workloads normally. Host isolation is different: the host may still be powered on and running VMs, but it cannot communicate with expected management-network targets or other HA participants.

HA uses network heartbeats between hosts to assess connectivity and state. Datastore heartbeating provides additional evidence by using files on shared datastores. This distinction matters because a management-network partition can leave VMs running on an isolated host while other hosts believe communication has been lost. HA must avoid treating that situation as an ordinary host failure and unnecessarily restarting the same VMs elsewhere.

Condition	Host network reachability	Datastore heartbeat evidence	Likely HA interpretation	Potential VM action	Administrative response
Host failure	Host and its HA communication are unavailable	Usually no current evidence from the failed host	Host is likely down	Restart eligible VMs on surviving hosts	Check hardware, power, ESXi, and management events
Host isolation	Host cannot reach expected network targets, but may still be running	Heartbeat files may show that the host is active	Network partition or isolated host	Depends on isolation response and effective VM settings	Check management VLANs, routes, gateways, firewalls, and storage visibility
Network partition with incomplete evidence	Communication is lost along one or more paths	Evidence may be unavailable or inconsistent	Requires careful HA state evaluation	Isolation response or restart behavior may occur	Review HA events and correct network and storage resiliency

Isolation addresses

An isolation address is an IP target that an ESXi host checks to help determine whether it is isolated from the network. The primary advanced-option key is das.isolationaddress. Additional targets use the numbered pattern das.isolationaddressN, such as das.isolationaddress1, when that pattern is supported by the installed release.

Choose targets that are reliable, reachable through the management network from every host, and outside the host itself. A reachable gateway or another resilient network endpoint is commonly used when it is appropriate for the network design. Do not choose a target whose availability depends on the same host, switch path, or failed management component that the test is intended to detect.

Candidate target	Reachable from every host	Independent of host failure domain	Highly available	Suitable for IPv4/IPv6 design	Recommendation
Resilient upstream gateway	Must be verified	Usually, if network paths are redundant	Preferable	Use an address family supported by the deployed release	Recommended when validated
Another host in the same cluster	May be reachable	Often not independent	May fail with the same partition	Validate carefully	Usually avoid as the sole target
Address on the local ESXi host	Appears reachable locally	No	No	Not a useful isolation test	Avoid
Single device behind the affected management path	May become unreachable	No	Depends on one path	Validate routing and address family	Avoid as the only target

das.usedefaultisolationaddress controls use of the default isolation-address behavior where the option is supported. If the environment requires only explicitly defined targets, disabling default behavior may be appropriate, but the exact syntax and effect must be checked for the deployed release. Validate both IPv4 and IPv6 routing, VMkernel bindings, firewall rules, and target reachability when IPv6 is used.

Configure an advanced option in the vSphere Client

Select the target cluster in the inventory.
Open the cluster configuration or settings view.
Open the vSphere HA settings and choose to edit the HA configuration.
Expand the advanced-options section or advanced-options editor.
Add a key and value. For example, use das.isolationaddress with an environment-specific address such as 192.0.2.1. This address is illustrative only and must be replaced with a reachable target.
Save the cluster configuration and wait for HA reconfiguration to complete.
Reopen the editor and confirm that the entry persists. Check cluster health, tasks, events, and alarms.

To edit an entry, select the key/value pair and change its value, then save and wait for reconfiguration. To remove an entry, delete the pair and save. Removing an override can restore default or inherited behavior, but only after confirming what the installed release defines as its default.

For multiple targets, add the primary entry and correctly numbered companion entries, for example das.isolationaddress1 with 192.0.2.2. Confirm that numbering, supported target count, and evaluation behavior are valid for the release. Every host should be able to reach every configured target.

Important advanced-option categories

Option area	Purpose	Typical examples	Verification requirement	Risk if misconfigured
Isolation and network detection	Influence how HA identifies isolation and network state	Isolation addresses and default-address behavior	Check network topology and release support	Unexpected isolation responses or VM restarts
Admission control and slot size	Influence reserved failover capacity calculations	CPU minimum and slot-related values	Review reservations, policy, and capacity	VM power-on blocked or insufficient failover reserve
VM restart behavior	Influence restart eligibility, priority, or timing	Restart-priority-related settings	Confirm supported keys and workload requirements	Critical VMs restart too late or unnecessary VMs restart
Host monitoring and failure detection	Adjust monitoring and timing behavior	Heartbeat and failure-detection settings	Validate against network latency and release behavior	False failure detection or delayed recovery
Datastore heartbeating	Provide storage-based evidence of host activity	Heartbeat datastore selection or monitoring	Confirm shared visibility and redundancy	Incorrect interpretation of isolation or failure
APD and PDL responses	Control responses to storage availability conditions where applicable	All Paths Down and Permanent Device Loss handling	Use only release-supported controls	Data unavailability, unnecessary power actions, or delayed recovery
Legacy or version-specific behavior	Preserve compatibility for particular releases or designs	Deprecated or undocumented-looking keys	Never assume universal support	Ignored settings or configuration errors

APD means All Paths Down: the host loses access to a datastore through all available paths. PDL means Permanent Device Loss: storage reports that the device is no longer available to the host. APD and PDL controls are release-dependent and should not be changed without understanding the storage design.

Admission control and CPU minimums

Admission control is the HA capacity policy that reserves enough resources for failover. It can prevent a VM from powering on when the cluster cannot preserve the configured failover reserve. A slot size is a capacity unit used by slot-policy calculations. CPU and memory reservations influence the size of a slot; a VM with a large reservation can require a larger slot.

The das.slotcpuinmhz option is associated with the minimum CPU component used in slot-size calculations. In a cluster where many VMs have unusually small CPU reservations, a configured minimum can prevent unrealistically small reservations from producing overly optimistic slot calculations. For example, 500 may be used as an illustrative value, not as a universal recommendation.

Increasing the CPU minimum can increase the calculated slot size, reduce the number of available slots, and cause admission control to report less available failover capacity. A reservation is a configured resource guarantee; it is not the same as actual CPU usage. Review VM reservations, memory reservations, the active admission-control policy, host capacity, and expected failover requirements before changing a slot-related value.

Record current reservations and admission-control capacity.
Identify whether small reservations are distorting the calculation.
Choose only a version-supported value and calculate its expected effect.
Save the option, wait for HA reconfiguration, and recheck failover capacity.
Confirm required workloads can still be powered on and that the reserve meets policy.

Cluster defaults and VM overrides

A cluster advanced option applies at cluster scope. A VM override is a per-virtual-machine HA setting that supersedes selected cluster defaults. Common override areas include restart priority, host isolation response, and VM monitoring behavior.

Setting area	Cluster-level purpose	When a VM override is appropriate	Operational risk
Restart priority	Set the general order in which VMs recover	A business-critical VM needs a different recovery priority	Too many high-priority exceptions can defeat the intended recovery order
Host isolation response	Define the normal action when a host is isolated	A workload has a deliberately different shutdown or power-off requirement	Conflicting actions can cause downtime or duplicate workload instances
VM monitoring	Define the normal response to guest or application health failures	A VM has application-aware recovery requirements or does not support monitoring	Unwanted resets or undetected application failure

Use an override only when the workload has a documented recovery requirement different from the cluster default. Do not use VM exceptions to hide a cluster-wide management-network, storage, or capacity problem. For a workload-specific isolation response, verify that the override agrees with application clustering and document its operational justification.

Datastore heartbeating

Datastore heartbeating uses files on shared datastores to provide evidence that an ESXi host is still active. This helps vCenter distinguish an isolated host from a failed host and reduces the chance of restarting VMs unnecessarily during a management-network partition.

Automatic selection lets HA choose suitable heartbeat datastores. Manual selection can be justified when the storage design requires explicit control, but selected datastores must be visible and writable by the relevant hosts. Consider redundant datastores, independent storage paths, datastore accessibility across host groups, and hosts that do not share the same datastores. A partially shared design may require careful selection so that heartbeat evidence is available to each host.

Inspect the current heartbeat datastore list before changing it. After a change, confirm visibility from all relevant hosts and check HA health. Datastore heartbeating supplements network heartbeats; it does not repair a broken management network or guarantee correct behavior when storage visibility is also partitioned.

Validation after a change

Confirm the key and value are spelled correctly and use the expected format.
Wait for HA reconfiguration to complete on the cluster.
Check cluster HA health, configuration alarms, recent tasks, and events.
From each ESXi host, verify management-network reachability to every configured isolation target using an approved, release-supported diagnostic method. A suitable vmkping test may require selecting the correct VMkernel interface and address family; follow the syntax supported by the installed ESXi release.
Review HA-related logs and vCenter events for invalid-option messages, isolation transitions, datastore-heartbeat warnings, or unexpected capacity changes.
Use a maintenance or test environment to exercise failure scenarios whenever possible.

Network reachability proves only that a target can be contacted at the time of the test. It does not prove that a complete HA failure scenario, VM power action, datastore-heartbeat decision, or application recovery sequence has been validated. Production disruption tests require an approved plan because they can trigger VM restart or power-off actions.

Troubleshooting common problems

Invalid or unsupported advanced option

Check for a typographical error, incorrect numbering, an option from another release, a deprecated key, or an invalid value type. Compare the entry with version-specific documentation, correct the exact key and format, or remove the unsupported entry. Allow HA to reconfigure and review cluster tasks and HA events.

Hosts enter isolation unexpectedly

Test each configured target from every host. Inspect management VMkernel configuration, VLANs, gateways, routes, firewalls, and upstream device availability. Determine whether the target itself is unavailable or whether the cluster is experiencing a network partition. Multiple independent targets can improve confidence when supported and justified, but they cannot compensate for a fundamentally unreliable management network.

Admission control shows less capacity

Compare capacity before and after the change. Check whether the CPU minimum increased slot size, VM reservations changed, a host entered maintenance mode, or the admission-control policy changed. Roll back the value if the effect is not justified by the availability policy.

VMs restart after a management-network incident

Review datastore heartbeat selection and shared storage access, then inspect the HA event timeline. Check isolation responses and VM overrides. Correct network and storage resiliency problems rather than relying only on HA tuning.

VM behavior differs from the cluster setting

Inspect the VM's HA override settings and compare the effective restart priority, isolation response, and monitoring behavior with cluster defaults. Confirm that any exception is intentional, documented, and compatible with the application design.

Rollback and upgrade cautions

Record the original state before modification. To roll back, restore the original value or remove the changed key when removal is documented to restore default behavior. Save the cluster configuration, wait for HA to reconfigure, and verify cluster health, alarms, events, capacity, heartbeat visibility, and effective VM settings.

Use only documented settings applicable to the installed vCenter Server and ESXi versions. Do not copy arbitrary values from unrelated environments. After an upgrade, review advanced options again because supported keys, defaults, and behavior may change.