ESXi Host Time Drifts or Fails NTP Synchronization When Joined to an Active Directory Domain

Products

• VMware vSphere ESXi

Issue/Introduction

An ESXi host experiences persistent time drift (e.g., jumping ahead or falling behind by several minutes) or completely fails to synchronize time via the Network Time Protocol NTP.

• The issue persists even though NTP is properly configured and the ntpd service is running.

• Disabling NTP may cause the host to temporarily hold the correct time, but the violent drift returns immediately upon re-enabling NTP.

• Running ntpq -p via SSH shows massive jitter, huge offsets, or the host dropping to Stratum 16.

• The /var/run/log/syslog.log file contains NTP sync failures, such as: ntpd[xxxx]: receive: Unexpected origin timestamp [hex] does not match aorg [hex] from server@[IP] ntpd[xxxx]: no peer for too long, server running free now

 

Environment

VMware ESXi 7.x, 8.x

Cause

This issue occurs due to a time synchronization override conflict. When an ESXi host is joined to a Windows Active Directory domain, it can default to pulling its time directly from the AD Domain Controller, overriding the standard ESXi NTP daemon (ntpd) configuration.

If the Active Directory Domain Controllers are not synchronizing to an external, reliable NTP source and are running on their own inaccurate local time, they will aggressively push this incorrect time down to the ESXi host. Because the domain hierarchy actively fights the local NTP configuration, the ESXi OS time shifts violently. When this shift happens while standard NTP packets are still in flight, the ntpd daemon rejects the returning packets because the timestamps no longer match, causing the daemon to drop the sync completely to protect the kernel.

Resolution

To resolve this issue, you must correct the time source at the top of the Active Directory domain hierarchy.

1. Engage the Active Directory or Windows Administration team.

2. Verify the current time set on the Primary Domain Controllers.

3. Configure the Windows Domain Controllers to synchronize with a reliable, external NTP source.

4. Once the Domain Controller time is accurate, the ESXi host will pull the correct time through the domain hierarchy, and the conflict with the local ntpd service will cease.

Additional Information

Verifying the Hardware Clock Override in Logs: If the domain controllers are verified to have the correct time, a defective physical hardware clock (RTC) or dying CMOS battery on the ESXi motherboard can cause identical symptoms. You can verify if the kernel is forcefully stepping the time by checking /var/run/log/vmkernel.log for the following events:

• TimeTracker: 212: System clock stepped forward by [xxxx] microseconds

• RTC: 104: hardware clock synchronized to OS time

Manual Time Configuration (Temporary Workaround): If you need to manually set the time while the AD team resolves the Domain Controller configuration, use the following ESXi CLI commands. (Note: ESXi operates in UTC. You must input the time in UTC, not your local time zone).

1. Set the OS Time: esxcli system time set -d <day> -M <month> -y <year> -H <hour> -m <minute> -s <second>

2. Set the Hardware Clock (CMOS): esxcli hardware clock set -d <day> -M <month> -y <year> -H <hour> -m <minute> -s <second>

A host reboot is required for the hardware time change to take full effect.

Related Information / Reference KBs

• Troubleshooting NTP on ESX and ESXi

• Verifying time synchronization across an ESX/ESXi host environment

• Configuring Network Time Protocol (NTP) on ESXi hosts using the vSphere Client

• Timekeeping within ESXi (Explains hypervisor reliance on physical hardware timers like TSC and HPET).