An HPE ProLiant ESXi environment showed several warnings within the same troubleshooting period: a host TPM attestation alarm, a vMotion clock-skew warning, an SSO token failure in a disaster-recovery component, incorrect task timestamps, and a clone operation that could not connect to another host.
The proximity of those messages makes a single root cause tempting. Some are genuinely connected by time synchronization. Others are separate security or network paths. Treating all of them as “the TPM problem” can waste time and introduce risky firmware or key changes before the simpler evidence has been checked.
Start with an error-to-dependency map
| Symptom | Primary dependency to verify | Usually caused by host TPM? |
|---|---|---|
| Host TPM attestation alarm | Secure Boot, TPM presence/state, attestation support | The alarm itself concerns host trust, but not guest networking |
| vMotion clock-skew warning | Actual time on both ESXi hosts and vCenter; alarm freshness | No |
| SSO token acquisition failure | Time agreement among the requesting appliance and SSO/vCenter components | No |
| Recent Tasks with wrong timestamps | Historical system time and current NTP state | No |
| Clone or cold migration “Cannot connect to host” | Host-to-host NFC connectivity, commonly TCP 902 | No |
This map is not a substitute for logs, but it prevents a TPM warning from becoming the assumed cause of every later event.
Host TPM attestation is not a VM vTPM
A host TPM attestation alarm evaluates the ESXi host’s boot trust. A virtual TPM attached to a guest is a different object with different key-management dependencies. Neither is a mechanism that “propagates an error” into ordinary guest operating systems.
Broadcom’s current host TPM attestation alarm article documents the alarm on ESXi 8 systems when Secure Boot is disabled, including installations that are not otherwise using the physical TPM. Therefore, begin with evidence visible to ESXi and vCenter:
- whether Secure Boot is enabled and supported on the host;
- whether ESXi detects a physical TPM and which version it reports;
- whether the alarm appeared after a fresh install, upgrade, or host re-add;
- the HPE System ROM, iLO, TPM firmware, and ESXi build;
- whether any workload actually depends on vTPM or VM encryption.
Do not clear or reset a physical TPM as a generic alarm reset. A TPM change can affect encryption and recovery workflows. Inventory key providers, encrypted VMs, vTPM-enabled guests, and recovery material first.
On older hardware such as a ProLiant Gen9, verify the exact platform and option-part support in HPE documentation rather than assuming that a firmware menu can convert TPM 1.2 hardware into TPM 2.0. Firmware can update supported hardware; it does not replace the underlying TPM generation.
Determine whether the clock skew is real or stale
A vMotion compatibility check can report that relative time skew between source and destination hosts exceeds five minutes. That warning deserves attention because time affects authentication, certificates, logs, and distributed operations. It still must be verified against current clocks.
Compare all participating systems at the same moment:
- source ESXi host;
- destination ESXi host;
- vCenter Server Appliance;
- any external Platform Services Controller in an older topology;
- Site Recovery Manager or vSphere Replication appliances involved in the failing task.
In vSphere Client, review each host under Configure > System > Time Configuration. From an ESXi shell, use read-only checks before changing configuration:
esxcli system time get
esxcli system ntp get
/etc/init.d/ntpd status
A timezone display difference is not necessarily clock skew. Systems can show different local representations of the same instant. Compare UTC or epoch time and confirm NTP synchronization rather than forcing every interface to display the same timezone.
Broadcom has also documented a stale vMotion time-skew warning that can persist even when host time is synchronized, with a fix in vCenter Server 8.0 Update 3g. If current time, NTP state, and logs agree but the warning remains, check the exact vCenter version and the current Broadcom clock-skew guidance before repeatedly changing NTP servers.
HPE “Propagate NTP Time to Host” is not continuous ESXi NTP
On iLO 4 and iLO 5, HPE’s “Propagate Network Time Protocol (NTP) time to host” setting synchronizes server time with iLO during specific platform events. HPE’s customer advisory describes propagation at the first POST after AC power is applied, after a blade insertion or e-fuse event, or after iLO is reset to defaults. It also documents a BIOS timezone side effect on affected configurations.
That is not a replacement for configuring ESXi’s own NTP service. Treat iLO, the host firmware clock, ESXi, and vCenter as distinct time consumers:
- Configure reliable NTP for iLO.
- Configure reliable NTP for each ESXi host.
- Configure the VCSA and recovery appliances according to their supported management interfaces.
- Permit the required NTP traffic and verify synchronization from each component.
Use a common authoritative time source where practical, but do not make a production domain controller the sole source without redundant upstream and monitoring.
Why SSO token failures often point to time
The error “Unable to acquire vCenter Single Sign-On user token. Check clock sync.” is much more directly related to time than the TPM alarm. Authentication tokens have validity windows. If the requesting appliance and the SSO service disagree on time, a freshly issued token can appear premature or expired.
Broadcom’s SSO token troubleshooting article identifies time synchronization among vSphere Replication, Site Recovery Manager, and vCenter/SSO components as the relevant path. Correct and verify the clocks, then retry authentication. Restarting services without fixing the time source may provide only a temporary recovery.
When diagnosing:
- capture the time from every participating appliance before making changes;
- verify NTP peers and synchronization state, not only the configured server name;
- check DNS resolution for the NTP source;
- inspect appliance and SSO logs around the same UTC interval;
- account for snapshots or restored appliances that may return with stale time.
Wrong task timestamps do not justify deleting history
If completed tasks were recorded while a host or vCenter clock was wrong, fixing NTP does not rewrite those historical timestamps. Preserve that audit trail. It documents what the system believed at the time and can help correlate the incident.
Removing task records through internal APIs or the Managed Object Browser is disproportionate unless the records are truly stuck and a vendor-supported procedure applies. Before any database- or MOB-level cleanup, verify backups, take supported snapshots where appropriate, and distinguish completed entries with bad time from active tasks that prevent new operations.
“Cannot connect to host” during a clone is usually another path
A VM clone or cold migration can fail with “Cannot connect to host” even when vCenter manages both hosts successfully. The data-mover path can require direct connectivity that the management UI does not exercise.
Broadcom’s clone and cold-migration guidance identifies TCP 902 connectivity between source and destination ESXi hosts as a common requirement for NFC traffic. Check routing, host firewalls, upstream ACLs, and name resolution in both directions. Test the path between the hosts, not merely from an administrator workstation to vCenter.
Also verify:
- source and destination management addresses;
- the selected VMkernel interfaces and routes;
- MTU consistency along the data path;
- datastore reachability and free capacity;
- hostd and vpxa health in the relevant timestamps;
- whether the failure is specific to one host pair.
Correcting a TPM alarm will not open a blocked TCP port. Correcting time may be necessary for authentication but still leave the clone path unavailable.
A low-risk diagnostic order
Use the least invasive checks first:
- Export or capture the exact alarms, task IDs, UTC timestamps, and affected components.
- Compare real time and NTP state across hosts, vCenter, and recovery appliances.
- Separate stale clock warnings from current drift.
- Test the host-to-host network path required by the failing clone or migration.
- Inspect the host TPM and Secure Boot state independently.
- Inventory encryption, key-provider, and vTPM dependencies before any TPM change.
- Update firmware or VMware components only against the exact HPE server and VMware compatibility guidance.
- Preserve historical tasks unless a supported cleanup is specifically required.
The most valuable result is not clearing every alarm at once. It is proving which dependency failed for each operation. In this incident pattern, time can explain SSO and timestamp problems, network reachability can explain clone failures, and TPM attestation remains a separate host-trust issue.
