VMware Cloud Community
w1nter
Enthusiast
Enthusiast
Jump to solution

esxi ntp client capabilities (interesting compliance requirement)

Hi Guys,

I was thrown an interesting compliance requirement from a customer. They require that all NTP updates be averaged across 2 (preferrably 3) ntp servers (of a particular stratum, though I dont think this would affect the question).

Effectively they want to query a few NTP servers, average the difference between the updates provided by all servers then drift towards that. Apparently this is the normal behaviour for the HP NonStop ntp client they use, and need to find a way to do this on all other hosts.

I trawled around, and couldnt find an easy way to do this with the ntpd esxi uses. The best i could think of would be to have the ntp infrastructure the clients (esx) are syncing to provide this, but from the compliance perspective this wouldnt cut it.

Apparently this is a common compliance requirement for financial houses - anyone else run into this, or have a solution?

It seems like one of those requirements that everyone just ignores Smiley Wink

As usual, any thoughts appreciated and rewarded with points :smileycool:

Reply
0 Kudos
1 Solution

Accepted Solutions
paulgear
Contributor
Contributor
Jump to solution

The behaviour you describe (drifting towards the average of reported servers) is the normal, expected behaviour of all proper implementations of NTP.  (See http://web.archive.org/web/20100331222927/http://www.sun.com/blueprints/0901/NTPpt3.pdf for an explanation of why this is the case - working through the diagram on page 9 is one of the best things you'll ever do in understanding NTP.)

As near as i can tell, ESXi provides a fully working NTP server.  So all you need to do is add three servers in the host time configuration screen and you'll achieve this behaviour.  You can verify the behaviour by running 'ntpq -pn IPaddress' from a local Linux box against your ESXi host.  Here's an example of what mine looks like shortly after the time servers have been reconfigured and ntpd restarted:

remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
192.168.240.254 203.192.179.98   3 u  101   64   37    1.229  60465.5 30179.7
192.168.240.5   203.31.84.4      3 u   96   64   37    0.269  60338.7 30169.5
192.168.240.249 192.189.54.17    3 u  100   64   37    0.229  60338.8 30169.4

This server was about 1 minute (60,000 milliseconds) slower than the real time, and should begin drifting towards it once it's synced up.

Regards,

Paul

View solution in original post

Reply
0 Kudos
4 Replies
AndreTheGiant
Immortal
Immortal
Jump to solution

You can have more source, but not this function.

You can implement using external NTP server.

Andrew | http://about.me/amauro | http://vinfrastructure.it/ | @Andrea_Mauro
Reply
0 Kudos
paulgear
Contributor
Contributor
Jump to solution

The behaviour you describe (drifting towards the average of reported servers) is the normal, expected behaviour of all proper implementations of NTP.  (See http://web.archive.org/web/20100331222927/http://www.sun.com/blueprints/0901/NTPpt3.pdf for an explanation of why this is the case - working through the diagram on page 9 is one of the best things you'll ever do in understanding NTP.)

As near as i can tell, ESXi provides a fully working NTP server.  So all you need to do is add three servers in the host time configuration screen and you'll achieve this behaviour.  You can verify the behaviour by running 'ntpq -pn IPaddress' from a local Linux box against your ESXi host.  Here's an example of what mine looks like shortly after the time servers have been reconfigured and ntpd restarted:

remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
192.168.240.254 203.192.179.98   3 u  101   64   37    1.229  60465.5 30179.7
192.168.240.5   203.31.84.4      3 u   96   64   37    0.269  60338.7 30169.5
192.168.240.249 192.189.54.17    3 u  100   64   37    0.229  60338.8 30169.4

This server was about 1 minute (60,000 milliseconds) slower than the real time, and should begin drifting towards it once it's synced up.

Regards,

Paul

Reply
0 Kudos
paulgear
Contributor
Contributor
Jump to solution

I forgot to mention: you might want to edit /etc/init.d/ntpd on your ESXi hosts to add the -x flag to the ntpd startup if you don't want your clocks jumping around.  Normally, ntpd will step the clock if it's too far out from the true time.

w1nter
Enthusiast
Enthusiast
Jump to solution

You rock! really appreciate the input.

david.

Reply
0 Kudos