Virtualisation does not replace Windows Time Service. It adds another layer that can influence the guest clock.

That distinction is important. A domain member may be correctly configured to follow Active Directory while Hyper-V Integration Services, VMware Tools, the QEMU Guest Agent or Xen guest tools also apply a correction from the host.

Start inside Windows

Before changing any hypervisor setting, record the Windows source, status and effective configuration:

w32tm /query /source
w32tm /query /status
w32tm /query /configuration

Check whether the source matches the intended role of the guest:

  • A domain member should normally use the Active Directory hierarchy.
  • A virtual domain controller should follow the normal domain hierarchy, with only the forest root PDC Emulator using the approved upstream source.
  • A standalone guest should normally use deliberate manual NTP peers.

If the Windows source is already wrong, correct that first. If the source is correct but the clock later changes again, investigate host-to-guest synchronisation.

The clock changes after startup

A virtual machine can inherit time from the host when it starts. Some guest integration services also perform a one-off correction during startup.

If the guest begins with the wrong date or time and then corrects itself shortly afterwards, check:

  • The clock on the hypervisor host.
  • The guest-tools startup synchronisation setting.
  • The Windows Time source after the machine has fully started.
  • Whether the VM was created from an old template or image.

A guest that starts with a badly incorrect clock can encounter certificate, activation, authentication or application problems before Windows Time Service completes its first correction.

The clock is correct after resync but wrong again later

This is one of the most useful diagnostic clues.

If:

w32tm /resync

corrects the clock, but the time later jumps back or moves again, Windows Time Service has demonstrated that it can reach and use a source. Another component is probably applying a later correction.

Typical causes include:

  • Hyper-V Time Synchronization.
  • VMware Tools periodic synchronisation.
  • A guest-agent correction after a lifecycle event.
  • A host clock that differs from the domain hierarchy.
  • A scheduled task or management tool changing the system clock.

Review the relevant platform settings rather than repeatedly running w32tm /resync.

The host clock is wrong

Do not assume that disabling ongoing host-to-guest synchronisation makes host time irrelevant.

The host clock can still affect:

  • The initial virtual RTC presented at startup.
  • Resume from suspension or saved state.
  • Migration between hosts.
  • Snapshot or checkpoint restoration.
  • Guest-agent time-setting operations.

Check the current host and every other host to which the VM can migrate. A cluster is only as consistent as its least accurate node.

Live migration and vMotion

A live migration should not normally produce a visible clock jump. If it does, compare the source and destination host clocks.

Also check whether the migration triggered a one-off guest-tools correction. Some platforms deliberately adjust the guest after migration to account for a pause or timing discontinuity.

After a migration during troubleshooting, run:

w32tm /query /source
w32tm /query /status

The guest should return to its intended Windows source once the migration has completed.

Suspend and resume

A suspended virtual machine stops executing while real time continues. When it resumes, the guest clock may initially reflect the time at which it was suspended.

Guest tools usually correct this difference, but the correction can expose a badly configured host or a conflict between the host and Windows Time Service.

After a long suspension:

w32tm /resync /rediscover

Then verify the source and status rather than relying only on the displayed clock.

Snapshots and checkpoints

Restoring a snapshot or checkpoint returns the guest operating system to an earlier state, including an earlier system time.

Applications may encounter:

  • Kerberos failures.
  • Certificate validation errors.
  • Incorrect scheduled-task behaviour.
  • Confusing event-log sequences.
  • Activation or evaluation-period problems.

After restoring a snapshot, verify the clock, source and last successful synchronisation before returning the VM to service.

Domain controllers require additional care. A domain controller snapshot affects Active Directory state as well as time. Use supported backup and recovery procedures and review Virtual Domain Controllers and Windows Time.

Domain members

For domain-joined Windows guests, the preferred approach used throughout this site is:

  • Windows Time Service follows the Active Directory hierarchy.
  • Ongoing host-to-guest time synchronisation is disabled where the platform supports that distinction.
  • The hypervisor hosts themselves remain accurately synchronised.
  • One-off correction after startup, migration or resume is considered separately.

