Well, to the clock being fast work around, I kind of found a way to work around it for now...
1) use a distribution that supports VMI (VMware's paravirtualization) 2) enable VMI paravirtualization support in VMware Workstation 6 VM's profile 3) use vmi-timer as the clocksource (as opposed to pit, acpi_pm, etc.) 4) CPU must be constantly at maximum frequency
For 1), I use Ubuntu 7.10 For 2), the VM must be VMWare 6 profile type, then in Settings -> Options -> Advanced, check on "Enable VMware paravirtual kernel support"). I was unable to use VMI before because my entire Vista (x64 Ultimate) machine will BSOD when Ubuntu was booted with VMI turned on; only in the recent Workstation 6.0.3 patch that this bug has been fixed. For 3), Ubuntu default to vmi-timer if 1) and 2) are working properly; can be verified by /sys/devices/system/clocksource/clocksource0/available_clocksource and current_clocksource For 4), I didn't want to constantly lock the CPU of my laptop at highest speed at any time, as I don't need the CPU at full blast when I'm browsing website, or using MSOffice. So what I've done is by using distributed.net - this program uses idle CPU power to do calculations. This program keeps my CPU busy at all times but easily switched out when other programs need the CPU.
With this, the Ubuntu's VM clock runs at a fairly accurate rate. The side effect is my CPU is constantly busy and the laptop cooling fan kept going and going (and no more putting my PC on my lap as it will be fairly hot). I also have a desktop with AMD Athlon X2 running Windows 2003 Server; with the above configuration (minus #4, as W2K3 Server keeps CPU clock rate constant) the Ubuntu VM's clock also was within 5 seconds compared to the host PC's clock over the period of a day.
I hope that VMware will be able to devise a better way to keep VM clocks accurate in the future in their products.