FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Red Hat Linux

 
 
LinkBack Thread Tools
 
Old 11-07-2008, 08:49 AM
"Kenneth Holter"
 
Default NTP problem for virtual RHEL 4 server on VmWare

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@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-07-2008, 05:27 PM
Ian Lists
 
Default 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@gmail.com> 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@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-07-2008, 05:50 PM
"Northrup, Wilson"
 
Default 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@redhat.com
[mailto:redhat-list-bounces@redhat.com] 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@gmail.com> 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@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?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@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-10-2008, 06:43 AM
"Andre Dill"
 
Default NTP problem for virtual RHEL 4 server on VmWare

Hi,

I had the same problem with my RHEL 4 and 5 servers. I found the KB article from VMWare to be very helpful.

http://kb.vmware.com/kb/1006427

Regards,

--
Andre Dill
Senior Systems Administrator
DataCash

Tel (Direct): +27 (0)21 528 4618

DataCash (PTY) Ltd, No1 Waterview Park, Century City Boulevard,
Century City. 7446. Cape Town, South Africa.

Tel:* +27 (0)21 528 4500
Fax: +27 (0)21 528 4570

www.datacash.com


> -----Original Message-----
> From: redhat-list-bounces@redhat.com [mailto:redhat-list-
> bounces@redhat.com] On Behalf Of Kenneth Holter
> Sent: 07 November 2008 11:49 AM
> To: redhat-list@redhat.com
> Subject: NTP problem for virtual RHEL 4 server on VmWare
>
> 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@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list

DISCLAIMER: This email and any files transmitted with it are confidential to DataCash Group plc and its group companies. It is intended only for the person to whom it is addressed. If you have received this email in error, please forward it to info@datacash.com with the subject line "Received in Error". If you are not the intended recipient you must not use, disclose, copy, print, distribute or rely on this email or any transmitted files. DataCash Ltd is registered in England and Wales no. 3430157. DataCash Ltd is part of the DataCash Group plc. DataCash Group plc is registered in England and Wales no. 3168091. DataCash Ltd and DataCash Group plc registered address is Descartes House, 8 Gate Street, London, WC2A 3HP, United Kingdom.

Save a tree...Please only print this page if essential


--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-10-2008, 10:59 AM
"Kenneth Holter"
 
Default NTP problem for virtual RHEL 4 server on VmWare

Thank you for the link.

I'll see if the kernel parmameters solves the problem. I'll try this
solution before shutting off NTP on the client, as this complies better with
out monitoring setup.

I noticed in the document that "..In all cases use NTP instead of Vmware
tools periodic time synchronization". Is this periodic time sync what
happens if I set "tools.syncTime = TRUE"?

I was asked for details of the Vmware host, so here they are:

- PowerEdge R900
- ESX server 3.5.0

Regards,
Kenneth


On 11/10/08, Andre Dill <Andre.Dill@datacash.co.za> wrote:

> Hi,
>
> I had the same problem with my RHEL 4 and 5 servers. I found the KB article
> from VMWare to be very helpful.
>
> http://kb.vmware.com/kb/1006427
>
> Regards,
>
> --
> Andre Dill
> Senior Systems Administrator
> DataCash
>
> Tel (Direct): +27 (0)21 528 4618
>
> DataCash (PTY) Ltd, No1 Waterview Park, Century City Boulevard,
> Century City. 7446. Cape Town, South Africa.
>
> Tel: +27 (0)21 528 4500
> Fax: +27 (0)21 528 4570
>
> www.datacash.com
>
>
> > -----Original Message-----
> > From: redhat-list-bounces@redhat.com [mailto:redhat-list-
> > bounces@redhat.com] On Behalf Of Kenneth Holter
> > Sent: 07 November 2008 11:49 AM
> > To: redhat-list@redhat.com
> > Subject: NTP problem for virtual RHEL 4 server on VmWare
> >
> > 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@redhat.com?subject=unsubscribe
> > https://www.redhat.com/mailman/listinfo/redhat-list
>
> DISCLAIMER: This email and any files transmitted with it are confidential
> to DataCash Group plc and its group companies. It is intended only for the
> person to whom it is addressed. If you have received this email in error,
> please forward it to info@datacash.com with the subject line "Received in
> Error". If you are not the intended recipient you must not use, disclose,
> copy, print, distribute or rely on this email or any transmitted files.
> DataCash Ltd is registered in England and Wales no. 3430157. DataCash Ltd is
> part of the DataCash Group plc. DataCash Group plc is registered in England
> and Wales no. 3168091. DataCash Ltd and DataCash Group plc registered
> address is Descartes House, 8 Gate Street, London, WC2A 3HP, United Kingdom.
>
> Save a tree...Please only print this page if essential
>
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-10-2008, 12:01 PM
"Andre Dill"
 
