asterisk users - Aug 2017 - Asterisk 13 on old VMware ESXI 4

>>> On Aug 2, 2017, at 6:45 AM, Richard Kenner kenner at gnat.com
wrote:
>>> 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

> 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"
"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.

Richard Kenner wrote:
> But the question here
> was *Asterisk*, not kernels.  User-level code has *way* fewer
> dependencies.
*Precisely*.  Unless we're talking DAHDI here (which we're not), Linux
& ESXi are red herrings.

Carlos Chavez wrote:
>       I am having a very tough time trying to replace an Elastix 2.X 
> install running as a virtual machine on ESXI 4.  
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.
> I will try using chan_sip 
> instead of PJSIP to get things running but confidence is not high.
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