OMG - Hyper-V Live Migrations

Don’t know if anyone else had tried this - You can move a FreePBX install live - Even have running phone calls and they don’t drop - Fantastic!

1 Like

Be careful. Default behavior of Hyper-V is dynamic MAC address. The way FreePBX handles licensing means that if your MAC changes your installation (and any commercial modules) will become unregistered and you’ll be doing some cleanup.

You won’t realize this until after you’ve moved the VM and then reboot it. A new MAC address will be assigned to your ethernet adapter due to dynamic MAC being set in hyper-v, eth0 will stop working in CentOS and you will get a new interface (eth1). The web gui will be unreachable until you fix things.

Fixing it can take a bit of work if you don’t know your original MAC address. Luckily you can find the original MAC address after moving it even if you didn’t have it written down (check through your firewall rules config files). If you do have this happen, even after setting the MAC address back and rebooting the VM, you still will have to register FreePBX using the existing Deployment ID. You can do this with the following command;

fwconsole sa a DEPLOYID

If you can’t figure out your original MAC you will have to reactivate the installation. this means you have to login at portal.sangoma.com and “reset your hardware lock” which I believe is still limited to doing this 2 times before you have to contact support.

You probably want to set your MAC to STATIC in Hyper-V (and any hypervisor for that matter) and just make sure you don’t cause a MAC conflict.

1 Like

Thanks for the heads up - Yes indeed, on a Centos-6 box (the current FreePBX Release) it resets the MAC on the first power-cycle to whatever range is on the box you are moving to.

It’s actually pretty easy to fix if you don’t care that the MAC changed - /etc/udev/rules.d/70-persistent-net.rules is the file you need to edit and it will have the following two lines if you already let it boot once (it will have assigned the new detected adapter to eth1):

SUBSYSTEM==“net”, ACTION==“add”, DRIVERS=="?", ATTR{address}==“00:15:5d:18:12:05”, ATTR{type}==“1”, KERNEL=="eth", NAME=“eth0”

SUBSYSTEM==“net”, ACTION==“add”, DRIVERS=="?", ATTR{address}==“00:15:5d:16:73:02”, ATTR{type}==“1”, KERNEL=="eth", NAME=“eth1”

And then the file /etc/sysconfig/network-scripts/ifcfg-eth0 will reference the original MAC like so:

HWADDR=00:15:5d:18:12:05

Fix the HWADDR to the new (generated MAC) and then edit /etc/udev/rules.d/70-persistent-net.rules - remove the old adapter, and re-number the new (detected) address like so:

SUBSYSTEM==“net”, ACTION==“add”, DRIVERS=="?", ATTR{address}==“00:15:5d:16:73:02”, ATTR{type}==“1”, KERNEL=="eth", NAME=“eth0”

and then reboot and you are golden - We have fixed this many times moving a FreePBX install from one physical machine to another. But you will have to to do a Zend Reset if you have commercial modules.

HOWEVER - since this is Hyper-V, we don’t need to go through all that rigamaroll - just look in /etc/udev/rules.d/70-persistent-net.rules, get the MAC the machine is expecting, shut it down and set that static MAC and you are also golden (and don’t have to re-authorize the machine).

Finally, one of the machines I migrated last night was our web server (http://www.bdc-llc.com) - it’s a WordPress site running on CentOS-7 and it got a new MAC address, but came up under the proper static address anyways - Yet another reason to hope the migration to FreePBX-14/CentOS-7 goes well!.

As @JayG30 said. HyperV users be aware to set your MACs to static to ensure your PBX fails over without major issues in most cases anyway. This caught us the first go around, now its just the default settings we do for basically all linux boxes we install. the 70-persistant fix works, but its really messy when you are in a hurry to get services restored, and completely avoidable.

Yeah, Hyper-V live migration is awesome for this.

I too was hit by the changing MAC address when I first tinkered with Hyper-V Server 2012 R2. super used to it now