Since the advent of virtualization (most notoriously VMware ESX) time keeping has gotten to be much more difficult. I know back in my unix admin days, I spent more than a few days on problematic Linux kernels on VMs under ESX (made far worse when hosts were over provisioned and VMs were starved for CPU readiness). I know later enhancements like tick-less kernels may have helped, but I do not envy anyone who has to wrestle these beasts.
I spent about 2+ weeks in early 2003/2004 trying to get VMware Server to properly keep the time in Sync. I had memorized the VMware whitepaper on the topic, and had followed every possible bit of advice they offered (including not using NTPD) - nothing worked. Eventually just cronned ntpdate to run every minute and that resolved the issue on all our systems.
This, by the way, horrified all our NTPD theoreticians, who made it clear that running ntpdate was going to cause catastrophic things to occur in our Operations environment - but, given that our logs were all getting progressively more and more useless as we were unable to correlate times for events between servers - the worst case scenario (in my mind) had already occurred.
I don't recall any particularly negative side effects as a result of our ntpdate sledgehammer.
I presume things have gotten better in the last 10 years with VMware.
Years ago, the answer was to run NTP on the host and use VMWare Tools to help ensure that good quality time was served to the clients. That's when the earlier versions of the page at <http://support.ntp.org/bin/view/Support/KnownOsIssues#Sectio... were written.
Since then, that advice has apparently been recanted.
The ultimate problem with any virtualization system is the frequency and accuracy of clock updates to the client, and the loss of clock interrupts.
To the degree you can solve that problem, protocols like NTP can work reasonably well to monitor and correct for various types of known clock issues.
Windows time sync only cares about being accurate to 5 !minutes, for Kerberos. HyperV and makes Windows not even able to be that accurate. Oddly enough, Linux guests have no trouble with subsecond accuracy.
I'm told the w32time codebase is not something MS employees like to look at.
I don't think that w32time is something that users like to look at! I recall a situation where you run w32time on a server and it runs fine and doesn't report an error, but still silently ignore the option you set as it is using another time source from another machine that it has designated a master.
I could be wrong, but I was disappointed that the utility didn't return any errors when it knew that it was going to ignore you.
I run various production systems in both VMware ESX and VirtualBox, and I have time issues in all VMs, regardless of hypervisor vendor. The VM tools are installed and operating "properly." The host machine clocks are synced correctly with ntp. Yet the VMs will sometimes get tens of minutes out of alignment in short order.
At this point I'm thinking I need to run ntp on the physical hardware with the least jitter, then just run ntpdate in a cron job on all the VMs. This would work better than ntp clients in the VMs or the VM tools.
