Allen Tsang wrote: > Also just to review, clocksource=acpi_pm should be used in conjunction > with the tools.synctime = "true" flag in your vmx file. The combination > of the two settings prevents time from going into the future from too > many ticks, and synctime corrects slow clocks, which leads to a much, > much better clock sync. That (clocksource=acpi_pm) is ONLY the best method if your clock is running SLOWER than normal .. and in fact, a "clocksource=pit" is probably the best solution for a clock that is running FASTER than normal. If the clock is running FASTER than normal, also getting the max frequency (host.cpukHz) set per these instructions is important: http://blog.autoedification.com/2006/11/vmware-guest-clock-runs-fast.html The /proc/ location in that article is not correct for centos4 or centos5, but you can probably get the correct info for frequency most of the time from /proc/cpuinfo, dmesg, or dmidecode. > > We'll have to wait until someone figures out a clever way to tie VM > clock ticks to a multiplexed physical clock source; > until then, clocksync will always be a problem without a complete > solution (read up on it). This is as close as it gets! There is a potential fix in the Real Time Kernel () that Red Hat has released as part of their beta MRG release in that it might the support tickless option. I have not had time to look at this solution yet, but the kernel SRPM is here if someone wants to: ftp://ftp.redhat.com/pub/redhat/linux/beta/MRG/RHEL-5/src/ <snip> Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20080505/f7a74d40/attachment-0004.sig>