Default NTP problem for virtual RHEL 4 server on VmWare

Setting "tools.syncTime = TRUE" only has an effect if you have the VMwareTools rpm installed and started. In which case the VMwareTools will periodically update the system time.

/bin/rpm -qa | /bin/grep VMwareTools

/sbin/chkconfig --list vmware-tools

/bin/ps axf | /bin/grep vmware-guestd

will all help in determining if VMwareTools is installed and running.

Regards,

--
Andre Dill
Senior Systems Administrator
DataCash

Tel (Direct): +27 (0)21 528 4618

DataCash (PTY) Ltd, No1 Waterview Park, Century City Boulevard,
Century City. 7446. Cape Town, South Africa.

Tel:* +27 (0)21 528 4500
Fax: +27 (0)21 528 4570

www.datacash.com


> -----Original Message-----
> From: redhat-list-bounces@redhat.com [mailto:redhat-list-
> bounces@redhat.com] On Behalf Of Kenneth Holter
> Sent: 10 November 2008 13:59 PM
> To: General Red Hat Linux discussion list
> Subject: Re: NTP problem for virtual RHEL 4 server on VmWare
>
> Thank you for the link.
>
> I'll see if the kernel parmameters solves the problem. I'll try this
> solution before shutting off NTP on the client, as this complies better
> with
> out monitoring setup.
>
> I noticed in the document that "..In all cases use NTP instead of
> Vmware
> tools periodic time synchronization". Is this periodic time sync what
> happens if I set "tools.syncTime = TRUE"?
>
> I was asked for details of the Vmware host, so here they are:
>
> - PowerEdge R900
> - ESX server 3.5.0
>
> Regards,
> Kenneth
>
>
*SNIP*

DISCLAIMER: This email and any files transmitted with it are confidential to DataCash Group plc and its group companies. It is intended only for the person to whom it is addressed. If you have received this email in error, please forward it to info@datacash.com with the subject line "Received in Error". If you are not the intended recipient you must not use, disclose, copy, print, distribute or rely on this email or any transmitted files. DataCash Ltd is registered in England and Wales no. 3430157. DataCash Ltd is part of the DataCash Group plc. DataCash Group plc is registered in England and Wales no. 3168091. DataCash Ltd and DataCash Group plc registered address is Descartes House, 8 Gate Street, London, WC2A 3HP, United Kingdom.

Save a tree...Please only print this page if essential


--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-12-2008, 03:47 PM
"Eric Sisler"
 
Default NTP problem for virtual RHEL 4 server on VmWare

On Fri, Nov 7, 2008 at 2:49 AM, Kenneth Holter <kenneho.ndu@gmail.com>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:



Early on I went through the frustrations with time & NTP problems on RHEL 4
virtual machines. I've used a number of the earlier suggestions, including
various boot time & VMware configuration options. I even went so far as to
compile a custom kernel with the clock frequency set back to 100, as it was
for the 2.4.x kernels. Overall it didn't seem like any of the boot time or
VMware config options made that much difference. Recompling the kernel
works, but gets to be a lot of overhead after awhile.

