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. 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! Allen Tsang wrote: > clocksource=pit is confirmed not working in VMware ESX. > You should be using clocksource=acpi_pm in addition to divider=10 to > reduce idle load. > > Binding to a single CPU is hardly a fix. Always engineer *real* > solutions, not poor workarounds! ;) > > > > Kai Schaetzl wrote: >> Akemi Yagi wrote on Sat, 3 May 2008 06:06:31 -0700: >> >> >>> I >>> tried it but it seems to have the same problem as before - when used >>> with clocksource=pit, it hangs on bootup. >>> >> >> For the record, this can also happen in other situations with VMWare. >> For instance, I have seen that happen with a Suse 9.0 guest on VMWare >> Server that is running on Win2k3. I was trying clocksource=pit >> because the clock was jumping ahead of time like nothing. I figured >> that it is actually a problem with the Suse kernel not liking that >> specific option (it didn't hang with other clock options). I fixed >> the time problem by binding the virtual machine to one CPU core. I >> didn't even have to shut off the power saving features of the CPU. >> >> Kai >> >> > > _______________________________________________ > CentOS-virt mailing list > CentOS-virt at centos.org > http://lists.centos.org/mailman/listinfo/centos-virt