Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

My Centos 5 VM is drifting time.

I have scoured different answers to solve this problem.

I've looked at the VMWare's tips and added tinker panic 0 on top of my ntp.conf file. I also changed the kernel parameters to:

kernel /vmlinuz-2.6.18-194.32.1.el5 ro root=/dev/VolGroup00/LogVol00 notsc divider=10 clocksource=acpi_pm

It worked for a while and then I recently restarted my machine and it is back to its old ways again. I'm not sure how to make it work again even though I followed the same procedure as last time.

Any ideas?

Here is how my ntpq -pn looks like:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 122.226.192.4   204.152.184.72   2 u   32   64  377   68.894  38873.7 5711.48
 116.193.170.16  192.93.2.20      2 u   35   64  177  135.991  45598.7 10745.4
 116.193.83.174  192.43.244.18    2 u   38   64  377   76.782  43291.2 8170.13
 61.153.197.226  209.81.9.7       2 u   32   64  377   83.523  34288.8 6679.24
share|improve this question
1  
When you enabled NTP, did you disable the time sync in the Vmware tools? –  Zoredache Aug 5 '11 at 20:39
    
Nope. This server used to be fine with syncing with NTP, but recently the vendor helped setup a VLAN for me and then I enabled a new eth1 interface and had to restart the system and this started happening. Not sure what the cause is. –  lamp_scaler Aug 6 '11 at 1:50
add comment

4 Answers

up vote 1 down vote accepted

I feel like a complete moron. Just realized I was loading the wrong default kernel on grub and the grub options had a misspelling in one of the values. I fixed it now and it is working...

For those who are curious, I mispelled:

clocksource=acpi_pm

as

clocksource=acpi_p

Lesson learned.

share|improve this answer
add comment

Is this a x86 or x86_64 kernel? I see you have already gone through the VMWare documentation - have you tried setting "clock=pit"?

I have seen this specific behavior when using AMD CPUs, although it has been a while (specifically, I saw it on AthlonXP and Athlon64 CPUs about 6-8 years ago), and was only able to fix it by then by completely disabling any sort of CPU power management affecting the TSC on the host system (this would be anything that alters the CPU clock frequency), and forcing my Linux guests to run with "clock=pit". Intel chips to my knowledge never were affected - I guess their TSC implementation was better.

share|improve this answer
    
It's a 32bit system. I believe it is an Intel. –  lamp_scaler Aug 6 '11 at 1:53
    
Never seen that on an Intel CPU. I'd still try setting "clock=plt" on the kernel command line, but beyond that, I am at the end of my wisdom. –  Andreas Turriff Aug 8 '11 at 16:46
add comment

Have you looked at VMWare's Timekeeping best practices for Linux guests?

Try either

divider=10 clocksource=acpi_pm

or

divider=10

in your bootloader config.



You'll also want to try:

vmware-guestd --cmd "vmx.set_option synctime 1 0"

to stop contention between the VMWare guest tools and NTPd.

share|improve this answer
add comment

Your ntpq output is missing any symbol to the left of the upstream hosts to indicate what your ntp server thinks of them.

Normally, one of them will have a * next to it and the others will have a + or a - The * is the currently chosen time source, + is a candidate and - has been excluded from the candidates. There are other symbols but you rarely see them.

A lack of symbols suggests to me that your ntp server is not trying to set its own time from any other servers and this is probably due to permissions.

Check out any "restrict" lines in your config or feel free to add them to your question.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.