Asterisk 13 On Old VMware ESXI 4

Home » Asterisk Users » Asterisk 13 On Old VMware ESXI 4
Asterisk Users 8 Comments

I am having a very tough time trying to replace an Elastix 2.X
install running as a virtual machine on ESXI 4. I tried using the Freepbx 14 ISO that installs CentOS 6 along with Asterisk 13.16 but I
keep getting random segfaults:

[175711.476685] asterisk[2942]: segfault at 188 ip 00007fc6c41abffc sp
00007fc608575890 error 4 in libasteriskpj.so.2[7fc6c4144000+14c000]

I then proceeded to install a CentOS 7.3 VM and compiled Asterisk
13.17.0 by hand. We are still using Freepbx 14 for the front end. We did some testing over the weekend and calls were coming in and out and all extensions were registered. Come Monday Asterisk started segfaulting again with exactly the same error. Maybe VMware is too old to support the newer CentOS and Asterisk? The Elastix install is based on CentOS 5 and Asterisk 1.6. I have no idea how to approach this. It only segfaults when there are only more than a couple simultaneous calls, that is why testing with only a couple of calls worked.

There are several core dump files but I really do not know how to use them for debugging Asterisk. Any ideas? I will try using chan_sip instead of PJSIP to get things running but confidence is not high.

—
Telecomunicaciones Abiertas de México S.A. de C.V. Carlos Chávez dCAP #1349
+52 (55)8116-9161

—

8 thoughts on - Asterisk 13 On Old VMware ESXI 4

  • Licensed or free ESXI?

    I want to say your version is too old. I’m currently running ESXI 6.0 update 3 at home and Asterisk in a VM under debian without issue.

    Doug

  • The version is licensed and the customer does not want to invest on new hardware/software at the moment. If the ESXI version is too old I need to give them definitive proof that the segfaults are caused by that but since the old elastix has been running there for years they do not quite believe it.

    —
    Telecomunicaciones Abiertas de México S.A. de C.V. Carlos Chávez dCAP #1349
    +52 (55)8116-9161

    —

  • I wouldn’t believe it either. I’d be quite surprised if something won’t work with any ESXI version. *Perhaps* there’s a configuration issue, but I’d be surprised about that too.

  • There are certain versions of the Linux kernel that have no support under the older version of ESXI. We started having issues under our ESXI v4 setup with RH Enterprise and vmware’s response was, “It’s not supported”

    Doug

  • “not supported” and “does not work” are not the same thing. ESXI
    emulates specific hardware. Most kernels will work with old hardware, so they should work with old ESXI, though there may need to be some configuration changes and there’s always the possibility of bugs in ESXI that weren’t detected by older kernels. But the question here was *Asterisk*, not kernels. User-level code has *way* fewer dependencies.

  • The messages that get dumped to the kernel log aren’t of much use. See below for more info.

    That *should* be a good combination.

    If you still have the coredump files, you can use the ast_coredumper utility located in /var/lib/asterisk/scripts to extract the human-readable stack traces. “sudo /var/lib/asterisk/scripts/ast_coredumper –help” will get you more info on how to run the command. The *-thread1.txt file it produces will be the most helpful but all 4 should be attached to the Asterisk issue should you decide to create one.

  • Richard Kenner wrote:

    *Precisely*. Unless we’re talking DAHDI here (which we’re not), Linux & ESXi are red herrings.

    Carlos Chavez wrote:

    There’s no way this has anything to do with ESXi or the version of it that you are running. Zero. Zip. Zilch.

    If you want to prove this to yourself and others, take the *exact* same binary bits, install them bare-metal on another piece of hardware, run the same traffic through it, and watch it crash and burn in the same way. The only way that I can see this playing out differently is if the bug (yes, bug) in Asterisk and associated libraries is extremely timing-dependent, and running it in a VM is exposing this bug in a way that most bare-metal installations wouldn’t.

    Given that the log entry you pasted into your e-mail references “libasteriskpj.so”, I’d bet $$$ that switching to chan_sip has an extremely high likelihood of working, assuming that your set-up has no particular dependencies on PJSIP-specific features that you have to work around (and if you are migrating from an Asterisk 1.6 installation, I’m guessing it doesn’t).

    Best of luck,

    — Nathan

  • I run the CentOS 7.3 / Asterisk 13.17.0 combination of software installed from the same sources on multiple servers across a wide variety of hardware (both metal and virtual) and this is the only place that I have encountered this particular problem. That is why the only variable left is the version of ESXI as newer versions work.
    Unfortunately I do not have a newer server where I can just import this same VM to completely eliminate the possibility.

    —
    Telecomunicaciones Abiertas de México S.A. de C.V. Carlos Chávez dCAP #1349
    +52 (55)8116-9161

    —