Brandon Davidson put forth on 1/20/2011 11:22 PM:
Stan,
On 1/20/11 7:45 PM, "Stan Hoeppner" stan@hardwarefreak.com wrote:
What you're supposed to do, and what VMWare recommends, is to run ntpd _only in the ESX host_ and _not_ in each guest. According to: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displ ayKC&externalId=1006427
Did you read the document you linked? As was mentioned on this list fairly recently, that's not been the recommendation for quite some time. To the contrary:
I didn't read the bottom, no. They've changed the rec. Contact VMWare and ask them why they reversed themselves on their previous recommendation.
=== NTP Recommendations Note: In all cases use NTP instead of VMware Tools periodic time synchronization. (...) When using NTP in the guest, disable VMware Tools periodic time synchronization.
Simply put, they made this change to lower support calls for time sync issues. Running ntpd inside each guest is unnecessary bloat.
We run the guests with divider=10, periodic timesync disabled, and NTP on both the host and the guest. We have not had any time problems in several years of operation.
I'm glad it works for you. You can achieve the same results without running ntpd inside the guests and without running the vmtools time sync in the guests, doing exactly what I mentioned. Again, I helped them write the early book on this back in '06 before they had a decent time keeping strategy. If you recall, back then, nptd wasn't even installed in the ESX console by default. You had to manually install and configure it.
As with many things in this tech world of ours, there are many ways to skin the same cat and achieve the same result. I have fairly intimate knowledge of both the Linux kernel timer and the ntp protocol due to the serious amount of research I had to do 4+ years ago. If you had the same knowledge, you too would realize it's just plain silly to run ntpd redundantly inside the host and guest operating systems atop the same physical machine.
The single biggest reason is that the ntp drift file in the guest instantly becomes dirty after a vmotion because the drift file tracks the physical hardware clock. This is virtualized to guest by the ESX kernel. Once you vmotion the drift characteristics have changed as they're slightly different on each physical host, and thus each ESX kernel.
Thus, even though the guest clock is still relatively accurate after a vmotion, why use ntpd with drift inside the guest if the drift isn't being used properly? Ergo, why not eliminate ntpd, which is unnecessary, and simply run an ntpdate periodically, based on SA documented drift over 30 days, as I do?
Again, you get the same, or sufficiently similar result, but without an extra unnecessary daemon running in each Linux guest. Try it yourself. Disable ntpd on one of your guests and cron ntpdate each midnight against your local ntpd server. After a few days report back with your results.
-- Stan