I have some odd behaviour running ntpd on a rhel 6.5 machine. This machine runs as a virtual machine on a kvm host (also rhel) and this host has the correct time (within a few ms), and an ntpd that keeps it correct.
What I noticed is that after i do an ntpdate -u the time will eventually become good, and usually stay there. However Red Hat recommends that one runs ntpd also on virtual guests. So I start ntpd. Now this goes well on most of our hosts, except for a few where I see a wierd behaviour.
On those hosts as soon as ntpd is started time starts to lag on those systems by about 0.5 ms/sec (or the 500 ppm that is the maximum ntpd will slew time by). And this even before the ntpd has aquired a peer it can synch with...
Stopping ntpd stops the time from drifting. Start it, and time start drifting again.
In other words, I seem to have an ntpd that on some systems (and this baffles me, as they are all identical) does more or less the exact oposite of what it should do.
My ntp.conf is fairly straightforward:
tinker panic 0
# Permit time synchronization with our time source, but do not'
# permit the source to query or modify the service on this system.'
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
server time.mydomain.com
# Driftfile.
driftfile /var/lib/ntp/drift
What could be the cause of this?
It sounds like ntpd has an incorrect idea of the virtual machine's clock drift, and is incorrectly compensating for drift. Stop ntpd, delete the
driftfile
and restart ntpd.If this doesn't fix the issue, consider switching to chrony. This is the default NTP client in EL 7, and is available in EPEL for EL 6.
I had not encounter such a problem before, since my VMs run on either VirtualBox or ESXi. Both solutions expose the clock of the host to the guest machine and thus I faced no problems with the clocks. I would send you to try on the VMs with the problematic clocks to use the Host machine as NTP server (and of course to modify the ntp.conf of the host machine accordingly).
Anyway, I found the following extremely interesting.
http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.2.
And of course, if you run RHEL (and not CentOS), I would strongly recommend to you to open a support ticket.