VMware and Time moved backwards

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

VMware and Time moved backwards

Robert Henjes

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

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?

According to Timo's postings, workarounds within the dovecot itself to
cope with "time moved backward" problems are not planned yet to be
impelented.

So best regards,
Robert


Reply | Threaded
Open this post in threaded view
|

Re: VMware and Time moved backwards

Bill Cole-4
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
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: VMware and Time moved backwards

Peter Hessler
In reply to this post by Robert Henjes
never ever ever run ntp on virtual hardware.

instead, run ntp on the host hardware, and tell the client to always
obey the bios clock.  I add "* * * * * /sbin/hwclock --localtime --hctosys"
to my crontab for that.



On 2008 May 21 (Wed) at 20:27:09 +0200 (+0200), 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
:
: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?
:
:According to Timo's postings, workarounds within the dovecot itself to
:cope with "time moved backward" problems are not planned yet to be
:impelented.
:
:So best regards,
:Robert
:
:

--
Magpie, n.:
        A bird whose thievish disposition suggested to someone that it
might be taught to talk.
                -- Ambrose Bierce, "The Devil's Dictionary"
Reply | Threaded
Open this post in threaded view
|

Re: VMware and Time moved backwards

Robert Henjes
In reply to this post by Robert Henjes
Thank you for the prompt answers


@Luuk Vosslamber

>finding correct values for the following entrys in your vmware(host)
>config file might solve some things:
>host.cpukHz = 1596000  <== depends on processor speed ;-)
>host.noTSC = TRUE
>ptsc.noTSC = TRUE
>hostinfo.noTSC = TRUE
>tools.syntime = TRUE
>
>Above values go with the presumption that the host CPU is running at a
>fixed frequency. The variable frequency seems to be the origin of this
>problem..

We tried your parameters already, but they are not an option, unless you
have the following
a) machine smp disabled (enabled in our case)
b) other machines on the host system have really low load
c) vmware tools should not be missing on guest


@Peter Hessler

>never ever ever run ntp on virtual hardware.
>
>instead, run ntp on the host hardware, and tell the client to always obey
the bios clock.  I add "* * * * * /sbin/hwclock --localtime -->hctosys"
>to my crontab for that.

Thank you very much Peter, this hint opens up a bunch of new possibilities
only mentioning "adjtimex" ...

BUT: And this brings me back to, why I posted this issue to the dovecot
mailinglist and not elsewhere:
All these guest based solutions lead to a fixed time movement (we used
previously ntpdate -u every 7 minutes, ntp itself synchronizes every 11
minutes with the hardware clock for calculating drifts), which happens about
once per week, that the time movement backward is larger than 11 seconds
between two dovecot imap operations, which leads to an immediate shutdown of
the dovecot process. All other services on these machine can cope with this.

So the question is how to get these adjustments smooth or close to realtime.

Best regards,
Robert

Btw.: We are running Dovecot 1.0.13 from Debian etch-backports (which is an
important information since debian seems to have its own rules ;) )

 

Reply | Threaded
Open this post in threaded view
|

Re: VMware and Time moved backwards

Bjørn T Johansen
In reply to this post by Peter Hessler
Why not? I have been running ntp inside vmware for many years now, without any problems....

BTJ

On Wed, 21 May 2008 12:30:01 -0700
Peter Hessler <[hidden email]> wrote:

> never ever ever run ntp on virtual hardware.
>
> instead, run ntp on the host hardware, and tell the client to always
> obey the bios clock.  I add "* * * * * /sbin/hwclock --localtime --hctosys"
> to my crontab for that.
>
>
>
> On 2008 May 21 (Wed) at 20:27:09 +0200 (+0200), 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
> :
> :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?
> :
> :According to Timo's postings, workarounds within the dovecot itself to
> :cope with "time moved backward" problems are not planned yet to be
> :impelented.
> :
> :So best regards,
> :Robert
> :
> :
>
Reply | Threaded
Open this post in threaded view
|

Re: VMware and Time moved backwards

Peter Hessler
the short explanation is that both the VM container and ntp adjust the
clock tick, and both think they are the only application that does so.  
There are longer explanations in many places around the internet.


On 2008 May 21 (Wed) at 23:39:17 +0200 (+0200), Bj??rn T Johansen wrote:
:Why not? I have been running ntp inside vmware for many years now, without any problems....
:
:BTJ
:
:On Wed, 21 May 2008 12:30:01 -0700
:Peter Hessler <[hidden email]> wrote:
:
:> never ever ever run ntp on virtual hardware.
:>
:> instead, run ntp on the host hardware, and tell the client to always
:> obey the bios clock.  I add "* * * * * /sbin/hwclock --localtime --hctosys"
:> to my crontab for that.


--
"A power so great, it can only be used for Good or Evil!"
                -- Firesign Theatre, "The Giant Rat of Sumatra"
Reply | Threaded
Open this post in threaded view
|

Re: VMware and Time moved backwards

Scott Silva
In reply to this post by Bjørn T Johansen
on 5-21-2008 2:39 PM Bjørn T Johansen spake the following:
> Why not? I have been running ntp inside vmware for many years now, without any problems....
>
And I occasionally fail to come to a full stop at a stop sign, and don't get a
ticket, but is it the proper thing to do?



--
MailScanner is like deodorant...
You hope everybody uses it, and
you notice quickly if they don't!!!!


signature.asc (266 bytes) Download Attachment