Current Experience - Hyper-V FreePBX on Azure

Does anyone have any recent experience with hosting their Hyper-V FreePBX 15 VM on Azure? I am thinking about is as I am tired of maintaining all the infrastructure for our current setup (about 30 Hosted VM’s) and also I am somewhat limited on what I can host without increasing my infrastructure, so cost goes up either way.

The main attraction to Azure (apart from already being a Microsoft Partner) is the Migrate Hyper-V VM’s to Azure - Migrate Hyper-V VMs to Azure with Azure Migrate Server Migration - Azure Migrate | Microsoft Docs but also because we have always run them on Hyper-V so we are fairly good at it.

I have seen several older posts about people setting up scratch instances on Azure, but I would be migrating them as they sit - Has anyone else tried this?

Also, RAM - I run all my VM’s with 4G of RAM, but that get’s a little pricey on Azure - Has anyone tried this setup:

$22.63/Month to host them on Azure is easily doable but it seems like a little low on the RAM.

Anybody doing this, or is this an unknown?

I have run FreePBX 15 on Azure using the B-series instance types.

It will run on 1GB of RAM (B1s) if you are mainly using just Asterisk – disable UCP node, XMPP server, etc. Add a swap file and watch memory carefully.

It runs more comfortably on the B1ms and B2s. (2GB, 4GB)

Do you have a compelling reason to migrate your VMs rather than backup and restore?

Backup and Restore has been so hit-and-miss in the past I am loathe to use it except in an emergency - Dial-Plan not functioning correctly, missing media, odd behavior after the restore. It’s just another black-eye as far as reliability with the Customers when I have to restore - it’s never back to where you started - it’s always to some other place where you have to fix things to get back to where you started.

Having said that, I have done no 15 restores, and from what I read here, it is better - but I have been burned so often in the past, that migrating the machine sounds like it has a better chance of working.

You have had good luck with 15 restores?

B2 is what I was looking at also - FreePBX and Asterisk in particular acts wonky in low RAM - Once it starts paging out memory, the audio suffers - I learned that early on and have not repeated that mistake.

Do you mind me asking how many simultaneous channels you have gotten going, and whether or not you use any HD audio? My customers seem to really like G722 and most of them are using it now - I can’t imagine that would be too much for Azure, but I want to be paranoid.

Don’t want to hijack this thread, but I will point out that backup module in 15+ was rewritten from scratch, there is no common code with 14 and earlier. The Backup and restore module It is THE supported way of moving between versions, so if you experience issues when restoring on a 15 system, we want a ticket.

I would love to be wrong about restores - I will try one with my experiments in moving to Azure and post the results - I did see that it was re-written, but before you all did the 15 Backup/Restore model I perfected Hyper-V Replication with 13/14 and haven’t had to restore a machine since.

But I will try - it’s a VERY good thing if it works like it should! I just have no personal experience with 15 Restore.

My experience with a 14 -> 15 backup/restore migration was flawless. 15 -> 15 also. I think some folks have problems because they do not actually back up everything they want, and then find things missing on the restore.

G.722 takes no more resources than G.711 and transcoding between the two (which you would likely do for calls to the PSTN) is trivial.

I am going to try restores once I try a test migration (doing that now).

That is what I thought about G.722 but it is good to have it confirmed.

How would you go about loading a FreePBX instance into Azure to be able to restore? I am looking around at what they have available and all I see are generic CentOS/Ubuntu/RHEL installs - how do you get the FreePBX Distro as an option without a migration? I really do want to start from the Distro - it just fixes so many problems and avoids so many issues that are posted here getting a scratch load working.

I am still looking - maybe I will find it, but I can’t see it right now.

Ok - This is cool so far - I am in the process of migrating my first machine up to Azure - The Analysis tool said I needed to use Standard_F2s which looks like this:

That’s funny, because it’s almost exactly what I am using on the server it’s hosted on now - don’t know how “deep” the analysis is, but whatever.

The cost estimator says it will be about $34.00/Month - that is actually fine - we charge our customers $75.00/Month to have their server in our CoLo, so we can still make money at this level of expense.

