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@centos.org http://lists.centos.org/mailman/listinfo/centos-virt