• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

vmware tools setting clock back 100 seconds?

D

danswartz

2[H]4U
Joined
Feb 25, 2011
Messages
3,715
This is truly an odd one. I have a vm running ubuntu 10.10 - works fine. Except I noticed every time I reboot the VM, dovecot (IMAP server) complains the time has gone backward 100 seconds (it can be a second or two more - normal skew?) Anyway, after much init script debugging, I discovered the culprit is the vmware tools. If I disable them, everything is dandy. The moment I start them manually (via "start vmware-tools"), I see this in the syslog:

Oct 27 11:24:07 sphinx init: Connection from private client
Oct 27 11:24:07 sphinx init: vmware-tools goal changed from stop to start
Oct 27 11:24:07 sphinx init: vmware-tools state changed from waiting to starting
Oct 27 11:24:07 sphinx init: Handling starting event
Oct 27 11:24:07 sphinx init: vmware-tools state changed from starting to pre-start
Oct 27 11:24:07 sphinx init: vmware-tools pre-start process (1597)
Oct 27 11:24:07 sphinx kernel: [ 35.984085] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
Oct 27 11:24:07 sphinx init: Handling module-device-added event
Oct 27 11:24:07 sphinx init: Handling slots-device-added event
Oct 27 11:24:07 sphinx kernel: [ 35.984324] acpiphp: Slot [32] registered
(snip a bunch more acpi messages)
Oct 27 11:24:07 sphinx init: Handling slots-device-added event
Oct 27 11:24:07 sphinx init: last message repeated 30 times
Oct 27 11:24:07 sphinx init: vmware-tools pre-start process (1597) exited normally
Oct 27 11:24:07 sphinx init: vmware-tools state changed from pre-start to spawned
Oct 27 11:24:07 sphinx init: vmware-tools state changed from spawned to post-start
Oct 27 11:24:07 sphinx init: vmware-tools state changed from post-start to running
Oct 27 11:24:07 sphinx init: Handling started event
Oct 27 11:22:25 sphinx icinga: Warning: A system time change of 0d 0h 1m 42s (backwards in time) has been detected. Compensating...
Oct 27 11:22:25 sphinx dovecot: Fatal: Time just moved backwards by 102 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki.dovecot.org/TimeMovedBackwards

I found a KB article on the vmware site about how to totally disable time sync, so I made those config changes and retested the scenario and it's "fixed" now. I don't really care I guess, since I use ntp to keep the VMs in sync, but I'd dearly like to know what the root cause is... Also, when the system is up and ntpd starts, it detects this restores the correct time.
 
Probably an obvious question, but is the time on the host system set properly? All the time sync in the tools is supposed to do is make the guest clock the same as the host clock. If the host clock is off by 100 seconds, the guest will be too.
 
Well, that's odd. It never occurred to me to check that, since the host system is set up to use ntp. I just checked and sure enough:

Thu Oct 27 13:17:45 EDT 2011 (guest)
Thu Oct 27 17:16:01 UTC 2011 (host)

And so I just checked via the vsphere client, looking at the time config setting, and it shows ntp has the wrong date too. Digging more, apparently when I reconfigured the host awhile ago, I apparently neglected to set a default route, so ntp client was apparently unable to do anything useful (what fooled me was there is no obvious indication of a malfunction in the GUI.) I set the default route and now it's working. Facepalm. Thanks for the tip :)
 
I thought best practice is to use ntp for your VMs and hosts and not to use vmware tools to sync time...
 
danswartz: That's really awesome that you stuck to your guns and found the root cause!

I posted this recently so maybe you were referring to my post.

In case other people come across this thread. KB recommends to disable time sync on vms and rely on ntp for both host and vms. VM tools will still do one-time sync when guests are powered on to do the initial time sync.

Relevant KB: http://kb.vmware.com/selfservice/mic...rnalId=1006427
 
SpaceHonkey said:
I thought best practice is to use ntp for your VMs and hosts and not to use vmware tools to sync time...
Click to expand...

And I follow that best practice. Unfortunately, as the previous poster mentions, it will do so anyway when the tools start on power-up.
 
odd, if tools sync is disabled, it should not even then, from what i understand.
 
Honestly, I've just always used NTP and disabled vmwtools timesync - never had an issue so far...
 
You must log in or register to reply here.
Back
Top