facti.net

There are several factors that can affect the clock in a guest OS running inside VMware. I was previously aware of a couple that have been (mostly) fixed:

• Timer interrupt rate
• Low power idle state on laptops

However, I noticed another problem with unpredictable time behaviour on my AMD system that appears to be triggered when a browser performs certain actions. A bit of digging reveals it is a known issue: Virtual Machine Clock Reports Time Unpredictably on Multiprocessor Systems. Since it is not really practical to disable the "cool'n quiet" mode (the machine generates serious heat when running flat out), I applied this fix on the virtual machine images: How to Run VMware Hosted Products on Systems on Which TSCs Are Not in Sync.  The key statement is this: 

If you are using GSX Server, VMware Server, or Workstation on a
64-bit AMD multiprocessor system, the VMware product does not assign
each virtual machine to a subset of processor cores by default. If you
need this assignment to be done on your 64-bit AMD system, choose a
specific processor core to which to assign each virtual machine, using
the processor<n>.use options as described in the next section.

So the fix on the dual Opteron is to add this to the ".vmx" file:

processor1.use = FALSE 

Incidentally, I noticed that drive-mapping an HGFS shared folder within Windows guests significantly improves performance, even in the systems where the registry fix was applied.