We've just introduced SUSE Enterprise 10 into our environment to implement Novell Access Manager (NAM) and have started them off on a VMware host. NAM is pretty time sensitive so one of my application admins starting complaining about the time drifting too much. This is the first I've heard of it - we have about 20 Red Hat VMs and haven't noticed much of a time drift and all of the rest of our VMs are Windows.

Windows synchs up with the domain controllers and they seem to be just fine with how their time is kept. I looked on some of our Red Hat VMs and noticed some time drifting there but from what I found on google, Red Hat has fixed their issue with time keeping with their new kernel.

The so-called "fixes" I've found for this is to add parameters to the kernel in SUSE's /boot/grub/menu.lst to help it out (acpi=off and clock=pit). I've done this and it still seems to drift the time. Another workaround is to use ntpdate -u <myTimeSourceIP> and schedule that as a cron job to run.

I'm wondering if anyone knows of or has dealt with this linux kernel time drifting in a virtual environment issue and what fixes they've used.

We've had time drifts all over the place...some 45 seconds drift in 24 hours, some as extreme as a 20 second drift in a span of only 90 seconds (reported from my application admin but I haven't seen it).

Chad

Hi.

Standard practice everywhere I've been is to set up a host as a time server somewhere on your network. That machine should get its time from GPS, or a radio clock, or from one of the Internet time server pools (assuming you can set up a host that faces out to the world).
Then set up ntpd.conf on all the Unix hosts to sync to that time server and switch on the ntpd service. All your machines will then have pretty much exactly the same time.

Dave

Yeah, we've suffered big time from that in previous places i've worked. One major thing to take out of it is to never use ntp within a vm. Make the time right on your host machine, and then let the vm's trust their clock. As you've seen there is lots of recommendations about changing the clock type. In terms of progressing forward more, the vmware forums do contain a lot of useful information about it. I can have a word with some contacts who were dealing with the issues more directly, as I do think they got a good solution in the end, and I bet it bites me in the arse in the future too.

http://www.vmware.com/pdf/vmware_timekeeping.pdf
http://www.djax.co.uk/kb/linux/vmware_clock_drift.html
http://communities.vmware.com/thread/120931

Looking at the 2nd link there, I *think* I do remember the disabling of smp to have had a big impact. VMware largely recommended different clock methods, with only modest improvements.

And I i wrote this ilikejam did recommend tight ntp implementations... again within vmware and other virtual environments, when you think about it, there should never ever be any need to change the time, as it is getting the time from another machine already, not a bios clock. With fluctuations in process scheduling and all that freaky stuff that a VM is subjected to by its host compared to a good old fashioned bit of tin, if you then add in another mechanism to make the time fluctuate, that poor VM is just going to get a really bad headache.