VMware Tools: Time sync not working

[WhiteKnight]

Summer time has ended last week. This brought me to the observation that VMware Tools time sync feature doesn't work:

---

Host time:                       Guest time:

---

Guest setting:

[vcallaway]

Is VMtools installed and up to date in the guest OS?

[WhiteKnight]

Absolutely.

I set up this VM completely fresh after I bought Workstation 15. Including VMware Tools.

[bonnie201110141]

Does it work after you power off your VM and start it again? And is your guest in the same timezone as your host?

[WhiteKnight]

No, restarting doesn't solve the problem. I created a number of clones and they all share the same issue.

Yes, they are all (by default) in the same timezone as my host. When I set a guest to use a time server (Windows Control Panel > Date and Time), time is set correctly by Windows 10.

[bonnie201110141]

Can you please do the following to enable logs?

1. Set VM Settings > Options > Advanced > Gathering debugging information to Full.

2. Add below lines in C:\ProgramData\VMware\VMware Tools\tools.conf in guest, and then restart guest OS?

  [logging]

  log = true

  timeSync.level = debug

  timeSync.handler = vmx

3. Reproduce the issue

Send us the vmware.log. Thanks a lot!

[WhiteKnight]

Hi Bonnie,

thanks for trying to help!

I created the tools.conf file in the guest at the location you suggested (the file didn't exist there yet) and added the proposed content to that file. Then I set the VM's logging extent to full. Finally I ran the VM.

I just sent you a PM with the log's content as I'm concerned the log may contain sensitive data.

Best regards,

Axel

[vithampi]

Hello,

I was able to take a look at the logs you have provided. I do see the timeSync service being activated. Unfortunately, it looks like you only ran it for a couple of minutes. Would it be possible for you to reproduce the problem with the debug logs enabled?

Generally speaking, time synchronization is only applied to system time which should be on the UTC time scale, and time zone / day light savings are managed by the OS as offsets. So during a switch over, Windows just changes the offset and VMware tools timeSync is not involved. Can you also provide the output of the following command?

  w32tm /tz

Thanks.

[WhiteKnight]

I just did. Here's the output:

Host:

C:\Users\Me>w32tm /tz
Zeitzone: Aktuell:TIME_ZONE_ID_STANDARD Bias: -60 Min. (UTC=Ortszeit+Bias)
  [Standardname:"Mitteleuropäische Zeit" Bias:0 Min. Datum:(M:10 T:5 DoW:0)]
  [Sommerzeitname:"Mitteleuropäische Sommerzeit" Bias:-60 Min. Datum:(M:3 T:5 DoW:0)]

C:\Users\Me>time
Aktuelle Zeit: 13:09:57,65
Geben Sie die neue Zeit ein:
C:\Users\Me>

.

Guest:

C:\Users\Me>w32tm /tz
Zeitzone: Aktuell:TIME_ZONE_ID_STANDARD Bias: -60 Min. (UTC=Ortszeit+Bias)
  [Standardname:"Mitteleuropäische Zeit" Bias:0 Min. Datum:(M:10 T:5 DoW:0)]
  [Sommerzeitname:"Mitteleuropäische Sommerzeit" Bias:-60 Min. Datum:(M:3 T:5 DoW:0)]

C:\Users\Me>time
Aktuelle Zeit: 14:09:44,24
Geben Sie die neue Zeit ein:
C:\Users\Me>

Here's a screenshot I took, showing both times (please note that I always hide the VMware Tools icon in the guest because the icon doesn't serve a purpose):

I will run the guest for another few minutes and send you the logs via PM right away.

Thanks for all your efforts!

[vithampi]

Thanks for the screenshots and the logs. According to the host, UTC time is 13:09 - 60 mins = 12:09. According to the guest, UTC time is 14:09 - 60 mins = 13:09. Obviously, the VM is wrong. Something, and I'm not sure what that could be, seems to have set the guest's system time ahead by 60 minutes.

VMware tools does not step correct time backwards if it notices that the guest is ahead of the host, unless it's during startup or when time sync is enabled from the UI. Think of it as as a one-time courtesy before starting the service after which time can only be stepped forward or slew corrected (i.e., fixed in small increments over a long period of time).

Looking at the logs you have provided, tools time sync is detecting that the guest is ahead, and trying to fix it by slewing it:

2018-11-05T13:09:27.118+01:00| vcpu-1| I125: Guest: [   debug] [vmsvc:timeSync] Periodic synchronization: slewing time.

2018-11-05T13:09:27.118+01:00| vcpu-1| I125: Guest: [   debug] [vmsvc:timeSync] Slewing time: adjustment -3600479500

...

