@Andrew many thanks. As do I. See my OP. A failed build doesn't break XO. It leaves the previous successful build in place. My post wasn't to ask how to fix my problem, but to point out the issue to others who might care to know (see my last post). Cheers.

This is an old thread, but I ran into this myself recently. While there is a link to deleting the entire XO configuration, I think I fixed it with a less drastic solution. Remember: I'm just a random dude on the internet posting dangerous commands to try. It worked for me, but your mileage might vary. I run Xen Orchestra in a container (Xen Orchestra, commit e8733 at the time of writing). So I got a command line in the container with: docker exec -it xoa bash Then I ran redis-cli to get a redis command prompt. I typed KEYS * to get a list of keys. One key I saw was: 7) xo:server_host:172.30.0.214". That's the IP of the host I was trying to join (the master of a single-host pool). So I ran: del xo:server_host:172.30.0.214 Then I restarted my container with docker restart xoa. After that, I was able to successfully add the host to Xen Orchestra. Maybe this will help someone else. It got me working again.

@pierrebrunet Are you aware if there is an official guide on how to use this with AzureAD ?

@jsox79 No I did not. Disclaimer - I inherited this FreePBX system and don't know a whole lot about it. Once I got it to boot, I tested by calling my cell from a desk phone and making a page, and both worked as expected so I'm considering everything to be working. Didn't realize re-registering modules was something I may have needed to do.

OK, thanks for the quick response

Bit of a necro-post, but we're mid migration of storage/VM hosts/pools. I have a single win11 VM that's UEFI (not secure boot). It runs just fine on our old 8.1 server that we're migrating off of. If I provision a new UEFI VM on the new pool and point it at the shared storage VHD, it refuses to boot with the same "The emulator required to run this VM..." error OP posted. I've tried restarting the toolstack and "updating the Secure Boot certs" on the host server. Any guidance very much welcomed, I was unaware that this VM wasn't booting on the new pool (the VM is off a lot of the time), and we're a couple weeks from this project completing (and the old server being WEEEd).

Ping @florent

Not with XOA then (yet). We might switch XOA to UEFI in the future for that. If you are using XO from the source, sure, you can do that

@lsouai-vates those look great! @Pilow hey I’m just happy that @olivierlambert officially 100% promised and fully committed to a December 2025 initial release of XO6 on the monthly blog

@olivierlambert The only thing I can think of from newer kernels is NFS options like nconnect=xx for hopefully more speed in the day to day range of duties. As of the pre-LTS, this still wasn't in 8.3. I haven't checked after LTS.

@bleader Hi, After a restart of the entire host, port 6640 is now listed when I trigger ss. But, unfortunatly, tunnels are not working, every VM on this host loose connection to other in the same sdn network. Exemple with an ping between two hosts : 2025-10-09T12:22:54.781Z|00026|tunnel(handler1)|WARN|receive tunnel port not found (arp,tun_id=0x1f1,tun_src=192.0.0.1,tun_dst=192.0.0.3,tun_ipv6_src=::,tun_ipv6_dst=::,tun_gbp_id=0,tun_gbp_flags=0,tun_tos=0,tun_ttl=64,tun_erspan_ver=0,gtpu_flags=0,gtpu_msgtype=0,tun_flags=key,in_port=33,vlan_tci=0x0000,dl_src=56:30:10:5c:4d:ad,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.10.10,arp_tpa=192.168.10.20,arp_op=1,arp_sha=56:30:10:5c:4d:ad,arp_tha=00:00:00:00:00:00) 2025-10-09T12:22:54.781Z|00027|ofproto_dpif_upcall(handler1)|INFO|Dropped 61 log messages in last 59 seconds (most recently, 1 seconds ago) due to excessive rate 2025-10-09T12:22:54.781Z|00028|ofproto_dpif_upcall(handler1)|INFO|received packet on unassociated datapath port 33 If I migrate the VM on the third host to another, network came back. This is very strange, because the network I've choose to test it is one of firt of all created, not last one, so it have worked before, and not now. I don't understand why and what to do...

Hi, As the message said, please reach out to us, you can use the contact form https://vates.tech/contact We'll be happy to discuss and assist in your evaluation

@tc-atwork thanks for post, i wasnt able to get xo6 setup as i havent had time to play with it. I look forward to when it released. For now I just keep using xo-lite to open the console window.

@MajorP93 stress of VM migration XD good luck with your V2Vs !

@vmpr hello, to be able to address the problem more clearly can you give me the version of your XO please? and if you are on stable or latest? XO v5.111.0 has been publicly released in latest channel yesterday.

@DustinB with Easyvirt integrated in the stack

The same issue was reported here, but seems its been fixed already. https://github.com/Jarli01/xenorchestra_installer/issues/137 nickali created this issue in Jarli01/xenorchestra_installer closed v6 build error: Scale is not exported by #137

Ah... so I missed the fix by one commit and two hours... I can confirm it resolve it. Thanks!

@hitechhillbilly Hi, For now the import tool does not use the proxy. Not that the full import tool also work from source if you need additional XOA , but we won't be able to connect to them for support

@Danp the issue is "resolved" only because we got the host back online so it released the lock. Yes I did try Start on which is method that produced the "The VDI is not available" error no the offline host was not the pool master Yes the VDI's are on shared iSCSI storage (truenas) And I want to note that OTHER VM's that were not on that failed host were able to restart and on any other node without an issue. I was even able to delete old snapshots without an issue so clearly the storage was online and available. It is deeply concerning that we were unable to get the VMs running again and only coincidental that were were able to re-seat the ram module and get it back online -- once it rejoined the pool the locked VM started without any issues on another host, so something was clearly locking it down even though it was fully stopped and visible.