Huge Time Drift in VMWare Windows 7 guest

Question

I'm running a Windows 7 guest in VMWare and it is losing as much as 5 seconds per minute. I resynched the time through Windows about 25 minutes ago and it has lost 00:01:20 so far. It is obviously inconsistant as I frequently find the clock to be roughly 2 minutes out of synch with the other computers. A Redhat guest on the same VM stays lock step with other computers that use the same domain time server. I've looked around and found people recommending both using the VMWare synch tool and others suggesting using the guest Windows synch tool. Drift this large seems rediculous and is causing issues with software running on various machines.

What I'm asking is, does anyone know what could be causing this and what I might do to mitigate it? I have a suspicion that VMWare is slewing the clock somehow, but the fact that a different guest OS isn't experiencing it makes me doubt that suspicion.

Thanks.

Answer 1

Why does it happen?

I think it happens because the properties of the host physical hardware cannot be manifested fully and accurately in the virtual hardware while still providing virtualization on the x86 platform (on which efficient virtualization was thought impossible for many years), especially to provide high performance with low overhead. More specifically, one factor supposedly is variation of clock speeds and power management between the physical and logical CPU's. I think maybe the CPU clock speed of the physical CPU varies but the logical CPU VMware presents does not show that. IIRC the TSC (Time Stamp Counter) register gets messed up, and this confuses Windows especially.

VMware, in their usual thorough engineering, has a 31 page comprehensive article on how VM timekeeping works and what the problems are it can run into: http://www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf. Windows timekeeping is dealt with on page 14

See also: http://pelican.rsvs.ulaval.ca/mediawiki/index.php/VMWare_tips_and_tricks#Power_saving_.28SpeedStep.2C_C-states.2C_P-States.2C....29

Why is it so bad for this VM on this hardware? I have no idea; I wish I could help you there. Do you have other Windows VM's on the same machine? How do they fare?

How to fix it:

If you have accurate host time, then I'm pretty sure an adequate solution is to have VMware Tools time sync every 60 seconds. (If you don't have accurate host time, see the end of this section for how to get that set up.)

Place this in the VM's .vmx file:

tools.syncTime = true
tools.syncTime.period = 60   #Every 60 seconds is supposed to be the default, but this forces it to 60 second just in case.

If you want, you can make it sync with the host every second:

tools.syncTime.period = 1

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1318

Once you do this, make sure Windows is NOT synchronizing itself with the hardware TOD clock. If tries to synchronize with that as well, that can cause problems, as explained in detail in the VMware document. VMware says they disable this by default, but it may have gotten enabled again, especially if you'd been trying different fixes.

Also, IMHO, Microsoft's time synchronization is no end of trouble. Since you have a Linux guest on the same host, I'd set up NTP there and let it keep the host clock up to date.

More solutions info:

Here is an excellent set of answers keeping a VM in good time sync, even though it's for a Linux VM, along with occasional bonus answers on why the problem occurs: How to keep a VMWare VM's clock in sync?

Here's an old article I suspect would work despite the references to Linux VM's: http://vmblog.com/archive/2007/08/24/help-vmware-fixing-time-keeping-problems-with-the-guest-os.aspx