Last Updated: 14-March-2013
If you are about to dive into the process of virtualizing some of your Asterisk infrastructure then some primary issues might be preventing you from moving (e.g. the lack of proper timing as you need it for IAX2 trunking). If this is your case, consider these options and the pro and cons of each one:
- OpenVZ - Better resource usage, lower overhead. Primary issue is how to grant access to host node timing source (physical device, or dahdi_dummy in /dev/dahdi/) to the containerized Asterisk process.
- KVM - Higher overhead, easier installation, ‘true virtualization’. Primary issue is not timing per se, but KVM scheduling. Timing source, while present from dahdi_dummy natively may still not get proper scheduling by KVM process. This could also affect general call quality (even non IAX2 trunked voice), DTMF, etc.
- VMware – They are moving all server products to their ESXi engine. (The old VMware “server” and ESX products are moving to legacy status – with these you could actually do stuff on the kernel). ESXi is no longer a kernel you can mess with, can’t install drivers, etc. ESXi is being treated as an appliance that you cannot and should not touch (even authorized partners like HP only get to add software through VMware). Many of these devices are not (and will not be) recognized by the VMware kernel, so forgot about host support. At best you can pass-through the device to a single guest, but then you lose the whole point of a shared timing source.
- XEN - Virtual machines can use both hardware- or paravirtualization. It has been used to separate machines where people should do their sip-registration (internet / intranet /
pstn-gateway) and the actual dial-beast.
In order to take the most out of virtualization besides easy scaling and ability to perform an upgrade in no-time, upgrade to the latest version of Asterisk, as it has a newer timing source that don’t rely on Dahdi and a complete rewrite of ConfBridge which doesn’t require Dahdi for mixing at all.