Its right to say KVM or XEN is much much better than most VMware products. I would never ever recommend any Virtualization software over KVM or XEN. But for this problem of VMware server and host/guest time synchronization I can tell you that disabling any guest site time synchronization like ntp or chrony (although chrony could be the better choice when it comes to big time drifts) could solve your problem. You have also to make sure that “vmware-tools” are compiled against the actual guest kernel and running correctly (just check dmesg) and that “cat /proc/cmdline” should give you something like “clock=pit”. Further “tools.syncTime = true” should also be set in the vmx guest file like mentioned above.

We have migrated all that we can to Xen and will be leaving VMWare’s silly toys behind to go to enterprise level from here on out. We started with VMWare when Xen wasn’t enterprise ready yet years ago so we don’t regret the decision but they just aren’t in the game anymore. They are driven by marketing, not engineering, and it really shows in their products.

I read your article (I had to read it in order to reply!)

Your article suggests that ntpdate doesn’t handle issues – this is completley right – it doesn’t handle anything all, it just changes the system time by making it leap forwards or backwards. Any big leap in time, particularly backwards will subtely break running applications.

Rather than use ntpdate (which is a workaround) you need to fix your clock skew problem and then use ntpd. Using ntpdate is a poor solution which puts unnecessary strain on the public ntp servers.

All recent versions of VMware and Linux do not have any clock skew issues. Which versions are you running?

NTPDATE is NOT subject to the skew issues that NTPD is, it simply matches the time without trying to bring the time into line gently. This is required when the drift is too great as it is here.

Please read the article before you make statements that don’t even relate to the subject matter at hand. This entire article was about dealing with time drift when your suggestions (the starting point of the article) don’t work. You’ve apparently missed the entire point.

> Ntpdate is not subject to the skew and offset issues that ntpd is.

I don’t see where you get this idea from. This is wrong: if you configure ntpd correctly (i.e. you use sync at boot and correct from then on) you will see no such issues with ntpd.