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