RE: NTP problem for virtual RHEL 4 server on VmWare



Along with the version of VMware software you are running, please also
indicate what hardware you are using.


-----Original Message-----
From: redhat-list-bounces@xxxxxxxxxx
[mailto:redhat-list-bounces@xxxxxxxxxx] On Behalf Of Ian Lists
Sent: Friday, November 07, 2008 1:28 PM
To: General Red Hat Linux discussion list
Subject: Re: NTP problem for virtual RHEL 4 server on VmWare

What version of VMWare are you running? Make sure you have vmware tools
installed on the guest and the .vmx file for the guest has
"tools.syncTime = "TRUE". If that is set to true, you should turn off
NTP on the guest and just let the physical host update the guest.



----- "Kenneth Holter" <kenneho.ndu@xxxxxxxxx> wrote:

Hei.


One of our RHEL 4 servers running on VmWare has a quite serious NTP
problem.
I know that NTP can be an issue when running red hat boxes on VmWare,
so as
a fix I put this small script in a file in /etc/cron.hourly:


[root@server cron.hourly]# cat ntpdate
#!/bin/sh
/etc/init.d/ntpd stop
ntpdate 1.2.3.4 >> /tmp/time_adjust.log
/etc/init.d/ntp


After investigating the "/tmp/time_adjust.log" file, I was quite
surprised
by the amount of drift found on one particular server. Consider this
extract
from the file:

6 Nov 20:00:01 ntpdate[19373]: step time server 1.2.3.4 offset
-60.504153
sec
6 Nov 20:00:52 ntpdate[19666]: step time server 1.2.3.4 offset
-8.735440
sec
6 Nov 20:01:00 ntpdate[19689]: step time server 1.2.3.4 offset
-1.635632
sec
6 Nov 20:54:06 ntpdate[24198]: step time server 1.2.3.4 offset
-415.894712
sec
6 Nov 21:01:01 ntpdate[24920]: adjust time server 1.2.3.4 offset
0.136833
sec
6 Nov 22:01:02 ntpdate[29943]: adjust time server 1.2.3.4 offset
-0.114253
sec
6 Nov 23:01:01 ntpdate[2519]: adjust time server 1.2.3.4 offset
-0.036345
sec
7 Nov 00:01:00 ntpdate[7577]: step time server 1.2.3.4 offset
-1.064935 sec
7 Nov 01:00:57 ntpdate[12697]: step time server 1.2.3.4 offset
-3.922577
sec
7 Nov 02:00:21 ntpdate[17733]: step time server 1.2.3.4 offset
-40.421825
sec
7 Nov 02:01:00 ntpdate[17777]: step time server 1.2.3.4 offset
-1.123175
sec
7 Nov 02:57:23 ntpdate[22542]: step time server 1.2.3.4 offset
-218.649820
sec
7 Nov 03:00:36 ntpdate[22900]: step time server 1.2.3.4 offset
-25.284528
sec
7 Nov 03:00:58 ntpdate[22940]: step time server 1.2.3.4 offset
-3.104130
sec
7 Nov 03:52:32 ntpdate[27430]: step time server 1.2.3.4 offset
-509.363952
sec
7 Nov 03:59:50 ntpdate[27943]: step time server 1.2.3.4 offset
-71.430354
sec
7 Nov 04:00:52 ntpdate[28236]: step time server 1.2.3.4 offset
-9.344907
sec
7 Nov 04:01:00 ntpdate[28259]: step time server 1.2.3.4 offset
-1.237651
sec
7 Nov 05:01:01 ntpdate[1363]: adjust time server 1.2.3.4 offset
0.390149
sec
7 Nov 06:01:01 ntpdate[6419]: adjust time server 1.2.3.4 offset
-0.185112
sec
7 Nov 07:01:02 ntpdate[11493]: adjust time server 1.2.3.4 offset
-0.228884
sec
7 Nov 08:00:59 ntpdate[16579]: step time server 1.2.3.4 offset
-2.166519
sec
7 Nov 09:00:38 ntpdate[21522]: step time server 1.2.3.4 offset
-23.169420
sec
7 Nov 09:01:02 ntpdate[21558]: adjust time server 1.2.3.4 offset
-0.492106
sec
7 Nov 09:59:26 ntpdate[26329]: step time server 1.2.3.4 offset
-95.154264
sec
7 Nov 10:00:55 ntpdate[26639]: step time server 1.2.3.4 offset
-5.997955
sec
7 Nov 10:01:01 ntpdate[26658]: step time server 1.2.3.4 offset
-0.506367
sec


Does anyone know what may be causing the RHEL box to drift as much as
500
seconds in only one hour?

Regards,
Kenneth Holter
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates (which may be known
outside the United States as Merck Frosst, Merck Sharp & Dohme or
MSD and in Japan, as Banyu - direct contact information for affiliates is
available at http://www.merck.com/contact/contacts.html) that may be
confidential, proprietary copyrighted and/or legally privileged. It is
intended solely for the use of the individual or entity named on this
message. If you are not the intended recipient, and have received this
message in error, please notify us immediately by reply e-mail and
then delete it from your system.


--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list



Relevant Pages

  • Re: NTP problem for virtual RHEL 4 server on VmWare
    ... I noticed in the document that "..In all cases use NTP instead of Vmware ... NTP problem for virtual RHEL 4 server on VmWare ... to DataCash Group plc and its group companies. ...
    (RedHat)
  • Re: Download RHEL4
    ... benefits over VMWare and a much better management API). ... contemporary tools on the server as well as in the guest domains. ... I'm running VMware Server on CentOS5.2 and on Fedora 9, there is no requirement for RHEL 3. ... Server runs on top of a host OS, ESX is the host. ...
    (linux.redhat)
  • RE: NTP problem for virtual RHEL 4 server on VmWare
    ... NTP problem for virtual RHEL 4 server on VmWare ... One of our RHEL 4 servers running on VmWare has a quite serious NTP ...
    (RedHat)
  • Re: Download RHEL4
    ... benefits over VMWare and a much better management API). ... contemporary tools on the server as well as in the guest domains. ... which does have significant performance benefits over VMware ... Linux kernel, it's running on RHEL 3, and putting monitoring tools on ...
    (linux.redhat)
  • Re: NTP problem for virtual RHEL 4 server on VmWare
    ... One of our RHEL 4 servers running on VmWare has a quite serious NTP ... has to do with the frequency & adjustment history recorded by NTP. ...
    (RedHat)