VMware ESXi and vSphere Cluster Management

Advanced Options in vSphere HA

Learn how to configure, validate, and safely roll back vSphere HA advanced options, with emphasis on host isolation detection and isolation addresses.

vSphere High Availability (HA) detects ESXi host failures and coordinates recovery or restart of virtual machines through vCenter Server. Most HA behavior is configured through standard cluster controls, but some supported behaviors are exposed as advanced options: cluster-level key-value settings that tune HA beyond the normal configuration interface.

Advanced options supplement, rather than replace, admission control, host monitoring, datastore heartbeating, isolation response, VM monitoring, and other standard HA settings. The available keys and accepted values can change between vSphere releases. Always use the parameter list and documentation that match the installed vCenter Server and ESXi versions.

What vSphere HA Advanced Options Control

An advanced option is a named key paired with a value. HA reads the setting as part of the cluster configuration and uses it to influence a supported behavior. For example, the key das.isolationaddress identifies a custom IP address that an ESXi host can probe when evaluating whether it is isolated.

These settings are useful when a standard control does not fully represent the environment. Examples include unusual management-network layouts, isolated sites, multiple uplinks, special routing designs, or workloads that require carefully tuned restart and monitoring behavior.

Do not treat advanced options as a general-purpose way to override HA design. An incorrect value can cause unnecessary VM restarts, cause an isolated host to remain active when it should not, create split-brain-like operating conditions, or reduce recovery protection. Use change control, record the previous state, test in a representative environment, and apply one change at a time.

When Advanced Configuration Is Appropriate

  • Unusual management networks: A cluster may use several management paths, routed segments, or special gateway designs.
  • Isolated sites: A site may need a carefully selected probe endpoint because normal gateway assumptions do not apply.
  • Multiple uplinks: Redundant uplinks can create different reachability results if VLANs, routing, or firewall rules are inconsistent.
  • Specialized workloads: Capacity, restart, or monitoring behavior may need adjustment after validating the workload and recovery design.
  • Diagnostics: Some supported options help collect or refine operational information, but they should not be enabled simply because a key is mentioned in an old procedure.

Avoid guessing undocumented parameters, copying settings from another vSphere release, or retaining obsolete keys after an upgrade without verification. Confirm that the key is supported, determine its allowed syntax, document the reason for the change, and define a rollback procedure before applying it.

Host Isolation Detection

Meaning of Host Isolation

A host isolation event occurs when an ESXi host loses expected HA network communication with other cluster members while the host may still be running workloads. The host then evaluates whether it has connectivity outside the HA management path. If HA determines that the host is isolated, the configured isolation response influences what happens to its virtual machines.

An isolation response is the action configured for VMs when their host determines that it is isolated. Depending on policy and VM settings, the action can involve leaving the VM powered on, powering it off, or shutting it down so another host can restart it. The exact available choices depend on the vSphere version and cluster configuration.

Isolation, Failure, and Partition Compared

A failed host is no longer operating or no longer able to provide meaningful evidence of its state. An isolated host is still operating but cannot communicate through the expected HA network path. A network partition is a communication split in which multiple operational hosts or groups cannot all communicate with one another. A temporary management-network interruption may be brief and may not meet HA's complete isolation criteria.

Failure-State Comparison

Condition: Host failure

Host management connectivity: Unavailable

External network reachability: Usually not observable from the failed host

Datastore heartbeat evidence: May indicate that the host stopped updating or is no longer active

Expected HA interpretation: Host failure

Administrative response: Confirm hardware, power, and ESXi health; review VM recovery.

Condition: Host isolation

Host management connectivity: Lost to HA peers

External network reachability: May remain available through an isolation probe path

Datastore heartbeat evidence: May show that the host is still active

Expected HA interpretation: Isolated host if probe and HA criteria indicate isolation

Administrative response: Check management networking, uplinks, routing, probe reachability, and isolation response.

Condition: Network partition

Host management connectivity: Available within separate groups but not across the whole cluster

External network reachability: Can differ by group or host

Datastore heartbeat evidence: Can help HA distinguish active hosts from failed hosts

Expected HA interpretation: Partitioned cluster with potentially different views of membership

Administrative response: Repair the communication path and review HA events before changing VM power state.

Condition: Temporary management-network interruption

Host management connectivity: Briefly impaired

External network reachability: May remain available

Datastore heartbeat evidence: Often continues

Expected HA interpretation: Depends on duration, probes, heartbeats, and other HA evidence

Administrative response: Investigate transient network faults and avoid unplanned isolation testing.

Isolation-Address Probes