Now for the odd part: Currently my RHEL4 VMs have time sync enabled in the
VMware config file & also have NTP running. It seems that the longer NTP
runs, the more accurate the time gets on the VM. When booting a "new" VM,
it wasn't uncommon for NTP to adjust the time by 20-30 seconds. Once the VM
gets a bit "older" & NTP has been running longer, when rebooting the VM
clock adjustment goes down to around 5-6 seconds. I suspect part of this
has to do with the frequency & adjustment history recorded by NTP.

The updated VMware KB may be of some help as well. Good luck!

-Eric
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-13-2008, 07:25 AM
"Kenneth Holter"
 
Default NTP problem for virtual RHEL 4 server on VmWare

Interesting observation. Our troublesome VM has been running for quite a log
while, though, and it still seems quite unstable. We just rebooted it with
the kernel parameters mentioned in http://kb.vmware.com/kb/1006427 (thank
you Mr. Dill), and I'll post the results back here in a day or two.
Hopefully it will solve our problem, even thogh it didn't solve yours.

What puzzles me is why this VM drifts so much, while most of our other VMs
doens't (at least not more than NTPd can handle).


On 11/12/08, Eric Sisler <lbylnxgek@gmail.com> wrote:
>
> On Fri, Nov 7, 2008 at 2:49 AM, Kenneth Holter <kenneho.ndu@gmail.com
> >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:
>
>
>
> Early on I went through the frustrations with time & NTP problems on RHEL 4
> virtual machines. I've used a number of the earlier suggestions, including
> various boot time & VMware configuration options. I even went so far as
> to
> compile a custom kernel with the clock frequency set back to 100, as it was
> for the 2.4.x kernels. Overall it didn't seem like any of the boot time or
> VMware config options made that much difference. Recompling the kernel
> works, but gets to be a lot of overhead after awhile.
>
> Now for the odd part: Currently my RHEL4 VMs have time sync enabled in the
> VMware config file & also have NTP running. It seems that the longer NTP
> runs, the more accurate the time gets on the VM. When booting a "new" VM,
> it wasn't uncommon for NTP to adjust the time by 20-30 seconds. Once the
> VM
> gets a bit "older" & NTP has been running longer, when rebooting the VM
> clock adjustment goes down to around 5-6 seconds. I suspect part of this
> has to do with the frequency & adjustment history recorded by NTP.
>
> The updated VMware KB may be of some help as well. Good luck!
>
> -Eric
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-13-2008, 01:53 PM
"Kenneth Holter"
 
Default NTP problem for virtual RHEL 4 server on VmWare

We adjusted the kernel parameters this morning, and the result looks
promising:


13 Nov 08:01:02 ntpdate[6253]: adjust time server 1.2.3.4 offset 0.041978
sec
13 Nov 09:01:01 ntpdate[14110]: adjust time server 1.2.3.4 offset -0.426118
sec
13 Nov 10:01:02 ntpdate[24901]: adjust time server 1.2.3.4 offset -0.151613
sec
13 Nov 11:01:01 ntpdate[3253]: adjust time server 1.2.3.4 offset 0.244806
sec
13 Nov 12:01:01 ntpdate[14023]: adjust time server 1.2.3.4 offset 0.256945
sec
13 Nov 13:01:02 ntpdate[25138]: adjust time server 1.2.3.4 offset -0.058973
sec
13 Nov 14:01:01 ntpdate[3482]: adjust time server 1.2.3.4 offset 0.144722
sec
13 Nov 15:01:01 ntpdate[12936]: adjust time server 1.2.3.4 offset -0.019486
sec


I'll keep monitoring it, but if nothing else comes up I think I'll settle
for this solution.

Thansk for all the help.


Regards,
Kenneth


On 11/13/08, Kenneth Holter <kenneho.ndu@gmail.com> wrote:
>
>
> Interesting observation. Our troublesome VM has been running for quite a
> log while, though, and it still seems quite unstable. We just rebooted it
> with the kernel parameters mentioned in http://kb.vmware.com/kb/1006427 (thank
> you Mr. Dill), and I'll post the results back here in a day or two.
> Hopefully it will solve our problem, even thogh it didn't solve yours.
>
> What puzzles me is why this VM drifts so much, while most of our other VMs
> doens't (at least not more than NTPd can handle).
>
>
> On 11/12/08, Eric Sisler <lbylnxgek@gmail.com> wrote:
>>
>> On Fri, Nov 7, 2008 at 2:49 AM, Kenneth Holter <kenneho.ndu@gmail.com
>> >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:
>>
>>
>>
>> Early on I went through the frustrations with time & NTP problems on RHEL
>> 4
>> virtual machines. I've used a number of the earlier suggestions,
>> including
>> various boot time & VMware configuration options. I even went so far as
>> to
>> compile a custom kernel with the clock frequency set back to 100, as it
>> was
>> for the 2.4.x kernels. Overall it didn't seem like any of the boot time
>> or
>> VMware config options made that much difference. Recompling the kernel
>> works, but gets to be a lot of overhead after awhile.
>>
>> Now for the odd part: Currently my RHEL4 VMs have time sync enabled in
>> the
>> VMware config file & also have NTP running. It seems that the longer NTP
>> runs, the more accurate the time gets on the VM. When booting a "new" VM,
>> it wasn't uncommon for NTP to adjust the time by 20-30 seconds. Once the
>> VM
>> gets a bit "older" & NTP has been running longer, when rebooting the VM
>> clock adjustment goes down to around 5-6 seconds. I suspect part of this
>> has to do with the frequency & adjustment history recorded by NTP.
>>
>> The updated VMware KB may be of some help as well. Good luck!
>>
>> -Eric
>> --
>> redhat-list mailing list
>> unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
>> https://www.redhat.com/mailman/listinfo/redhat-list
>>
>
>
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-13-2008, 03:33 PM
"Eric Sisler"
 
Default NTP problem for virtual RHEL 4 server on VmWare

Kenneth Holter <kenneho.ndu@gmail.com> wrote:

> What puzzles me is why this VM drifts so much, while most of our other VMs
> doens't (at least not more than NTPd can handle).

The Linux 2.6.x kernel is largely the culprit. Are your other VMs 2.4
kernels? The kernel frequency HZ changed between the 2.4.x & 2.6.x
kernels. A snippet of a *much* earlier posting. Unfortunately I
don't have the name to give credit where it's due:

"The 2.4 kernels have HZ set to 100, while 2.6 kernels have HZ set to
1000. This value affects the frequency of clock interrupts that are
generated, and those are per-CPU (that's why the problem gets worse
when you go SMP). This change in frequency is the main reason for the
clock problems for Linux guests. That is why your RH 7.3 works OK,
while RHEL 4 doesn't. Another drawback of this change in value of HZ
is that 2.6 kernels will waste more CPU cycles than 2.4 kernels when
idling. Much more. When you have several SMP Linux 2.6 guests, just
to keep the kernels running will waste a lot of the available CPU time.

One recommendation from VmWare is to recompile the 2.6 kernel with HZ
reduced back to 100 (as it was in 2.4 kernels). I haven't yet
attempted this, but I heard reports that it works nicely.

Apperently the behaviour of Windows is much closer to 2.4 Linux
kernels. Hence you don't see the problem that much there."

As I mentioned earlier, adding a small patch to set the kernel clock
HZ back to 100 & building custom RPMs does work, but can be time
consuming if you have many servers to maintain. I *think* I have notes
about the process somewhere if anyone's interested.

-Eric

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

Thread Tools




All times are GMT. The time now is 10:43 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org