Category: Linux

Previously, I’ve never had much success running trixbox within a virtual environment, but I decided to revisit the possibility with the recent release of Windows Server 2008 R2 and the latest version of trixbox (currently 2.8) and this time had much greater success.

The only thing I had to do was install the Microsoft Hyper-V Integration Components for Linux on the machine and set the kernel parameters appropriately (as described below).

You can download the .iso from Microsoft at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ab7f4983-93c5-4a70-8c79-0642f0d59ec2.

Currently, CentOS/RedHat doesn’t appear to be supported by Microsoft, but following the steps below will allow you to install the appropriate drivers (and confirm a successful intallation): –

• Mount the downloaded .iso on your trixbox machine
• Install the kernel-devel and gcc (GNU Compiler Collection) packages by running the commands below

yum install kernel-devel

yum install gcc

•  Now you’ll need to mount the CD ROM using these commands

mkdir -p /mnt/cdrom

mount /dev/cdrom /mnt/cdrom

• Copy the contents of the CD to the local machine

cp -rp /mnt/cdrom /opt/linux_ic

• Unmount the CD ROM

umount /mnt/cdrom

• Run the driver setup

cd /opt/linux_ic

./setup.pl drivers

• Set the kernel boot parameters as per this article
• You’ll need to restart to initialise the drivers

shutdown -r now

• When the machine is back up and running, make sure the drivers are loaded by running the command below

lsmod | grep vsc

• This should give you a result similar to the following

netvsc

storvsc

blkvsc

vmbus

scsi_mod

Now you have the integration components installed, configure the rest of the options on your trixbox and test it out. I allocated mine 512MB RAM, and it doesn’t skip a beat while I performed audio streaming tests.

I found this issue specifically on CentOS running the trixbox telephony software, where over a 12 hour period my system clock had gained over 3 hours of extra time.

This is not a good thing for VoIP, as it relies heavily on time for RTP packet switching.

I also had a compounding issue of my system locking up whenever I tried to perform an NTP update from one of my domain controllers, with an error similar to the following: –

BUG: soft lockup – CPU#0 stuck for 10s! [bash:2513]
EIP: 0060:[<c06100b8>]

dahdi_dummy_timer

It turns out that this service is particularly time sensitive, and the very large time step incurred by an NTP update causes it to lock up until the time is back in phase, but in my case that will never happen because of the rate that the system is gaining time.

My solution was to disable ACPI and APIC at boot time, prevent the dahdi service from starting at runtime and then perform an NTP update and update the hardware clock with the system time by performing the following steps: –

1. Modified the kernel boot options by modifying the boot loader config file (trixbox uses grub, so I had to edit “/boot/grub/grub.conf” to add “divider=10 clocksource=acpi_pm” after the appropriate kernel line
2. Ran “chkconfig dahdi off” to prevent the dahdi service from automatically starting
3. Restart
4. Ran “ntpdate -u <NTP server IP>” to update the time
5. Ran “hwclock –systohc” to update the hardware clock from the system clock
6. Ran “chkconfig dahdi on” to allow the dahdi service to start automatically again

Now the time is accurate and my VoIP calls are working properly.