2

This is taken from an Ubuntu 10.10 VM running on ESX5:

Nov  3 21:58:50 server1 ntpd[21169]: adjusting local clock by 31.187370s
Nov  3 22:02:36 server1 ntpd[21169]: adjusting local clock by 31.159808s
Nov  3 22:05:18 server1 ntpd[21169]: adjusting local clock by 31.067579s
Nov  3 22:07:59 server1 ntpd[21169]: adjusting local clock by 30.952187s
Nov  3 22:11:38 server1 ntpd[21169]: adjusting local clock by 30.890147s

According to the VMWare KB no kernel tweaks should be needed for Ubuntu 10.10 to maintain time to their standards.

What's especially odd is the drift seems fairly consistent.

Any help appreciated on this one!

UPDATE

I've been running tail on the log for a while to watch this, and just come back to it and noticed the distance is decreasing every time it polls which is... odd...

Nov  3 21:58:50 server1 ntpd[21169]: adjusting local clock by 31.187370s
Nov  3 22:02:36 server1 ntpd[21169]: adjusting local clock by 31.159808s
Nov  3 22:05:18 server1 ntpd[21169]: adjusting local clock by 31.067579s
Nov  3 22:07:59 server1 ntpd[21169]: adjusting local clock by 30.952187s
Nov  3 22:11:38 server1 ntpd[21169]: adjusting local clock by 30.890147s
Nov  3 22:15:56 server1 ntpd[21169]: adjusting local clock by 30.797336s
Nov  3 22:19:02 server1 ntpd[21169]: adjusting local clock by 30.645081s
Nov  3 22:22:30 server1 ntpd[21169]: adjusting local clock by 30.607198s
Nov  3 22:23:44 server1 ntpd[21169]: adjusting local clock by 30.542707s
Nov  3 22:27:56 server1 ntpd[21169]: adjusting local clock by 30.413376s
Nov  3 22:29:45 server1 ntpd[21169]: adjusting local clock by 30.322777s
Nov  3 22:33:14 server1 ntpd[21169]: adjusting local clock by 30.259502s
Nov  3 22:36:17 server1 ntpd[21169]: adjusting local clock by 30.181322s
Nov  3 22:38:30 server1 ntpd[21169]: adjusting local clock by 30.103619s
Nov  3 22:40:34 server1 ntpd[21169]: adjusting local clock by 30.074569s
Nov  3 22:41:43 server1 ntpd[21169]: adjusting local clock by 29.996409s
Nov  3 22:45:26 server1 ntpd[21169]: adjusting local clock by 29.902263s
Nov  3 22:48:04 server1 ntpd[21169]: adjusting local clock by 29.791393s
Nov  3 22:51:21 server1 ntpd[21169]: adjusting local clock by 29.763237s
Nov  3 22:54:22 server1 ntpd[21169]: adjusting local clock by 29.619058s
Nov  3 22:57:34 server1 ntpd[21169]: adjusting local clock by 29.510606s
Nov  3 23:00:43 server1 ntpd[21169]: adjusting local clock by 29.455033s
Nov  3 23:03:36 server1 ntpd[21169]: adjusting local clock by 29.390589s
Nov  3 23:05:05 server1 ntpd[21169]: adjusting local clock by 29.264441s
Nov  3 23:09:19 server1 ntpd[21169]: adjusting local clock by 29.189259s
Nov  3 23:11:48 server1 ntpd[21169]: adjusting local clock by 29.101459s
Nov  3 23:15:14 server1 ntpd[21169]: adjusting local clock by 29.017875s
Nov  3 23:18:14 server1 ntpd[21169]: adjusting local clock by 28.906337s

2 Answers 2

5

Make sure your host's clock (hardware) and NTP is correct. Is it? If not, your guest will be fighting to keep time...

Do you have VMWare tools installed in your guest?

5
  • The KB recommends not using host clock sync, so we have that disabled. kb.vmware.com/selfservice/microsites/… and yes vmware tools is installed. Nov 3, 2012 at 22:44
  • 2
    I didn't say host clock sync. I said "host clock". Is the system's clock set properly?
    – ewwhite
    Nov 3, 2012 at 22:46
  • oh ok sorry, so are you referring to the vmware hosts hardware clock? Nov 3, 2012 at 22:47
  • if so, just checked and yes all hosts are running ntpclient to a reliable source. Nov 3, 2012 at 22:52
  • How are the other VM's on the system doing with regard to time?
    – ewwhite
    Nov 4, 2012 at 13:29
3

It turns out because I didn't specify the iburst flag on any of my servers in ntp.conf, it didn't do a big jump to correct the time. After about 12 hours it had settled itself down and now is spot on accurate.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .