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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
| All times are GMT. The time now is 02:37 PM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.