This, by the way, horrified all our NTPD theoreticians, who made it clear that running ntpdate was going to cause catastrophic things to occur in our Operations environment - but, given that our logs were all getting progressively more and more useless as we were unable to correlate times for events between servers - the worst case scenario (in my mind) had already occurred.
I don't recall any particularly negative side effects as a result of our ntpdate sledgehammer.
I presume things have gotten better in the last 10 years with VMware.
Years ago, the answer was to run NTP on the host and use VMWare Tools to help ensure that good quality time was served to the clients. That's when the earlier versions of the page at <http://support.ntp.org/bin/view/Support/KnownOsIssues#Sectio... were written.
Since then, that advice has apparently been recanted.
The ultimate problem with any virtualization system is the frequency and accuracy of clock updates to the client, and the loss of clock interrupts.
To the degree you can solve that problem, protocols like NTP can work reasonably well to monitor and correct for various types of known clock issues.
I'm told the w32time codebase is not something MS employees like to look at.
I could be wrong, but I was disappointed that the utility didn't return any errors when it knew that it was going to ignore you.
At this point I'm thinking I need to run ntp on the physical hardware with the least jitter, then just run ntpdate in a cron job on all the VMs. This would work better than ntp clients in the VMs or the VM tools.
Eventually I had ntpdate running every minute via cron. Pretty annoying.