Apparently this is a known issue, http://support.microsoft.com/kb/918461

From the KB:
---
After you install a Linux-based virtual machine in Microsoft Virtual Server 2005 R2, the system time in the Linux guest operating system runs too fast. For example, the current time in the Linux guest operating system may advance by one minute approximately every 48 seconds. After some time, the Linux-based virtual machine resets the clock to the correct time.
---

I've tried the suggested resolutions in the KB but still having problems keeping my CentOS 5.3 clock accurate. It either runs too fast or too slow. The system clock is inaccurate but the hardware clock seems to stay accurate. Running ntpd does not help because the clock is so far off. I have another CentOS system running on XP with VMware and it does NOT have the same problem.

So what I've done as a solution is to set a cron job which syncs the system clock to the hardware clock every minute.

* * * * * /sbin/hwclock --hctosys

I'm not too happy with this solution and I'm about to deploy a bunch of high traffic web servers using RHEL5 on MS Virtual Server and really want a better fix.

Besides using VMware does anyone have a solid solution?

Does anyone know if this problem also occurs on MS HyperV?

Thanks.

Nope, sorry. VMware used to have an issue with RedHat and the clock being out of sync, but that was addressed pretty quickly by both parties. I doubt Microsoft cares, and they probably won't fix it for a VERY long time, if at all.

If its any consolation, I had to do the same thing with VMware and RedHat for a month or so, until the patch got released. Thankfully, I was able to keep the synching down to every 15 minutes, instead of every minute.

One thing I will say, is that NTP won't sync up, if the clock is too far out of whack. If you run ntpdate (or sntp, if that command is depreciated on CentOS as it is on OpenSuSE), and get the clock close, you can fire up NTP. The bug exists, though, but you may be able to sync less frequently, and keep NTP running if you get things in synch 'manually'....

Good luck.

Just a quick, ironic, and sad update. None of the things I tried would keep the clock accurate to an acceptable level. It's hard to believe but my final solution that works pretty darn good was to install Samba just so that I could run "net time" and sync the clock off of a Windows file server. So a MS solution to a MS problem. Hmm.