I will post some stats once I have it up and running - load, throughput, etc, but this is looking good!


I installed it there from the ISO directly on an Azure VM… it’s a small bit of sleight of hand but it works great.

Could you please provide some details? You cannot do it easily on AWS or GCP, so this would be very attractive to someone who wants to use a major cloud provider without a big setup hassle.

Do you have any experience with this on Asterisk 18? Supposedly, you can set it up so the extension negotiates G.711 when that’s all the trunk endpoint offers, but provides G.722 between extensions and when the trunking provider does G.722. No transcoding is required.

Even better, are you aware of any decent VoSP who offers a wideband connection when the remote party on VZW, AT&T Wireless or T-Mobile is VoLTE capable? Either G.722 or having Asterisk transcode from AMR-WB or other native codec would be fine.

I assume you’re talking about the new late negotiation described at

Which looks great but I don’t think FreePBX implements it yet.

I haven’t paid attention to this. I know the folks over at talk about it from time to time.

I agree, which is why I sell this solution. Sorry, no public details to disclose for now. :slight_smile:

Azure can be great if you actually need to add regional redundancy and such. But that adds to the cost. But for a basic phone system without that extra redundancy, Azure is overpriced for this. Vultr has been solid for me and Digital Ocean has similar pricing.

You can match that size for $20

Add $4 for automatic backups.

You can upload your own ISO files, but they already have FreePBX as an option.

Hmmm…that is something I am going to have to check out - Do you know how long Vultr has been around and are they stable? It would be a bummer to get in bed with them and then have them go Tango-Uniform.

So far the biggest bummer I have found with Azure is that even though they are hosting with Hyper-V (It’s Microsoft’s standard thing) they don’t expose the Hyper-V Manager to you - so you can’t connect to the “Console” of the VM the way you can on your own Hyper-V Server! Found out the hard way yesterday when I migrated my first test server and then no matter what I did, I couldn’t connect to it - it had an incompatible network config from it’s local iteration and I could not get to the console to change it.

CentOS is supposed to have the Serial Console turned on by default, but FreePBX has it turned off - so I basically had to nuke the migrated machine and try again.

We switched to Vultr 2 years ago and there is no looking back !

My experience with Vultr/DigitalOcean is that either of their $5 dollar + $1 backup offerings will happily run a busy FreePBX for at least 20 users, that would include monitoring and some transcoding but only a little xmpp/UCP.
OutOfMemory can happen if you do “All-in-One” backups on a hard used machine unless you add significant swap-space or break the backup tasking up.

1 Like

I have a couple systems, going on 4 years now, that are desk phone only locations with ~100 extensions and ~15 concurrent calls peak and 5 average on the $5 + $1 backup size.

Zero issues because of Vultr instance size. Vultr outages noticed once by customer because it was a couple hours for the Chicago data center. I think only 3 times total, the rest blips, but fuzzy brain so not 100% on that.


Not exactly Hyper-V.

Personally a couple of years ago, Vultr dropped everyone of my Los Angeles servers for hours at a time, they never fessed up or compensated even with un-surmountable evidence. ( I never forgave them, DO gets my business right now)

1 Like

Add to your kernel boot string:

console=ttyS0 earlyprintk=ttyS0 rootdelay=300

probably best to do this before migrating it over :wink:

1 Like

Yeah, I figured that out too late - that machine was in no-mans land. But good to know going forward if I ever do that again…

I have spun up two servers so far on Vultr and I am totally impressed - the machines are much more responsive than my machines running on my servers with more resources - I am using the NVME 64G/1Proc/2G-RAM instances and they are very responsive and HD voice over them is perfect.

I am even doing Video through it - I have two Polycom VVX1500’s that I foolishly bought back when they came out - set up one at my office and one at my home-office for my wife and it was perfect - clean, smooth and no hesitation that I can see.

This weekend will be the real test - I am going to do a 15-Backup on one of my local machines and migrate it over to the Vultr instance and see how that goes.