Trixbox under VMWare Server 2.0 hosted on Linux

The easy is to just linux on host box and not windos

Squiggly,

I do not think I that I can thank you enough for posting this info here... It took me days to gather it from different places, but when I found it already posted here by you I was reassured that I am on the right track thanks.

Virtualization is the wave of the present, those who resist it are stuck in the past.

You could opt to set/correct your VM time after you boot with new kernel:

service ntpd stop
ntpdate 0.pool.ntp.org
hwclock --systohc

Check the date/time in both OS and VM side:
date;hwclock

If all looks OK - start NTP again:
service ntpd start

Also, after upgrading kernel on trixbox 2.6.2.3 my freepbx was broken, so I ran install_amp in /usr/src/tbm-pbxconfig-5.5.1 and that fixed it for me.

trixbox 2.8.02 now uses Dahdi. The new Dahdi dummy has much better trimming then zaptel dummy. I have run 2.8.0.2 under vmware without any problems.

Don't hijack another thread to get an answer to your question.

Go to the wiki and read the getting started guides.

In 2.4 kernels the system timer was normally clocked at 100 Hz, while in 2.6 the default system timer is set to 1000 Hz (some other distros are not following these "rules", and USER_HZ is still 100). 1000 Hz is definately a good thing for desktop computers requiring fast interactive responses, but there are environments where this causes bad side effects.
Kernels compiled for SMP the system timer will requests twice as many interrupts when running on a single cpu and 2.5 as many when running on a dual cpu system.

Some cpus can't keep up with this interrupt rate, and the 2.6 kernel has code to detect this, but it can't always correct for lost ticks, and having the interrupt rate this high is also affecting the performance negatively. The negative effects of this has been experienced in virtual environments using VMware products.

In a virtual environment, a key indicator that these systems are not properly setup is if you have an idle guest system (indicated by tools inside the guest) while the host reports that this guest is using a lot of cpu (typically 20-30%). Another indicator is that the clock inside the guest is not keeping up with time. On newer cpu's these effects are not as visible as on old cpus (for example a Pentium 3 500-1000MHz), but also on newer cpus you will not be able to scale as well due to these issues, resulting in fewer guests systems per server host.

Kernel-vm was clocked at 100HZ instead of the usual 1000HZ provided by the regular CentOS kernels.

Anyway, since the release of CentOS 5.3, there is no longer any kernel-vm provided since it is no longer needed.

If you are running Centos 5.3 on 32 bit, all you have to do is:

modify the startup parameters in the bootloader (grub) by adding "clocksource=acpi_pm divider=10" at the end of the menu entry so it would read like this:

title CentOS (2.6.18-164.6.1.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-164.6.1.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet clocksource=acpi_pm divider=10
initrd /initrd-2.6.18-164.6.1.el5.img

If you are running Centos 5.3 on 64 bit:
substitute clocksource=acpi_pm with notsc

Here is a list for best practices published by vmware.

Note on CentOS 5.4 and divider=10
For CentOS 5.4 and later, divider=10 is a supported kernel configuration option, but is no longer necessary for accurate timekeeping. Using it reduces the frequency of timer interrupts by 10x, which reduces the CPU overhead of processing timer interrupts. This overhead is especially noticeable for idle virtual machines. The only drawback of using divider=10 is that the granularity of wakeups provided by the kernel changes from 1ms to 10ms. The vast majority of applications are not affected by this, but using divider=10 may not be the right tradeoff for some time sensitive applications. For CentOS 5.3 and earlier, divider=10 greatly improves timekeeping accuracy and is strongly recommended.

Hope this helps!