Proxmox VE does not provide a VMware Tools or Hyper-V Integration Services setting that continuously synchronises every Windows guest clock with the host. The underlying QEMU/KVM platform provides the virtual clock seen by the guest, while the optional QEMU Guest Agent allows the host to perform selected operations inside the virtual machine.

One of those guest-agent operations can set the guest system time. It is intended mainly for situations where a virtual machine has been paused, suspended or restored and its clock is now significantly behind the current time.

QEMU, KVM and Proxmox VE

Proxmox VE is the management platform, QEMU provides the virtual machine process and device model, and KVM provides hardware-assisted virtualisation through the Linux kernel.

This is why the documentation for Windows time behaviour is spread across several projects. Proxmox documents the platform and guest-agent configuration, QEMU documents the guest-agent commands, and the Linux kernel documents the KVM clock used by the virtual machine.

For a Windows administrator, the practical point is simpler: Windows should still have one clear ongoing time source, while every Proxmox node must also maintain accurate time.

Domain members

A domain-joined Windows guest on Proxmox VE should normally behave like any other domain member. Windows Time Service should use the Active Directory hierarchy and report a domain controller as its source.

w32tm /query /source
w32tm /query /status

The QEMU Guest Agent can remain installed for shutdown, filesystem freeze, IP address reporting and other management functions. Installing the agent does not mean that it should replace Windows Time Service as the normal clock source.

If a guest clock changes unexpectedly, check Windows Time Service first, then review whether a Proxmox operation or guest-agent command has set the guest time.

Domain controllers

Virtual domain controllers should follow the normal Active Directory time hierarchy. The forest root PDC Emulator should use its approved external peers, while the remaining domain controllers should use domain hierarchy synchronisation.

Do not configure a domain controller to use the Proxmox node as its regular NTP source simply because it is virtual. That introduces the hypervisor into the Active Directory hierarchy and makes the domain dependent on the host configuration.

The QEMU Guest Agent may still be useful for management and recovery operations, but any time correction should be treated as an exceptional action rather than the normal synchronisation method.

Standalone Windows guests

A standalone Windows guest can use a manually configured peer list in the same way as a physical standalone server.

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

This keeps the source visible and verifiable from within Windows. It also means the guest retains the same design if it is migrated between Proxmox nodes.

The QEMU Guest Agent

The QEMU Guest Agent runs inside the Windows guest and communicates with the host through a virtual serial channel. Proxmox VE recommends installing it because it improves communication between the platform and the guest.

The agent supports a guest-set-time command. QEMU documents this as a way to correct a guest after it has been paused or migrated from a saved state, where the guest operating system may not know that a large amount of real time has passed.

This is different from a continuously running NTP client. The command sets the guest system time and hardware clock; Windows Time Service should then continue normal synchronisation from its configured source.

Install and enable the QEMU Guest Agent

For Windows guests, install the QEMU Guest Agent from the current VirtIO driver media, then enable it for the virtual machine in Proxmox VE.

In the Proxmox web interface:

  1. Select the virtual machine.
  2. Open Options.
  3. Edit QEMU Guest Agent.
  4. Enable the agent.
  5. Restart the virtual machine or the guest-agent service if required.

The agent should be installed for its wider management benefits, not specifically as a replacement for Windows Time Service.

Proxmox node time

Every Proxmox node must use a reliable time source. This is particularly important in a cluster, where nodes migrate guests and share configuration and storage responsibilities.

The nodes should use the same deliberate time design rather than unrelated defaults. This may be a local Chrony server, an organisational NTP name or several approved external peers.

Accurate node time matters even when Windows guests use their own NTP sources because:

  • The virtual RTC is derived from the host.
  • KVM clock handling depends on the host clock and timestamp counter.
  • Live migration depends on compatible and synchronised source and destination nodes.
  • Guest-agent time correction uses a time supplied through the host.

Migration between nodes

KVM includes mechanisms to preserve a monotonic guest clock during migration. The Linux kernel documentation also notes that migration can cause problems if the source and destination hosts do not have synchronised real-time clocks.

Therefore, every node that may run the VM must use the same reliable time design. Checking only the current host is not sufficient in a cluster.

After a migration performed during troubleshooting, verify the Windows source and last successful synchronisation:

w32tm /query /source
w32tm /query /status

Snapshots, backup and resume

A guest restored from an older snapshot or resumed after being paused may start with a clock that is behind the current time.

The QEMU Guest Agent time-setting capability exists to help with this situation, but Windows Time Service should still be checked afterwards. A large correction can affect authentication, certificates, scheduled tasks and application behaviour.

w32tm /resync /rediscover

Do not assume that a successful restore also proves that the guest time configuration is healthy.

Windows clock source

Windows guests on modern QEMU/KVM normally use the KVM paravirtual clock as their underlying clocksource. This provides the operating system with a stable virtual time counter, but it is not the same thing as selecting an NTP source.

w32tm /query /source reports the Windows Time Service source. It will not normally display KVM clock or Proxmox, because those describe the underlying virtual clock rather than the network source used to discipline it.

Common mistakes

  • Assuming the QEMU Guest Agent replaces Windows Time Service.
  • Pointing virtual domain controllers directly at Proxmox nodes.
  • Installing the guest agent but not enabling it in the VM options.
  • Allowing different cluster nodes to use unrelated or incorrect time sources.
  • Restoring a snapshot without checking the Windows clock afterwards.
  • Confusing the KVM paravirtual clock with the Windows NTP source.
  • Checking only the current Proxmox node in a cluster capable of migrating the guest.

Proxmox, QEMU and KVM documentation

Related information