An isolation address is a dependable IP endpoint that an ESXi host tests as part of isolation detection. The probe helps answer a practical question: has the host lost all relevant network connectivity, or has it only lost communication with the other HA hosts?

The primary custom isolation probe is represented by:

das.isolationaddress = 192.0.2.1

The address 192.0.2.1 is documentation-safe example data. Replace it with an address suitable for the actual network design. Every relevant cluster host should be able to reach the endpoint through the intended management-network path.

A good endpoint is stable, reachable, and resilient. A properly designed gateway or another highly available routed address may be appropriate, provided it is not a single fragile device and does not fail whenever the management network fails. Some vSphere releases support additional isolation-address keys for more than one probe. Verify the exact key names, syntax, and behavior for the installed version before configuring primary and additional addresses.

An incorrect or unreachable address can make a healthy host appear isolated. An address behind a failed gateway can produce the same result as a real network outage. Routing asymmetry, firewall rules, VLAN mistakes, or an endpoint reachable only from some uplinks can also produce inconsistent isolation decisions among hosts.

Isolation Address Selection Checklist

Candidate endpoint: Network gateway, routed service address, or other approved endpoint

Reachable from every host: Confirm from each host and intended management path

Resilient endpoint: Prefer an endpoint whose failure does not represent a single-device outage

Uses intended routing path: Confirm VLAN, gateway, route, ACL, and firewall behavior

Suitable for production use: Validate with network and HA owners before deployment

Notes: Do not select an address merely because it responds from an administrator workstation.

Configuring an Advanced Option in the vSphere Client

Interface labels vary slightly among vSphere Client versions, but the workflow is generally similar:

  1. Select the target cluster in the inventory.
  2. Open the cluster's Configure or Settings area.
  3. Open the vSphere HA configuration section and choose the control to edit HA settings.
  4. Locate the Advanced options area.
  5. Add a key-value pair. For the isolation-probe example, enter das.isolationaddress as the key and 192.0.2.1 as the example value.
  6. Save or apply the configuration.
  7. Reopen or review the advanced-options area and confirm that the entry appears in the cluster configuration.

The value must be replaced with an endpoint appropriate for the environment. Before saving, verify the exact spelling, capitalization, value format, and release support. A setting that saves successfully is not necessarily a setting that is valid for the intended behavior, so validation is required.

Common Advanced-Option Categories

HA Advanced Option Planning Matrix

Option category: Isolation detection

Typical purpose: Tune network reachability checks and isolation-probe behavior

Example configuration key: das.isolationaddress

Primary dependency: Management VLANs, routes, gateways, firewalls, and uplinks

Operational risk if misconfigured: False isolation, unnecessary VM actions, or reduced protection

Option category: Capacity and restart behavior

Typical purpose: Influence decisions about available recovery capacity and VM restarts

Example configuration key: Use only the release-supported capacity or restart key

Primary dependency: Admission control, reservations, cluster capacity, and workload demand

Operational risk if misconfigured: Recovery may be refused, delayed, or planned around unrealistic capacity

Option category: Heartbeat-related behavior

Typical purpose: Tune or diagnose failure-state evidence involving HA heartbeats

Example configuration key: Use the supported heartbeat-related key for the installed release

Primary dependency: Management networking and shared datastore access

Operational risk if misconfigured: Ambiguous failure interpretation or excessive sensitivity

Option category: VM monitoring and restart behavior

Typical purpose: Tune VM health monitoring or restart decisions

Example configuration key: Use the supported VM-monitoring or restart key

Primary dependency: Guest behavior, tools status, restart priority, and VM overrides

Operational risk if misconfigured: Repeated restarts or insufficient response to an unresponsive VM

Option category: Diagnostic or operational settings

Typical purpose: Support troubleshooting or controlled operational behavior

Example configuration key: Only a documented, version-matched key

Primary dependency: VMware support guidance and release-specific behavior

Operational risk if misconfigured: Noise, unsupported behavior, or misleading diagnostics

These categories are conceptual rather than a promise that every listed behavior has a configurable key in every release. Historical, deprecated, undocumented, or renamed parameters may be rejected, ignored, or behave differently. Never guess a key or value; use the supported parameter list for the exact vCenter Server and ESXi version.

CPU Capacity, VM Usability, and Restart Decisions

HA can use capacity-related settings and admission control to decide whether the cluster has enough resources to restart protected VMs after a host failure. This is a cluster recovery-capacity question, not a direct measure of whether a guest operating system will feel fast after restart.

