Re: [Dovecot] dovecot: Fatal: Time just moved backwards by 3909 seconds.
Charles Marcus wrote: On 11/30/2009 4:36 PM, Udo Rader wrote: Recent kernels should be able to keep the VM time synced using kvmclock clocksource... So I'll give clocksource=acpi_pm a chance and see how it turns out ... So for the sake of other peoples' nerves also facing this problem, the solution was to add "divider=10" as a kernel boot parameter. There is an good post about this problem here: http://forums.fedoraforum.org/showthread.php?t=211100 and this also leads to this document for VMWare giving an indication of what the suggested parameters for various distributions are: http://kb.vmware.com/kb/1006427 Did you not try the clocksource=kvm-clock? Or do you not have a new enough kernel (2.6.27+)? http://www.proxmox.com/forum/showthread.php?t=23814 No, unfortunately Centos 5.4 comes with a 2.6.18 kernel (though with many backports from newer versions). % uname -r 2.6.18-164.6.1.el5.centos.plusPAE % cat /sys/devices/system/clocksource/clocksource0/current_clocksource kvm-clock -- Udo Rader, CTO http://www.bestsolution.at http://riaschissl.blogspot.com
Re: [Dovecot] dovecot: Fatal: Time just moved backwards by 3909 seconds.
On 11/30/2009 4:36 PM, Udo Rader wrote: >>> Recent kernels should be able to keep the VM time synced using >>> kvmclock clocksource... >> So I'll give clocksource=acpi_pm a chance and see how it turns out ... > So for the sake of other peoples' nerves also facing this problem, the > solution was to add "divider=10" as a kernel boot parameter. > > There is an good post about this problem here: > > http://forums.fedoraforum.org/showthread.php?t=211100 > > and this also leads to this document for VMWare giving an indication of > what the suggested parameters for various distributions are: > > http://kb.vmware.com/kb/1006427 Did you not try the clocksource=kvm-clock? Or do you not have a new enough kernel (2.6.27+)? http://www.proxmox.com/forum/showthread.php?t=2381
Re: [Dovecot] dovecot: Fatal: Time just moved backwards by 3909 seconds.
Udo Rader wrote: Charles Marcus wrote: On 11/30/2009, Udo Rader (list...@bestsolution.at) wrote: The virtual guest is Centos 5.4 based with dovecot 1.2.8 (at first we also tried with the original 1.0.7 (?) dovecot shipped with Centos). I wrote "alleged time shift" because there is no timeshift whatsoever, or at least I don't notice it anywhere else. ntp is - of course ;-) - up and running and no other applications have time troubles and I've even disabled the local clock as a time reference. Of course you know not to use ntp on VMs, only on the host, right? :) heh, ok, ship hit an sunk :-) I was absolutely not aware of a "clocksource" kernel parameter, what a weird thing ... > Revent kernels should be able to keep the VM time synced using kvmclock clocksource... So I'll give clocksource=acpi_pm a chance and see how it turns out ... So for the sake of other peoples' nerves also facing this problem, the solution was to add "divider=10" as a kernel boot parameter. There is an good post about this problem here: http://forums.fedoraforum.org/showthread.php?t=211100 and this also leads to this document for VMWare giving an indication of what the suggested parameters for various distributions are: http://kb.vmware.com/kb/1006427 cheers! -- Udo Rader, CTO http://www.bestsolution.at http://riaschissl.blogspot.com
Re: [Dovecot] dovecot: Fatal: Time just moved backwards by 3909 seconds.
Charles Marcus wrote: On 11/30/2009, Udo Rader (list...@bestsolution.at) wrote: The virtual guest is Centos 5.4 based with dovecot 1.2.8 (at first we also tried with the original 1.0.7 (?) dovecot shipped with Centos). I wrote "alleged time shift" because there is no timeshift whatsoever, or at least I don't notice it anywhere else. ntp is - of course ;-) - up and running and no other applications have time troubles and I've even disabled the local clock as a time reference. Of course you know not to use ntp on VMs, only on the host, right? :) heh, ok, ship hit an sunk :-) I was absolutely not aware of a "clocksource" kernel parameter, what a weird thing ... > Revent kernels should be able to keep the VM time synced using kvmclock clocksource... So I'll give clocksource=acpi_pm a chance and see how it turns out ... Thanks for your hint! -- Udo Rader, CTO http://www.bestsolution.at http://riaschissl.blogspot.com
Re: [Dovecot] dovecot: Fatal: Time just moved backwards by 3909 seconds.
On 11/30/2009, Udo Rader (list...@bestsolution.at) wrote: > The virtual guest is Centos 5.4 based with dovecot 1.2.8 (at first we > also tried with the original 1.0.7 (?) dovecot shipped with Centos). > > I wrote "alleged time shift" because there is no timeshift > whatsoever, or at least I don't notice it anywhere else. > > ntp is - of course ;-) - up and running and no other applications > have time troubles and I've even disabled the local clock as a time > reference. Of course you know not to use ntp on VMs, only on the host, right? :) Revent kernels should be able to keep the VM time synced using kvmclock clocksource...
[Dovecot] dovecot: Fatal: Time just moved backwards by 3909 seconds.
Hi, after setting up a KVM based virtual guest on one of our virtualization servers, we see dovecot die on that virtual guest regularly because of an alleged time shift. The virtual guest is Centos 5.4 based with dovecot 1.2.8 (at first we also tried with the original 1.0.7 (?) dovecot shipped with Centos). I wrote "alleged time shift" because there is no timeshift whatsoever, or at least I don't notice it anywhere else. ntp is - of course ;-) - up and running and no other applications have time troubles and I've even disabled the local clock as a time reference. As a proof that the time did not shift see this log excerpt: --CUT--- Nov 29 14:02:22 athesia dovecot: IMAP(atester): Connection closed Nov 29 14:04:11 athesia dovecot: imap-login: Time just moved backwards by 4397 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki.dovecot.org/TimeMovedBackwards --CUT--- So as you see, dovecot successfully logged a message on 14:02 and then complained about the time having shifted 4397 seconds on 14:04 ... Thanks in advance -- Udo Rader, CTO http://www.bestsolution.at http://riaschissl.blogspot.com