On Thu, 2008-06-26 at 06:04 -0700, Akemi Yagi wrote:

...

This bug report: http://bugs.centos.org/view.php?id=2189 seems to suggest clocksource=pit and divider=10 will crash kernels and I did not see "it's fixed" in the release notes.

Right, so, if you do not need the clocksource= option, you can use the divider option. But otherwise, kernel-vm is the way to go. I trust Tru would keep providing us with the kernel-vm until the bug is fixed.

Is there any detail on when you would actually need to use the clocksource= option? I'd love to not have to deal with the kernel-vm packages since there doesn't appear to be a repo for them yet and if you have other requirements like kmod-drbd you have to manually rebuild those.

On Thu, Jun 26, 2008 at 2:43 PM, John Thomas gmane-2006-04-16@jt-socal.com wrote:

David Hollis wrote:

...

Is there any detail on when you would actually need to use the clocksource= option? I'd love to not have to deal with the kernel-vm packages since there doesn't appear to be a repo for them yet and if you have other requirements like kmod-drbd you have to manually rebuild those.

I use clocksource=pit because my VM clocks ran WAY fast without it. They still run a bit fast (1 second per 6 hours type of thing). If you do not use a clocksource option, how are your clocks?

Yes, clocksource=pit is needed IF your clock goes faster. If the clock tends to go slower, use of the divider= option should do the trick.

Akemi

Johnny Hughes wrote:

One thing to make sure of if your clock is running fast is to get the correct setting for this in your vmx file for the VM: host.cpukHz = See this link for more info: http://blog.autoedification.com/2006/11/vmware-guest-clock-runs-fast.html

I suspect (please clarify if I am wrong) you mean the /etc/vmware/config file, not the vmx file. The blog article suggests /etc/vmware/config.

Note: if you do not have the command cpufreq-info you can get it by installing cpufreq-utils with this command: yum install cpufreq-utils

After installing cpufreq-utils, "cpufreq-info" produced, "no or unknown cpufreq driver is active on this CPU". I, through the notes in the above blog article, found /proc/cpuinfo had this: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping : 1 cpu MHz : 2995.211 cache size : 1024 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc up pni monitor ds_cpl cid xtpr bogomips : 5992.20

Then set the value based on the above article, then time might not run as fast.

I am not sure if I should use: host.cpukHz = 3000000 or host.cpukHz = 2995211

I have tried both. Neither seems to work. My current solution, is to run a script once per hour that pauses for two seconds, then sets the clock back one second. The vmware time sync brings the guest clock current if it gets behind from the script.

Are you able to think deep enough to figure out if I should set the host.cpukHz above or below the above range to see if that would slow down the guest clock? I wonder if I should even try that.

Thanks, Johnny Hughes

Thank you Johnny. I very much appreciate your time.

On Mon, 2008-06-30 at 16:32 +0200, Tru Huynh wrote:

kernel-vm are a workaround for the current issue on the regular kernel. No one forces you to use them :)

But if I do use them, am I able to avoid any kernel cmdline params games (like clock=, noapic, etc etc)?

It's sounding a bit like every host has different quirks so there really isn't a magic bullet "Use this kernel or this param and things will magically work and be happy."