Colleagues, tell me what tools allow you to evaluate the suitability of the provided virtual machine for installing Asterisk into it?
I have always installed Asterisk on real machines, but now more and more often I have to deal with installations on virtual machines. Of course, virtual machines respond less well to load surges; their latency and jitter parameters are significantly lower.
Please, tell me, is it possible to assess the acceptability of a particular virtual machine, knowing the basic parameters of the expected load of Asterisk?
The trick is to not run your host on the bleeding edge of it’s abilities. If you just do something like throw VirtualBox on a desktop and VM Asterisk on it…yes, you might see some issues if you try to run the entire corporation’s phones that way.
But in a properly configured environment…this is not a problem. It’s just when a host has a lot of stuff on it that initial surge might not be available at the time it’s needed. As long as you plan out what’s getting virtualized on what host and stay within the total power of your machine…it’s fine. It just means rather than 12 VMs on a host you might do the smart thing and drop it back to 4 or something.
I work in an industry where we essentially have Asterisk virtualized in the cloud; and it runs fine in the cloud. This is all type-1 bare-metal virtualization; not a VM running in a program in your desktop OS. That is likely the key…we’re not doing it in a random desktop we’re doing it in a server environment specfically designed for this stuff.
Now if you want to run a PBX at home…then it shouldn’t matter because that’s stupid low volume.
In our business, we operate virtualized instances of Asterisk within openVZ containers. Our use of Asterisk goes beyond a simple PBX; instead, we utilize it as a versatile platform for crafting intricate telephone applications. These applications demand intensive database operations, substantial disk I/O for reading and writing, and a sophisticated dialplan.
Despite these unique requirements and the somewhat unconventional solutions we’ve implemented, we are proficient at maintaining between 60 and 80 simultaneous calls with relatively modest resources (our most extensive virtual machine boasts 6 GB of RAM and 4 VCPUs, for example).
While we’ve experienced occasional inconveniences, like noisy neighbors causing disruptions, our service provider typically resolves these issues promptly upon receiving a complaint.
Asterisk, to the best of my knowledge, does not distinguish whether it’s running in a virtualized environment or on a physical server. It operates as long as it’s provided with the necessary resources. For virtual machines, optimizing performance can be enhanced by configuring “autoload=no” in /etc/asterisk/modules.conf and selectively loading only essential modules. Additionally, thorough optimization of the dialplan and any external scripts is crucial.
Regarding jitter, packet loss, and related concerns, we adhere to the reliable g.711 codec, which has consistently delivered excellent results. We cannot provide insights into the behavior of other codecs in the face of potential timing issues that may arise when running Asterisk on a virtual machine. However, as long as we limit concurrent calls to 80, g.711 serves us well. Pushing beyond this limit can overload the system and degrade audio quality, resulting in performance issues.
At home, I have Asterisk on a powerful server running FreeBSD and no virtual machine will desecrate it by appearing there. I have not yet forgotten how to run several server applications on one Unix server.
Our OpenVZ container was moved to another physical machine and asterisk didn’t start anymore, because it had been compiled from the source with CPU optimization. We had to recompile asterisk with that flag turned off (I don’t remember now which one). So keep this in mind if you compile asterisk.