VMware Cloud Community
bk0038CP
Contributor
Contributor
Jump to solution

ESXi 5.1 Configured as NTP Server Not Syncing with Local PC

I have an ESXi 5.1 server configured as a NTP server and a local Windows Server 2008 R2 PC that aren't syncing.  I understand it's not recommended for ESXi, but I've read [1] [2]  that whenever an ESXi server is run as a client, it also acts as a server, so I enabled it as an NTP client in vSphere by checking the NTP client box, adding no servers to the server list, and clicking run, and I also enabled port 123 incoming/outgoing by adding firewall settings from the ESXi Shell.

I'm almost positive that it's not a firewall issue.  I've completely disabled the firewall on my local PC.  Running "w32tm /monitor /computers:-IP of server-" gives me the time of the server, and running the NTPQuery software gives me a response back on port 123 with the server's time.

I have tried:

- Date/Time settings (right-click on notification area-->Adjust date/time-->Internet Time-->set as IP of server) -- syncing fails (*An error occurred while Windows was synchronizing with -IP of server-*)

- Group Policy Editor (Computer Configuration\Administrative Templates\System\Windows Time Service, currently disabled though because I've heard this causes problems) -- syncing fails

- Registry Editor (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\settings) -- syncing fails

- Command Prompt, using:

w32tm /config /manualpeerlist:-IP of server- /syncfromflags:MANUAL /reliable:yes /update

net stop w32time && net start w32time

w32tm /resync /rediscover

This updates the registry correctly, but outputs "The computer did not resync because no time data was available."  And whenever I use the command "w32tm /query /source" the source is always "Local CMOS clock."

Here is the output of w32tm /query /configuration

    [Configuration]

    EventLogFlags: 2 (Local)

    AnnounceFlags: 5 (Local)

    TimeJumpAuditOffset: 28800 (Local)

    MinPollInterval: 10 (Local)

    MaxPollInterval: 15 (Local)

    MaxNegPhaseCorrection: 3600 (Local)

    MaxPosPhaseCorrection: 3600 (Local)

    MaxAllowedPhaseOffset: 1 (Local)

 

    FrequencyCorrectRate: 4 (Local)

    PollAdjustFactor: 5 (Local)

    LargePhaseOffset: 50000000 (Local)

    SpikeWatchPeriod: 900 (Local)

    LocalClockDispersion: 10 (Local)

    HoldPeriod: 5 (Local)

    PhaseCorrectRate: 1 (Local)

    UpdateInterval: 360000 (Local)

 

    [TimeProviders]

 

    NtpClient (Local)

    DllName: C:\windows\system32\w32time.dll (Loca

    Enabled: 1 (Local)

    InputProvider: 1 (Local)

    AllowNonstandardModeCombinations: 1 (Local)

    ResolvePeerBackoffMinutes: 15 (Local)

    ResolvePeerBackoffMaxTimes: 7 (Local)

    CompatibilityFlags: 2147483648 (Local)

    EventLogFlags: 1 (Local)

    LargeSampleSkew: 3 (Local)

    SpecialPollInterval: 900 (Local)

    Type: NTP (Local)

    NtpServer: -IP of server-,0x1 (Local)

 

    NtpServer (Local)

    DllName: C:\windows\system32\w32time.dll (Loca

    Enabled: 1 (Local)

    InputProvider: 0 (Local)

    AllowNonstandardModeCombinations: 1 (Local)

Any ideas?  Thanks in advance.

Reply
0 Kudos
1 Solution

Accepted Solutions
jlanders
VMware Employee
VMware Employee
Jump to solution

The reply from your ESXi server shows that the leap indicator is 3 and the server stratum is 0.

This means that the ESXi NTP server is running unsynchronized and unable to provide a valid reference time to clients.

We recommend that you configure your ESXi host with valid upstream NTP servers such as:

0.vmware.pool.ntp.org, 1.vmware.pool.ntp.org and 2.vmware.pool.ntp.org

as described in the KB article or alternatively NTP servers from your internet service provider.


Although not recommended, you can configure ESXi to provide a reference time using the system's own clock

if you can't configure ESXi to synchronize to external upstream NTP servers.

Using the UI, Configuration Tab, Software (Time Configuration), Properties, Options, and finally NTP Settings,

specify "127.127.1.0" as your only NTP server. Be sure to check the box "Restart NTP service to apply changes"

and click OK twice to close both dialogs. Wait a few minutes for NTP to synchronize, then try your test again.

According to RFC 4330, Simple NTP (SNTP) clients should not use the time in an NTP reply packet if the

returned stratum is 0 (and the leap indicator is 3). Apparently, your Windows Simple NTP client is following

the RFC.

View solution in original post

Reply
0 Kudos
4 Replies
bk0038CP
Contributor
Contributor
Jump to solution

I just ran Microsoft Network Monitor on the local PC and ran w32tm /resync /rediscover.  Here's the log.  105 is the PC, 200 is the server.  Looks like the request is being sent and a response is being sent back, so I'm not sure why it's printing out "The computer did not resync because no time data was available."  Maybe it's that NULL in the reference timestamp sent back.

EDIT:  My ntp.conf file on the server only has a few lines.  How should the ntp.conf file be configured so that my server works as an NTP server?

output.png

Reply
0 Kudos
jlanders
VMware Employee
VMware Employee
Jump to solution

The reply from your ESXi server shows that the leap indicator is 3 and the server stratum is 0.

This means that the ESXi NTP server is running unsynchronized and unable to provide a valid reference time to clients.

We recommend that you configure your ESXi host with valid upstream NTP servers such as:

0.vmware.pool.ntp.org, 1.vmware.pool.ntp.org and 2.vmware.pool.ntp.org

as described in the KB article or alternatively NTP servers from your internet service provider.


Although not recommended, you can configure ESXi to provide a reference time using the system's own clock

if you can't configure ESXi to synchronize to external upstream NTP servers.

Using the UI, Configuration Tab, Software (Time Configuration), Properties, Options, and finally NTP Settings,

specify "127.127.1.0" as your only NTP server. Be sure to check the box "Restart NTP service to apply changes"

and click OK twice to close both dialogs. Wait a few minutes for NTP to synchronize, then try your test again.

According to RFC 4330, Simple NTP (SNTP) clients should not use the time in an NTP reply packet if the

returned stratum is 0 (and the leap indicator is 3). Apparently, your Windows Simple NTP client is following

the RFC.

Reply
0 Kudos
bk0038CP
Contributor
Contributor
Jump to solution

Thanks!  I should've caught that  Setting the NTP server's upstream server to its own time (127.127.1.0) worked.

I'm new to all this--why is it not recommended to sync to the ESXi server?  In my application, I need a few PCs and another ESXi server to sync with my ESXi server and all have the same time.  It's not critically important to have the clocks be accurate to the true time of day.  It's only important that they should all be in sync.  The server will ideally always be on, but when it's off, all these devices have their internal clocks to go off of for a few minutes until re-syncing.

Reply
0 Kudos
jlanders
VMware Employee
VMware Employee
Jump to solution

Thank you for the update.

ESXi implements RFC-1589 (Kernel Model for Precision Timekeeping) in the vmkernel, and

has a recent and well maintained NTP daemon, so the server makes a good time source

especially when configured with reliable upstream time references.

Without upstream reference time sources, you create a "floating time island" that depends

on the accuracy of the clock on the server hardware. This can work well if you can keep all

of the elements pegged to one time source. It sounds like your configuration would be fine.


Deployments sometimes get into trouble when they inadvertently anchor to another time

source. The time discrepancy between the "floating time island" and other time sources can

cause problems with services that are certificate or leased based (i.e. SSL and AD). These

problems can be difficult to diagnose. Again, it sounds like your configuration would work fine.

Reply
0 Kudos