[CentOS] ntpd

Wed Dec 12 13:07:50 UTC 2007
Blackburn, Marvin <mblackburn at glenraven.com>

 

-----Original Message-----
From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf
Of Luke Dudney
Sent: Wednesday, December 12, 2007 5:32 AM
To: CentOS mailing list
Subject: Re: [CentOS] ntpd

On 12/12/2007 05:50, Jason Pyeron wrote:
> I am running a server inside of VMWare, and the clock gains ~30 seconds
> every 1000 seconds or 1.03X.
>
> I need to keep the drift under the magic 1000 limit that ntpd kills its
> self, but despite setting maxpoll really low I get:
>
> Dec 11 23:58:14 host ntpd[4909]: kernel time discipline status change 41
> Dec 11 23:59:17 host ntpd[4909]: kernel time discipline status change 1
> Dec 11 23:59:17 host ntpd[4909]: time correction of -1123 seconds exceeds
> sanity limit (1000); set clock manually to the correct UTC time.
>
>
> /etc/ntp.conf:
>
> server time.intranet.pdinc.us maxpoll 7
>
> Ideas? If I cannot get ntpd working, then I will have to resort to a cron
*
> * * * * rdate -s time.intranet.pdinc.us
>
>   

I would love to see some clear, accurate guidance from anyone regarding 
time synchronisation within Linux VMs under VMware. From what I've been 
able to gather, VMware recommend that you disable any in-guest external 
synchronisation (ntp, windows time etc) and use vmware-tools to sync the 
time. For now the approach seems to involve trying random kernel boot 
options and a lot of reboots until you find something that works.

I'd be happy to have my understanding of this issue clarified!

cheers
Luke



Luke,
We have had similar problems with vm's running fast.  I was under the same
impression that you were about
the recommended method to sync time.  But after working the issue with
vmware for several months, they backed
down on their recommendation and stated that they did not recommend using
both methods togethter: syncing with host AND ntpd.
They said either would be fine, not both.  This didnt entirely fix my
problem -- still runs a second or two fast, but much better than before.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3921 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos/attachments/20071212/b43c96be/attachment-0005.bin>