[Dovecot] Fwd: Re: Dotlock dovecot-uidlist errors / NFS / High Load

Stan Hoeppner stan at hardwarefreak.com
Fri Jan 21 08:52:31 EET 2011


Brandon Davidson put forth on 1/20/2011 11:22 PM:
> Stan,
> 
> On 1/20/11 7:45 PM, "Stan Hoeppner" <stan at 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


More information about the dovecot mailing list