On a physical computer, Windows Time Service normally has one clear job: select a suitable source and keep the local clock synchronised. A virtual machine introduces another layer because the hypervisor can also influence the guest clock.
Most virtualisation platforms include a guest integration component capable of correcting time. Depending on the platform and configuration, this may happen continuously, periodically, or during events such as startup, resume and snapshot restoration.
The problem is not that hypervisor time synchronisation is inherently wrong. The problem is allowing two separate mechanisms to manage the same clock without understanding which one should take precedence.
Domain members
A domain-joined Windows virtual machine should normally use the Active Directory time hierarchy in the same way as a physical domain member.
Where the virtualisation platform is also correcting the guest clock, the machine may effectively have two time sources: the domain hierarchy and the host. If they differ, the guest can be pulled in two directions and the resulting behaviour can be difficult to diagnose.
A common approach is therefore to disable ongoing host time synchronisation on domain members and allow Windows Time Service to use the domain hierarchy exclusively.
This does not necessarily disable every form of time correction. Some platforms distinguish between continuous synchronisation and one-off correction during startup, resume or snapshot operations. The platform-specific articles explain those differences.
Domain controllers
Virtual domain controllers require particular care because they participate directly in the Active Directory time hierarchy.
The forest root PDC Emulator should obtain time from its approved external source. Other domain controllers should follow the domain hierarchy. Hypervisor time synchronisation should not be allowed to undermine that design.
Before changing any integration setting, confirm how the hypervisor handles startup, resume and snapshot recovery. The objective is to preserve the Windows hierarchy while avoiding a badly incorrect guest clock during exceptional events.
Standalone virtual machines
A standalone Windows virtual machine has no domain hierarchy to follow. It can use a manually configured NTP source, the hypervisor, or a deliberately designed combination of the two.
For most standalone servers, using Windows Time Service with reliable NTP peers provides a clear and supportable configuration. Host time synchronisation may still be useful during startup or recovery, but the design should avoid continuous competition between the host and guest.
The host must also be correct
Disabling host-to-guest time synchronisation does not make the host clock irrelevant.
A virtual machine may inherit the host time when it is first created or started. If the host clock is badly wrong, the guest can begin life with the same error before Windows Time Service has had an opportunity to correct it.
During the build of an Exchange 2007 environment many years ago, newly created virtual machines appeared to have their evaluation period expire immediately after joining the Active Directory domain.
The fault was not Exchange. The VMware hosts had not been configured with a reliable time source and their clocks were significantly wrong. The new virtual machines inherited that time. When they joined the domain, Windows corrected the guest clock, but the evaluation period had already been calculated using the earlier date.
Correcting the time configuration on the VMware hosts resolved the problem for subsequent builds. It remains a useful reminder that the hypervisor itself must be included in the time design even where ongoing guest synchronisation is disabled.
Snapshots, suspend and resume
Snapshots and suspended virtual machines create additional complications because the guest clock may resume from an earlier point in time.
Most platforms include mechanisms to correct the clock after these events. Those mechanisms may remain active even when regular time synchronisation is disabled.
After restoring a snapshot or resuming a long-suspended Windows guest, verify the clock, the selected Windows Time source and the last successful synchronisation before relying on the system.
Do not assume every platform behaves the same way
Hyper-V, VMware, Proxmox VE and XCP-ng all provide guest integration tools, but the controls and default behaviour are not identical.
A setting labelled time synchronisation on one platform may control ongoing corrections, while another platform may separate startup correction from periodic synchronisation. Instructions should therefore be applied to the relevant hypervisor rather than copied between platforms.
Topics in this section
Hyper-V
Understand Hyper-V Integration Services time synchronisation and how it should interact with Windows Time Service.
VMware
Review VMware Tools time synchronisation, startup behaviour and the correct configuration for Windows guests.
Proxmox VE
Understand host time, QEMU guest behaviour and Windows time configuration on Proxmox VE.
XCP-ng and Citrix Hypervisor
Review Xen guest tools, host time and Windows Time Service on XCP-ng and Citrix Hypervisor.
Virtual Domain Controllers
Protect the Active Directory hierarchy when domain controllers run as virtual machines.
Common Virtualisation Time Mistakes
Avoid competing time sources, incorrect host clocks and problems caused by snapshots or suspended guests.