The Power Out of 2013
Have been in Toronto for so many years it did not come as much of a surprise when the power was out for a week at the very end of 2013. Having most of my servers on an ESXi tower made things easy to restart.
VMware ESXi
As soon as the power came back online my modem and switches kicked in and so did my UPS and ESXi tower and within 5 minutes the first virtual machine (VM) was booting up. Being my router I considered my home online a few minutes later. Within a half hour, both of my domain controllers, my WSUS, my Ubuntu web server, and a few other back end VMs where online and for the most part I was good again but still my FreePBX VoIP server was offline, since I was not home to power it on. The downside to having dedicated physical servers keeps piling up and with access to virtualization technologies like ESXi 5.1 I saw no reason why my FreePBX server could not work as a VM as well.
Research
Having done some googling I found lots of post talking about the downside of virtualizing a phone server and how future virtual servers will be able to handle ‘real-time’ applications like FreePBX, but I did notice these had all been written over a year before.
So I went on the FreePBX IRC channel, #freepbx on freenode, and spoke to the chat room full of people who work on FreePBX all the time and even from them I got mixed results. Some of them said ‘soon maybe’ while others gave a very firm ‘I wouldn’t’.
Throwing all of this aside it decided to give it a shot. After all I actually had nothing to loose but my time. I figured that I could make the virtual server with a different internal IP address and hostname, and it would not cause any issues. The reason for my assumption was that it was all still based on IP address still. The phones registered to a specific IP/port and the firewall only forwarded the SIP and RTP packets to the internal IP I tell it to. So as long as I make it with something different and manually change it later, then ‘no harm, no foul.’
Installing FreePBX 2.11 on ESXi 5.1
So I made an empty VM and downloaded the latest 64-bit distro ISO of FreePBX which was v2.11 on CentOS 6.4.
I installed it as usual on Asterisk 11 (a choice when you boot to the ISO) and it installed without issue. After some checking I even found that some of the minor issues, like the CDR not working out of the box, that I had seen in previous releases were not an issue here and everything seemed to work out of the box. Of source I knew full well that the real problems that would come from virtualizing a Real-Time application like a VoIP server would come from performance related factors and so would not show up until I tried to use it.
I continued the installation by adding Webmin to the mix on this installation just as it was on my previous FreePBX 2.10 on an Acer mini-PC and so I was able to have the FreePBX Web GUI, the CLI from having SSH access, and the Webmin Web GUI.
With everything up at the same time it was only a matter of copying over settings like the extensions, trunks, inbound routes, and outbound routes, plus my announcements, and so on.
* I did try twice actually to take a backup of my FreePBX 2.10 and restore it on my new 2.11 but this resulted in restoring 2.10 entirely as the backup is really just the DB and the files so it grabs everything and is good only for a lost system and not for bringing settings over. In both cases I had to format and re-install in order to undo the damage done by restoring.
Testing
Once my FreePBX settings, backup schedule and so on where setup I licensed the server with Schmoozecom and began to test it. I waiting for a weekend. One Sunday I powered down the physical FreePBX 2.10 server and told FreePBX to static change it’s IP to the same as the old server, then rebooted and waited. To my surprise it seemed to work without issue.
I tested the inbound and outbound calling from all the lines and everything seemed to work fine, except on of my Linksys phones, an SPA942, refused to work right and just kept showing ‘~PLEASE WAIT~” on its display screen. Knowing what I had setup I went to the phone itself and told it to restore to factory settings. After a minutes the phone booted up and found the DHCP address waiting for it. The phone then checked and found the DHCP contained a TFTP server’s IP address as well and went there looking for specific files. Since I had setup my FreePBX 2.11 with a TFTP server ( a manually installed module) and told the DHCP server to use the FreePBX server’s IP for the TFTP server it made programming the phone easy, since I just needed to have the configuration files already there. I also found that by using something called the OSS Endpoint Manager, FreePBX 2.10 or 2.11 configured the phone’s configuration files for me. So the phone booted up, got an IP from DHCP and found the TFTP server with the files that the Endpoint Manager made for me. The phone rebooted after a minute and came back up showing what I wanted it to say on its display screen and I knew that it had taken the first configuration file. After another few minutes the phone rebooted again and came back up this time with the lines I wanted it to have already configured and in order. I tested the phone and it seemed to be working perfectly.
To my surprise, this worked for my Cisco 7960 and my Linksys ATA device as well.
* This also means that if in the future I need to change an extension’s password (“secret”) then once I do I just tell the Endpoint Manager to rebuild it’s configuration file and reboot the phone and it will pick up the new settings all on its own.
Results
So far it has been a business week and I have not seen any issues with my FreePBX 2.11 running on my ESXi 5.1 tower. All these advances in phone technology are actually starting to make things easier.