Re: 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@xxxxxxxxx> wrote:

On Fri, Nov 7, 2008 at 2:49 AM, 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:



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@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



Relevant Pages

  • Re: NTP problem for virtual RHEL 4 server on VmWare
    ... We adjusted the kernel parameters this morning, ... One of our RHEL 4 servers running on VmWare has a quite serious NTP ... VMware config options made that much difference. ... has to do with the frequency & adjustment history recorded by NTP. ...
    (RedHat)
  • Re: Monitoring the leap second tonight
    ... While the kernel does step the clock backward, the clock reading routine should remember the last reading and not allow a backward adjustment, unless more than two seconds. ... As for the leap itself, all the radios, FreeBSDs, Solariba, Ultrax and Alphae leaped the leap correctly. ... The CDMA receiver with embedded Linux went bonkers; it took the leap 24 hours ago and stayed that way until after the leap tonight. ... I'm not sure what this means; the CDMA takes its cue from GPS and the CDMA receiver hands off to NTP. ...
    (comp.protocols.time.ntp)
  • Re: Time reset
    ... kernel exhibits this same drift instability. ... the same version of NTP, but different hardware, so I haven't completely ... He meant if you had minpoll say 8 or 10 it would make settling down ...
    (comp.protocols.time.ntp)
  • Re: Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync
    ... The kernel only changes it on a manual time set or when the estimated error overflows. ... * NTP would take a few minutes to obtain PLL lock with multiple time sources. ... *** Once convergence was complete the 0x40 UNSYNC bitwise flag would be reset in the kernel by NTP. ... The UNSYNC flag is not masked out in the API, ...
    (comp.protocols.time.ntp)
  • Re: ntp strangeness
    ... Try booting the kernel with the "noapic nolapic" parameters. ... I've been monitoring ntp on and off all day and noticed it was having to ... step the clock about -6 seconds every 5 to 10 minutes. ... fix works and the problem it addresses. ...
    (Debian-User)