@sshughes My understanding of the system so far (but take that with a grain of salt, in real life I'm sort of an accountant who's only larp'ing as a sysadmin here): the system is not meant to 'run on a single host and when it dies we replace it'.

It's meant to run on three identical hosts which never all die at the same time (except for some GBU hitting their building). Therefore there is no focus on 'let's reconnect new hardware to existing SR and fire up the VMs stored on that SR'.

After planning accordingly, I can live with that. Planning accordingly in my case means: 'well, if my single host dies (running two or three isn't worth it for me), I'll take a day of down time to restore from backups.'

@sshughes When you go to 'Home > Hosts > YourRestoreHost > Tab:Network' in XO, is eth1 shown there? If not, it might need introduction.

@jsox79 had the same problem. Seems to happen with CentOS. Solution: new installation on xcp, bring old freepbx to identical version/versions (modules), use freepbx backup module, restore in new installation.

OK, it can be done. So your lost host/pool had some fancy named network device (let's say idrac). You don't have identical hardware. Solution:

• set up a virtualized XCP-NG with the same (more might work) number of NICs as your lost host
• access that host's console
• xe pif-list # find a NIC you don't need for metadata restore, let's say eth4
• xe pif-forget uuid=<that pif>
• xe network-list # find the network associated with the forgotten NIC
• xe network-destroy uuid=<that network>
• ip link set dev eth4 down
• ip link set dev eth4 name idrac
• ip link set dev idrac up
• ip link show # find idrac's mac
• xe pif-introduce host-uuid<your virtualized host> mac=<idrac's mac> device=idrac
• I think this automatically added a network named idrac to the pool - don't know if it's needed

Now you can add the virtualized host to XO and restore your metadata. Is this a good idea? I don't know. I did not test it any further.

I did restore the VMs from their backups (full backups, delta backups, online snapshots, offline snapshots, XOA, XO self compiled) - it worked flawlessly and it is very much good enough for me.

My post was just meant as a small contribution to a possible future solution to the problem. Larger environments might be interested in disaster-recovering metadata on non-identical hardware.

If there was some way to assign arbitrary names to virtual NICs, the "restore into a virtualized XCP-NG" approach would most likely work. Maybe this is a simple thing for you to implement - and thereby offer an even better DR solution to larger installations.

Hi,

I ran into the same problem when testing for disaster recovery.

• One possible solution I found when "ethX" is missing: set up an XCP-NG host as guest (nested virtualization) and assign it enough NICs. Then restore on the virtualized XCP-NG. This will at least allow you to restore.
• This however did not work for: In my testing environment the "dead" host (only host in pool) was a Dell with iDrac-passthrough enabled. The NIC's name was 'idrac' on that host.
• Restore seems to be name-sensitive for the NICs. I did not find a way to create a NIC named 'idrac' for a virtualized XCP-NG.

This behavior is described in this document, section "Physical Machine failure - To restore a pool with all hosts failed" with no solution given.