The aim is not to remove guest tools. It is to avoid two different components managing the same clock continuously.

Standalone virtual machines

A standalone guest has no Active Directory hierarchy. It should normally use a deliberate manual NTP configuration:

w32tm /config /manualpeerlist:"0.uk.pool.ntp.org,0x8 1.uk.pool.ntp.org,0x8" /syncfromflags:manual /update

Relying entirely on host time may be acceptable by design, but the source then changes with the VM's placement. Every possible host becomes part of the guest's time infrastructure.

Virtual domain controllers

Virtual domain controllers should follow the same Active Directory hierarchy as physical domain controllers.

The forest root PDC Emulator uses the approved upstream source. Other domain controllers follow the domain hierarchy. The hypervisor should not become an alternative ongoing source.

If a virtual domain controller is wrong, work from the top of the hierarchy before changing guest-tool settings:

netdom query fsmo
w32tm /monitor
w32tm /query /source
w32tm /query /status

Hyper-V

Hyper-V exposes a Time Synchronization integration service. Inside Windows this is associated with the vmictimesync service and may appear as:

VM IC Time Synchronization Provider

For a domain member where Active Directory should be authoritative, review whether ongoing Hyper-V synchronisation is enabled.

See Windows Time on Hyper-V.

VMware

VMware distinguishes between periodic synchronisation and one-off corrections associated with startup, migration, resume and snapshot operations.

Disabling periodic synchronisation does not necessarily disable every one-off correction. Review both settings if the guest clock still changes unexpectedly.

See Windows Time on VMware.

Proxmox VE

Proxmox VE uses QEMU/KVM and the QEMU Guest Agent. The guest agent can set the guest clock after events such as pause or migration, but it is not a replacement for normal Windows Time Service synchronisation.

See Windows Time on Proxmox VE.

XCP-ng and XenServer

Xen guest tools can participate in correcting time after resume or migration. The Windows guest should still retain its intended Windows source.

See Windows Time on XCP-ng and XenServer.

Old templates and cloned machines

A VM built from an old template may contain:

  • An obsolete manual peer list.
  • A disabled Windows Time service.
  • Old guest tools.
  • A stale Group Policy result.
  • A clock that was wrong when the template was captured.

After deployment, verify the effective Windows Time configuration rather than assuming the template remains suitable.

Time zones are not time synchronisation

A VM can display the wrong local time while its underlying UTC clock is correct.

Check the configured time zone separately:

tzutil /g

A time-zone error affects the displayed local time. An NTP or Windows Time error affects the system clock itself. Correct the appropriate layer rather than changing both.

Check the event logs

Review:

  • Windows Logs > System, filtered for Microsoft-Windows-Time-Service.
  • Hyper-V integration-service events where applicable.
  • VMware Tools logs and Windows events showing vmtoolsd.exe changing time.
  • Guest-agent and hypervisor task logs around migration, resume or restore.

The timing of the event is important. Match the clock change with a host operation, backup, migration or guest-tools action.

A lesson from an Exchange deployment

During the build of an Exchange 2007 environment many years ago, newly created Exchange servers appeared to have their evaluation periods expire immediately after joining the domain.

The problem was not Exchange. The VMware hosts had not been configured with a reliable time source and their clocks were badly wrong. New virtual machines inherited that time. Joining the domain corrected the Windows clock, but the evaluation period had already been calculated from the incorrect date.

Correcting the host time configuration resolved the problem for subsequent builds.

The lesson remains useful: an application failure inside a VM can originate from the virtualisation layer beneath it.

A practical troubleshooting sequence

  1. Record the Windows source, status and configuration.
  2. Confirm the intended source for the guest's role.
  3. Check the current hypervisor host clock.
  4. Check every possible migration target.
  5. Review ongoing and one-off guest time settings separately.
  6. Check whether the VM recently started, resumed, migrated or was restored.
  7. Make one change and observe whether the clock remains stable.
  8. Verify the original authentication or application problem afterwards.

Related information