[Dovecot] VMware and Time moved backwards

[Bill Cole]

At 8:27 PM +0200 5/21/08, Robert Henjes wrote:
>Hi,
>
>I followed the discussions regarding the "time moved backward" problem
>and the use of ntp in such cases. At our department we are running two
>dovecot servers within an vmware server environment, and unfortunately
>the timedrift (with ntpd active) exceeds sometimes up to 30 minutes
>virtual drift within 10 minutes realtime (mostly into future). This is
>due to some overcorrections within the TSC algorithms of the vmware
>virtual machine.
>
>More information and some hints to workaround are documented here:
>http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1420

That page seems to say that running ntpd inside a VMware guest is not 
a good choice. I would think that you'd be best off doing what your 
vendor advises on that page, at least as a start, rather than 
trusting in the consistently brilliant and consistently unified 
consensus view of the Dovecot admin community on a question which is 
only very tangentially related to Dovecot.


>Nevertheless we are currently working on evaluating a stable solution by
>doing some system measurements, which would be the best option to cope
>with this problem, since the XEN environment seems to have a similar
>issue.
>
>Running "ntpdate -u" as a cronjob is not an option due to two facts:
>a) Time is moving quickly and may cause "major problems" ;)
>b) It is not recommended by the vmware team itself as well
>
>We are currently considering two options:
>a) Using the "clock=pit" kernel option, which may cause the system to be
>to slow
>b) using vmware tools and use only the ntp synchronisation of the host
>(we have currently only little experience with this). Also vmware tools
>are somewhat critical in case of updates. So our intention was to
>use as less vmware specific things as possible within the virtual
>machine, so only our host itself depends on vmware specific software.
>
>The question is, which option would you prefer? Is there another
>solution beside the mentioned ones?

I think that trying to avoid VMware-specific software in a VMware 
environment is  unwise. VMware software is what provides your virtual 
system with a clock.


-- 
Bill Cole
bill at scconsult.com