A Fault Tolerance secondary that cannot power on is not automatically a capacity or FT-network problem. In the vSphere 8.0.x case documented by Broadcom KB 451614, the HA agent rejects the operation because VM Component Protection, or VMCP, is configured incompatibly with the FT workload. The decisive evidence is the policy message for that VM, not merely a red FT status.
This article explains that exact diagnostic branch. It is source-researched and untested; no host, VM, HA setting or protection policy was changed.
Two protection mechanisms meet
Fault Tolerance has a primary and secondary VM. The incident here concerns starting the secondary. VMCP is part of vSphere HA and responds to datastore accessibility failures. Its available responses range from recording events to powering off and restarting affected VMs elsewhere.
The vSphere 8.0 VMCP guide distinguishes Permanent Device Loss, or PDL, from All Paths Down, or APD. PDL is an unrecoverable accessibility loss reported by the device. APD represents transient or unknown accessibility loss. These labels concern the storage failure, not whether an application is healthy.
KB 451614 identifies an architectural incompatibility between VMCP and FT workloads. Its documented repair is specific to the affected VM's APD/PDL response policy. Disabling HA for the entire cluster would change a much broader protection boundary and is not the diagnostic response described here.
Start with the failed task and its policy evidence
Prerequisites are approved read access to the affected VM and cluster configuration, the existing failed task details, and the relevant HA agent log. Record vCenter and ESXi builds, the VM's identity, its primary host and the failure time including time zone. Similar names are insufficient if several copies of the VM exist.
Read the existing secondary power-on task error. Then inspect the corresponding interval in /var/log/fdm.log on the primary ESXi host through the organisation's approved log-reading route. KB 451614 shows this diagnostic fragment:
VM /vmfs/volumes/[datastore]/[vm]/[vm].vmx is not desired protected. Disable VMCP monitoring
The bracketed names here are placeholders, not a command. Match the VM path and time to the failed task. An unrelated occurrence for another VM does not establish this cause. Preserve enough surrounding lines to show which operation was rejected.
Next inspect the cluster's VMCP responses and the affected VM's overrides. In the vSphere Client, inspect Configure → Configuration → VM Overrides for the affected VM, then the existing vSphere HA → Failures and Responses → Datastore with PDL / APD values. Do not add an override or save changes. Record the effective choices for Datastore with PDL and Datastore with APD, including whether the VM inherits the cluster setting. Inspection means reading existing values, not clicking through to save a change.
The 8.0 VMCP guide also states that VMCP cannot restart VMs when Host Monitoring or VM Restart Priority is deactivated. Record those prerequisites separately; they do not justify enabling protection settings as a diagnostic experiment.
A worked interpretation
Consider a fictional VM named ledger-app. Its primary is running. A task to start the secondary fails at 10:12, and the FDM entry at that time identifies ledger-app.vmx with the policy fragment above. The VM inherits the cluster's VMCP storage responses.
Those observations support the documented policy-conflict diagnosis. They do not establish packet loss, insufficient RAM or a missing datastore. Repeatedly trying different hosts would leave the same policy conflict unresolved. Likewise, a running primary does not demonstrate that the intended secondary protection has been established.
Now change the hypothetical evidence: the secondary task reports insufficient datastore space, and there is no matching policy message. That is a different failure. This KB does not justify altering VMCP merely because another FT secondary once failed for that reason. Follow the actual error and preserve the protection settings while investigating.
The remedy has a protection trade-off
For the matching case, KB 451614 documents disabling the affected VM's PDL and APD VMCP responses through a per-VM override, then starting the secondary. This article identifies the vendor's remedy so the diagnosis leads to a concrete decision; it does not provide an immediate change or power-on procedure.
A qualified VMware owner must assess the exact build, current protection design and consequences of removing those VMCP responses before authorising that change. Record the existing inheritance and override values. Do not silently replace an inherited policy with a permanent override without documenting why it exists. The KB’s per-VM resolution is specifically intended to leave cluster-wide VMCP protection for other workloads in place; documenting the exception supports that design, rather than rejecting the vendor remedy.
Acceptance, reversal and limits
Diagnostic acceptance requires the exact failed task, matching FDM message and effective policy to agree. After a separately reviewed repair, functional acceptance would require successful secondary creation/power-on, the intended FT protection state and no repeat of the same policy rejection. A completed configuration task alone is insufficient. No such test was performed for this article.
Restoring the previous override or inheritance restores the previous policy choice; it may also restore the original incompatibility. It is not proof that the protection design is safe. Do not turn FT off, kill a VM, interrupt storage or disable HA to manufacture acceptance evidence.
Learning notes
- A secondary power-on failure needs its own task and log evidence.
- VMCP is a datastore-failure response policy, not a generic FT health indicator.
- A per-VM remedy changes that VM's protection contract and needs explicit technical review.
References
- A06-S1: Secondary FT Virtual Machine Fails to Power On With VMCP Monitoring Error
- A06-D1: VM Component Protection