Windows Time on VMware

VMware Tools supports two distinct forms of guest time correction: periodic synchronisation and one-off synchronisation during particular virtual machine events.

This distinction matters because disabling the visible periodic setting does not necessarily prevent VMware Tools from correcting the guest clock after startup, vMotion, snapshot operations or resume.

Periodic and one-off synchronisation

Periodic synchronisation causes VMware Tools to compare the guest clock with the ESXi host and correct it while the virtual machine is running.

One-off synchronisation is associated with events that may leave the guest clock incorrect, including:

Starting or restarting VMware Tools.
Resuming a suspended virtual machine.
Completing a vMotion operation.
Taking, restoring or consolidating a snapshot.
Resuming from a saved or suspended state.

Current vSphere versions expose separate controls for periodic synchronisation and synchronisation at startup and resume. Older versions and older articles may describe advanced virtual machine parameters instead.

Domain members

A domain-joined Windows guest should normally obtain time through the Active Directory hierarchy in the same way as a physical domain member.

If VMware Tools is also performing periodic corrections, the guest has two mechanisms controlling its clock. These sources may agree for years, but a badly configured ESXi host or a failed host NTP service can result in VMware Tools overriding otherwise correct domain time.

Disable periodic VMware Tools synchronisation and confirm that Windows reports a domain controller as its source:

w32tm /query /source
w32tm /query /status

On recent VMware Tools releases, the periodic status can also be checked from an elevated command prompt:

"C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe" timesync status

Disable periodic synchronisation from within the guest with:

"C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe" timesync disable

The exact command path can vary with the VMware Tools version. The vSphere Client setting remains the clearest place to record the intended behaviour with the virtual machine.

Domain controllers

Virtual domain controllers should follow the Windows time hierarchy. The forest root PDC Emulator should use its approved external source, while the remaining domain controllers should use domain hierarchy synchronisation.

Periodic VMware Tools time synchronisation should therefore be disabled on virtual domain controllers.

One-off correction requires more judgement. VMware recommends retaining one-off synchronisation for events that can leave a guest clock badly wrong, while Windows administrators may choose to disable all host corrections on domain controllers to preserve a single authoritative path.

Whichever approach is selected, it must be applied deliberately and supported by accurate time on every ESXi host. A domain controller moved to a host with an incorrect clock can otherwise inherit that error during a lifecycle event.

Standalone Windows guests

A standalone guest can use Windows Time Service with manual NTP peers or use the ESXi host as its primary source.

Using Windows Time Service generally makes the source easier to verify from within the guest and avoids the result changing when the VM moves between hosts. It also keeps the configuration consistent with physical Windows servers.

If VMware Tools periodic synchronisation is used instead, every possible ESXi host becomes part of the guest's time infrastructure and must use the same reliable upstream design.

Disable periodic synchronisation in vSphere Client

In current vSphere Client versions:

Select the virtual machine.
Choose Edit Settings.
Open the VM Options tab.
Expand VMware Tools.
Expand the time or Synchronize Time with Host settings.
Clear Synchronize time periodically or the equivalent periodic synchronisation option.
Leave or clear Synchronize at startup and resume according to the selected one-off correction policy.

The wording varies between vSphere releases, so confirm whether the displayed control applies to periodic corrections, one-off lifecycle corrections or both.

Disabling every VMware Tools correction

Clearing only the periodic option does not disable one-off corrections. If the requirement is that VMware Tools must never adjust the guest clock, the startup and resume setting must also be disabled.

Broadcom documents advanced virtual machine settings used to disable individual one-off correction events:

time.synchronize.continue = "FALSE"
time.synchronize.restore = "FALSE"
time.synchronize.resume.disk = "FALSE"
time.synchronize.shrink = "FALSE"
time.synchronize.tools.startup = "FALSE"
time.synchronize.tools.enable = "FALSE"
time.synchronize.resume.host = "FALSE"

These settings should not be added routinely. They are appropriate only where the design explicitly requires all host-to-guest corrections to be disabled and the consequences during resume, snapshot restoration and migration are understood.

Changes may require VMware Tools or the virtual machine to be restarted before they take effect.

The ESXi hosts must be correct

Disabling VMware Tools time synchronisation does not make ESXi host time unimportant.

The virtual RTC used when a guest starts is derived from the host. One-off corrections also use host time. A VM migrated to an ESXi host with an incorrect clock can therefore be affected even where periodic synchronisation is disabled.

Configure every ESXi host with reliable NTP sources and verify that the host time service is running. The hosts should follow the same time design rather than each using unrelated or undocumented sources.

A lesson from an Exchange deployment

During the build of an Exchange 2007 environment many years ago, every newly created Exchange server appeared to have its evaluation period expire immediately after joining the Active Directory domain.

The problem was not Exchange. The VMware hosts had been built without a working time configuration and their clocks were badly wrong. Each new virtual machine inherited the host time. Joining the domain corrected the Windows clock, but the evaluation period had already been calculated using the incorrect date.

The solution was to configure the VMware hosts with reliable time sources before rebuilding the virtual machines.

This is why host time should be part of the standard virtualisation build even where guest time synchronisation is normally disabled.

Snapshots, vMotion and consolidation

VMware lifecycle operations can pause or move a virtual machine. Snapshot consolidation can also stun the guest for a period, leaving the guest clock behind when execution resumes.

VMware Tools one-off synchronisation is intended to correct these events. If all host corrections have been disabled, Windows Time Service must be available and capable of correcting the resulting skew.

After restoring a snapshot, resuming a suspended VM or completing a migration during troubleshooting, check:

w32tm /query /source
w32tm /query /status
w32tm /resync /rediscover

Do not rely on the status command alone

The VMware Tools command reporting that time synchronisation is disabled refers to periodic synchronisation. Windows event logs may still show vmtoolsd.exe changing the clock because one-off synchronisation remains enabled.

If unexpected corrections continue, review both settings in vSphere Client rather than assuming the status output represents every form of VMware time synchronisation.

Common mistakes

Disabling VMware Tools periodic synchronisation without confirming that Windows Time Service works.
Assuming that the periodic status also covers one-off corrections.
Disabling every host correction without considering snapshot, resume and vMotion events.
Leaving ESXi host NTP stopped or misconfigured.
Allowing virtual domain controllers to use both periodic host time and the Active Directory hierarchy.
Moving a guest between hosts whose clocks are not consistent.
Checking the configured peer list but not the source selected by Windows.