018-11-05T13:10:27.114+01:00| vcpu-1| I125: Guest: [   debug] [vmsvc:timeSync] Periodic synchronization: slewing time.

2018-11-05T13:10:27.114+01:00| vcpu-1| I125: Guest: [   debug] [vmsvc:timeSync] Slewing time: adjustment -3594479000

...

The adjustment value is in microseconds, and as you can see, the adjustment value reduces each sync period (which is every 60s). And you can imagine this is going to take a long time.

One thing that I am not able explain is why tools did not perform a one-time backward correction. For some reason it determined that it did not need to do that. I'll have to reproduce this internally to answer that.

Meanwhile, would you be able to look into what might have caused system time to be set exactly 1 hour ahead in your VM?

Thanks for your patience and for providing all the additional logs and info.

[WhiteKnight]

Thanks for all your efforts.

All I did was: I created and set-up this VM on the 10^th of October 2018. Then, a few days later, Summer Time ended, and the guest's clock kept the Summer Time value.

Just out of curiosity: Why doesn't VMware Tools sync the guest's CMOS time at VM boot time (i.e. always set the guest's CMOS clock to the host's CMOS clock value when the VM starts) when "synchronize guest time with host" option is checked?

[vithampi]

> Just out of curiosity: Why doesn't VMware Tools sync the guest's CMOS time at VM boot time (i.e. always set the guest's CMOS clock to the host's CMOS clock value when the VM starts) when "synchronize guest time with host" option is checked?

Typically, that's what the OS itself does, and the virtual CMOS should provide host date-time guest. So the VM should have gotten the correct values. We are looking into this and I'll back to you as soon as I have new information.

[NathanosBlightc]

First of all check the timezone of windows guest OS

Then try w32tm /query /status to check guest OS time configuration, especially NTP settings. (if you joined your VM to domain, it must retrieve time settings from DCs, so you may need your PDC time)

Next find these lines in VMX config file of your VM: " tools.syncTime, tools.syncTime.Period "

some third-party NTP tools may be useful

[vithampi]

I hope you were able to remedy the situation for yourself. I tried reproducing this in-house, but haven't succeeded so far.  From your screenshots, it's clear that both host and guest have the correct time zone information. -60s bias for central european time and -60s for day light savings. And summer time ended, which means that the active bias should be just -60s. But for some reason, windows seems to have booted up with localtime with day light savings, and then assumed active bias without it. It could be a bug in windows day savings adjustments. But I have simply not been able to reproduce this.

Please let me know if you encounter this again. This time I have a few more ideas about what additional information we can collect.

[WhiteKnight]

Thanks so much, Vit, for all your efforts.

At the moment, the clocks seem to be in sync again. Perhaps it was a Windows issue, indeed, an Microsoft has fixed it in the meanwhile.

When I see clocks diverge again, I'll get back here. And I'd be very delighted to get your assistance.

[WhiteKnight]

After Summer Time ended and standard time has been set last week, I still have the same issue with time sync:

My VMs all still show summer time while my host shows winter time.

Shouldn't VMware Tools be amended in order to initialize a VM during POST with the correct time stamp when time sync is enabled?

[scott28tt]

I thought all VMs were "given" the host time when they powered on, regardless of whether VMware Tools is installed or not - POST/BIOS/UEFI are not specific to a driver in the guest OS of a VM.

[WhiteKnight]

Frankly, I don't know, either.

From what I learned in this thread, VMware Tools seems to slowly advance the clock when the guest is behind the host. But apparently, this isn't true the other way around:

Just to make sure: To be able to reproduce this issue, it's important to know that network time server sync is disabled in the guest, of course (see my first message where I reported this issue). It wouldn't make sense to enable the Sync Guest Time With Host option if that option would be enabled.

[datalifenyc]

This issue was causing serious issues for me, including affecting drive sync, such as OneDrive. To solve the problem, I leave the Synchronize guest time with host unchecked and set Windows Set time automatically and Set time zone automatically to On. At least for now, this has resolved the issue.

Edit 1:

The method I suggested did not resolve the issue long term. I tried multiple combinations of letting VMware and/or Windows control date and time. Unfortunately, none of these options has resolved the issue.

Edit 2 [2021-04-28]:

1. Disable all time sync features in Windows Guest OS.
2. In Terminal (Command Prompt), `cd "C:\Program Files\VMware\VMware Tools"` directory.
3. Enter the command: `VMwareToolboxCmd timesync enable`. Hopefully, this will be an effective long-term solution.

References:

Time Synchronization in Guests Deployed from OVF Templates (1014038) 

VMware Tools Configuration Utility User's Guide 

[sumit-Bhuvi]

Hi, Try this one.. open cmd run as administrator and execute this command w32tm /resync /force. Mine problem solve with this one.