@olivierlambert Thank you for the quick response. I concur there may be additional Azure platform issues to check, and I am working on that now. I am a certified Azure Cloud Architect.

I can tell you that I was able to install the XCP-ng image on a local Hyper-V instance on Windows 11 and it looks to be operating normally. On my first attempt I set the XCP-ng management interface as DHCP, but I found that the gateway did not update after moving to Azure. On the next attempt I changed the local Hyper-V subnet to match the destination Azure one, but after the machine booted I was still unable to get connectivity.

I do wonder if it would help to get the Linux Integration Services for Hyper-V loaded on XCP-ng, but I have been unable to load Linux headers to make the install for the drivers. Microsoft says they support RHEL/CentOS, but until I see it work or fail myself, it's hard to know for sure.

Thanks Again.

Hello All,

The company I work for has been migrating our MSP hosting business from our private data center to Azure. At the same time, we are also migrating our corporate resources from VMWare to XCP-ng. Historically we used Veeam to backup VMs to a local storage and then replicate critical servers to Azure Blob storage and we were able to use Veeam to restore those backups to Azure VMs for DR purposes.

Since XO has a built-in backup solution, we have been using that and I have found a method to create an SMB SR on Azure Blob so we can also have offsite backups, but we are missing the last step of the ability to restore as Azure VMs. We are storing the backups as multiple data blocks and encrypted, not in single VHD format.

I had an idea to see if I could install an XOA image as an Azure VM to read the backups, and that worked like a charm (XO from sources on top of Debian). What I would like to do now is create one or more XCP-ng Azure VMs and connect them to the XOA and then run nested virtualization for DR. Azure does support nested virtualization on specific VM SKUs.

Where I am running into resistance so far is after prepping the XCP-ng image and creating a VM on Azure, there is no network connectivity, and the console access is not functional yet. I have reviewed the guides to prep a Linux VM for Azure use, but I'm struggling with getting the correct distro commands to set the console port properly, etc. I also believe the XCP-ng kernel would not include drivers for Hyper-V and I am also having a challenge getting that sorted out as well.

Has anyone tried this or am I barking up a fruitless tree and would be better suited to work out another solution? Any feedback is welcome. Cheers!

@icecoke Got it. I worked through the steps and found where I transposed one of the variables incorrectly. I was able to complete all the steps and the VM is booting now as expected. Thanks again.

@icecoke Thank you.

I do have an added complication. This disk resides on an XOSTOR SR. Also, when gathering the VDIUSERDEVICE I get the following error:

"The uuid you supplied was invalid."

Is the VBDUUID parameter a typo of VDIUUID? Otherwise I don't see a command to obtain the VBDUUID for this step:
"VDIUSERDEVICE = xe vbd-param-get param-name=userdevice uuid=VBDUUID"

@DustinB Sure thing.

Yes, XCCP-ng 8.3 while applying the latest round on 3/12/25, kept up to date prior.
XOA Premium, version 5.103.1.
Guest was Windows Server 2019 Standard with XenServer VM Tools version 9.3.3.

I ran across this issue today and thought I would share as I didn't find any immediate results when looking for a solution. I had a VM that was in an unhealthy state where RDP would not connect and the console tab in XOA was blank.

I was in the process of applying updates to the pool and also could not migrate this VM to a different host. I proceeded to install the patches and this VM went offline during the updates after the toolstack restarted.

I tried to boot the VM on the host I had wanted to move it to and got the "SR_BACKEND_FAILURE_46 The VDI is not available not detached cleanly" error. I then tried to just boot the VM with the same result.

The fix was to boot the VM on the original host it had been running on before the shutdown. Hope this helps.