A VM's configured CPU reservation is the amount of CPU capacity the platform attempts to guarantee. CPU shares express relative priority during contention, while a CPU limit caps the VM's consumption. These settings are different from the VM's configured number of virtual CPUs and from the guest operating system's ability to use those CPUs effectively.

Evaluate any CPU threshold or capacity tuning alongside admission control policy, host capacity, reservations, restart priorities, consolidation overhead, and real workload demand. A cluster can technically satisfy a restart calculation while a workload remains undersized, or it can have substantial unreserved CPU while admission control prevents the desired recovery plan. Capacity tuning should be based on measured demand and a documented failure scenario.

Datastore Heartbeating and Network Detection

Datastore heartbeating is HA signaling through shared datastores. It provides additional evidence about whether a host is still active when management-network communication is impaired. HA can use datastore heartbeat information together with network reachability and host state to distinguish some host failures from communication failures.

Network isolation detection and datastore heartbeating complement one another. An isolation probe can show that a host still reaches an external endpoint, while datastore heartbeats can show that the host is still interacting with shared storage. Neither mechanism makes a poorly designed management network safe. Reliable HA still requires redundant paths, correct VLANs and routing, appropriate firewall rules, sound datastore access, and a deliberate isolation-response policy.

VM-Level HA Overrides

A VM override is a per-virtual-machine HA setting that changes behavior relative to the cluster default. Common overrides include restart priority, host isolation response, and VM monitoring sensitivity.

Conceptually, the cluster defines the default and a configured VM override supplies different behavior for that VM. This is why two VMs on the same host may respond differently during an event. Before diagnosing unexpected behavior, compare the cluster setting with the affected VM's override, then review HA events, datastore heartbeat evidence, and the host's connectivity state.

Validation and Rollback

Validation Procedure

  1. Record the old configuration, the proposed key and value, the reason for the change, and the expected result.
  2. Confirm that the key and value are supported by the installed release.
  3. Apply one advanced option at a time through the cluster's HA settings.
  4. Confirm that the cluster accepts the setting and retains it after saving or reopening the configuration.
  5. Check cluster health, HA status, host alarms, and recent HA events.
  6. Monitor for unexpected isolation reports, VM restarts, admission-control changes, or monitoring alerts.
  7. Review relevant host and HA logs when an event occurs.

Do not simulate host isolation in production without an approved test plan, maintenance window, stakeholder notification, and a method to prevent unwanted VM power actions. Prefer a representative test environment or a carefully controlled failure exercise.

Safe Rollback

Rollback means removing the changed key-value pair when the default behavior should be restored, or restoring the documented prior value when a previous custom setting was in use. Confirm the rollback syntax for the vSphere release, apply the change through the cluster configuration, and verify that the setting is absent or restored after saving.

Document the rollback, review HA events and alarms again, and confirm that standard admission control, host monitoring, datastore heartbeating, isolation response, and VM overrides still match the intended design.

Troubleshooting Advanced HA Settings

Hosts Report Isolation Unexpectedly

  • Confirm physical and virtual management-network connectivity, VLAN configuration, uplinks, gateway reachability, and routing.
  • Validate reachability to the configured isolation address from every relevant host path.
  • Check for asymmetric routing or firewall rules that affect probe traffic in only one direction.
  • Determine whether the endpoint fails whenever the management network fails.
  • Review HA and host events around the incident.
  • Compare datastore heartbeat evidence with the network symptoms.

A VM Does Not Take the Expected Action

  • Review the VM's HA override and compare it with the cluster isolation-response setting.
  • Determine whether HA recognized host isolation, host failure, a network partition, or only a temporary interruption.
  • Review recent cluster and VM configuration changes.
  • Inspect HA events before assuming that the host failed.

An Option Is Rejected, Ignored, or Has No Apparent Effect

  • Check the exact spelling and value format.
  • Verify that the parameter is supported and not deprecated for the installed version.
  • Confirm that the entry remains listed after saving.
  • Look for an overlapping standard HA setting, admission-control policy, heartbeat condition, or VM override.
  • Do not substitute an undocumented value based on a similar-looking key.

Practical Change Checklist

  1. Define the failure scenario the option is intended to address.
  2. Identify the affected clusters, hosts, datastores, and VMs.
  3. Check the release-matched supported parameter list.
  4. Record the current value or confirm that the key is absent.
  5. Validate network paths, isolation endpoints, datastore heartbeats, and VM overrides.
  6. Apply the smallest change possible through vCenter Server.
  7. Verify retention, cluster health, events, alarms, and workload behavior.
  8. Remove or restore the option if the result is not as expected.

For related cluster administration guidance, continue with Advanced Options in vSphere HA.