Why no Sangoma-7 love for Hyper-V?

Well, I am willing to pick up the pieces - Where can I get the old package so I can still use it?

I am willing to fix all the various problems - like I say I have done a LOT of them already.

Ok - Well I went through the History on some boxes I recently updated - found some previous versions of the script but they all fail (I guess they are too old?).

How about Flagging the Hyper-V and letting me acknowledge that I understand the risks and then letting me proceed?

Because these are Hyper-V machines, it is trivial to take a snapshot before the Upgrade starts and if it blows up, roll back - it’s one of the coolest features of Hyper-V.

Every time I upgrade a FreePBX machine from version to version, I always have some problems - I expect them and I am ready (and able) to fix whatever goes wrong.

Rather than blocking me, how about let me do it and I will live with the consequences.

Having to reload all these machines is a STRONG incentive to abandon the platform entirely.

Hmmm… I was able to successfully upgrade to FreePBX 14 at least two HyperV machines.

I believe there are many many FreePBX servers on HyperV which will need a tool of upgrading to FreePBX 14.
(Perhaps, will upgrading to FreePBX 15 on HyperV be supported?)

I hope there’s some fix for that…

This is not a decision by Sangoma, this is a RHEL decision - As is mentioned on the main page, this is blacklisted by Redhat and has nothing to do with us!

However, I did think it was a bit unusual, so I did my due diligence and tried to get a HyperV machine working, and gave up after wasting 2 hours just trying to get the VM out of UEFI mode and back into BIOS mode so I could actually boot a machine.

At that point I decided I agreed with Redhat and added an early check to fail, rather than having it fail 15 minutes later when it was doing all its compatibility checks.

If you REALLY REALLY want to, you can remove that check by changing RESULT_FAIL to RESULT_PASS, and edit the distro_upgrade file to remove that check, too, but - honestly - just use the Conversion tool. It’s much faster. 5 minutes vs 30 mins.


Ok - What is this conversion tool you speak of?

The one it tells you to use in the error message :sunglasses:


1 Like

OMG - I just used it to do a Physical-2-Virtual Conversion - that is the greatest script EVER - Rob, you are AWESOME!!!

The only thing I noticed is it didn’t migrate the SIP Settings Page - Is this normal? Now that I know it doesn’t move it, I will make sure and save it. but other than that - AWESOME!!!


I’m pretty sure it should migrate everything apart from the IP addresses. But if you want to open a ticket with what it missed I’ll look at it when I get time. I’m actually in India at the moment - you can follow my shenanigans on Facebook if you want - so I won’t be able to look at it for a few weeks, but I have a few low priority issues to look at next time I get a chance.


I am only putting this here so if anyone else tries to use this script, they are not frustrated - It is still a HUGE timesaver but there are a few things it misses:

  1. SIP Settings Page - Look at the Old Box - Copy the Settings once the new box is up - Easy.
  2. It doesn’t move /etc/asterisk/voicemail.conf - which means it turns off everyone’s VoiceMail - this can be BAD - Copy the file over manually after the migration.
  3. It doesn’t copy over the custom recordings (announcements and such) - If you look at System Recordings after the move, and go into the individual items, you will see they are all broken - copy over the whole directory.
  4. It doesn’t migrate /etc/asterisk/extensions_custom.conf - since I have code in here, I had to copy this file too!
  5. Endpoint Manager - This is a bummer - but it can be re-created…

For the more Linux-Noobs, if you have both machines on the same subnet, it’s a simple

scp -r [email protected]_machine:/folder/you/want/to/copy/* /same/destination/folder

and then put in the root password. Make sure if you copy any files this way, you do a fwconsole chown before you submit the new system or you may hit a permissions problem.

That is all I have found so far - I have done 4 Physical-2-Virtual Migrations/Upgrades so far - it works great!


I guess that if we want this script to be complete, someone should open a feature request, everyone will benefit from this…

There are pending tickets on all of these except for this one:

Please file a ticket for this at https://issues.freepbx.org you want the component to be ‘conversion script’

I will - I have a few more to do so I am going to make sure my list is complete - like this morning I saw that Endpoint Manager doesn’t come across either - That can be a real bummer if it’s a large install - just trying to make sure I see everything so I don’t keep going back over and over again to say this new thing doesn’t work.

Here is a link to all open conversion script issues. EPM is already a requested feature.

1 Like

OK - I added a comment about /etc/asterisk/extensions_custom.conf - Thanks!

You piggybacked a tangentially related ticket. Best to open a new ticket for the *custom.conf files.

Oh - Sorry, I thought you wanted me to add it to the existing ticket.

We’ve made the decision to NOT migrate custom files. Anyone who has made changes to those files will know to check. Anyone who had NOT will be happy to know that a potentially attacked file will not be replicated across.

Ah crap, I knew this at one point, and it’s also documented in the wiki:

So as of today there is no upgrade path on Hyper-V that doesn’t wipe out the EndPoint Manager configuration?

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.