Fix VM Clock Drift: Disable Host Sync, Use NTP

Quick answer for the impatient

Disable time sync between host and guest in VMware Tools, then set up NTP on the guest OS directly. On vSphere, edit the VM's .vmx file or use PowerShell: Set-VM -VMName "YourVM" -TimeSyncOff $true. Then configure NTP on the guest.

Had a client last month whose entire print queue died because of this. Their VM clock was 14 minutes behind the domain controller (also a VM). Everything stopped working — file timestamps, log entries, Kerberos auth. The fix took 5 minutes after I figured out the root cause.

Why this happens

VMware Tools has a built-in time sync feature that grabs time from the ESXi host. The host itself might be syncing from somewhere (or not). Meanwhile, your guest OS — Linux or Windows — probably runs its own NTP or w32time service. They fight each other. The Tools sync is aggressive and can override NTP adjustments, especially when the guest is paused, snapshotted, or vMotioned. Result: your VM clock drifts, jumps back, and never stabilizes. Common triggers: live migration (vMotion), snapshot revert, or just running mixed environments where the host and guest have different sync sources.

Fix steps (the one that works)

Stop the time sync war. On the VM, disable VMware Tools periodic time sync. For Linux: edit /etc/vmware-tools/tools.conf and add:
```
[guestinfo]
vmtoolsd.enableSyncTime = false
```
For Windows: run PowerShell as admin:
```
Remove-VMGuestTimeSync -VMName "YourVM"
```
Or through vSphere Web Client: go to VM settings > VM Options > VMware Tools > tick "Synchronize guest time with host" — uncheck it.

Set up NTP on the guest. Don't rely on the host. Use a reliable upstream. For Linux (RHEL/CentOS):

yum install chrony -y
systemctl enable chronyd --now

Then edit /etc/chrony.conf and replace pool lines with

pool 0.pool.ntp.org iburst
pool 1.pool.ntp.org iburst

For Ubuntu/Debian:

apt install chrony -y
systemctl enable chrony --now

For Windows Server: open Command Prompt as admin

w32tm /config /manualpeerlist:"0.pool.ntp.org,1.pool.ntp.org" /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time

Force a quick sync. On Linux: chronyc -a makestep. On Windows: w32tm /resync. Check your clock with date or timedatectl.
Verify it sticks. Wait 10 minutes. Check again. If the clock stayed in sync, you're done. If it drifts again, check that no other service (like Hyper-V integration services if it's a nested VM) is also syncing time.

Alternative fixes if the main one fails

If NTP won't work (e.g., the VM is isolated from the internet), you can still use host sync but do it right. Set the host's NTP to a reliable source, then re-enable VMware Tools time sync. But I've seen hosts drift even with NTP — a bad upstream pool or misconfigured firewall. Better to use a local NTP server if you have one.

If you're stuck with host sync only, at least make sure the guest doesn't run its own NTP. On Linux: systemctl stop chronyd && systemctl disable chronyd. On Windows: sc stop w32time && sc config w32time start=disabled. This is a dirty workaround, but it stops the conflict.

Another trick: if you can't modify the .vmx file, use the vSphere API to change time sync per VM. But honestly, the direct config edit is cleaner.

Prevention tip

Don't let VMware Tools and the guest OS fight over time. Decide who's boss: either let the host sync time (and disable NTP in the guest), or let the guest sync via NTP (and disable Tools time sync). The second option is better because NTP is smarter — it handles drift gradually, not in jumps. For production VMs, always disable VMware Tools time sync and use NTP or w32time. Also, schedule regular checks: a simple cron job that runs chronyc tracking and emails if offset exceeds 1 second.

Real world: had a customer running Exchange on a VM. Clock drifted 5 minutes over 3 months. Mail flow broke because Kerberos tickets expired. One PowerShell command and a chrony config saved their day. Don't skip this.