@olivierlambert deploying fresh copy worked and registered under different email. Thank you for assistance

A couple Windows 2016, and 2019, and a couple Rocky Linux 8 is what Im moving. I'll see if I have an 8.2 host suited (not too different CPU) to be a middle man. thanks.

Indeed, you are right and it's about to be fixed very soon. Thanks!

Okay so you deployed XOA, the turnkey VM with XO already installed in it. Are you sure you do not have an IP conflict? Make sure XOA IP is different than the host.

I had the same problem, I had to run the XenClean script and do a fresh install of 9.4.1 which resolved the issue. https://github.com/xcp-ng/win-pv-drivers/releases

Hi, This is perfectly normal. Only the master is the contact point for the entire pool. I would advise to go for manual promotion if you consider your host dead. To do it, go on any slave you want to promote (just one) and type xe pool-emergency-transition-to-master. If you use HA, this will be done automatically, but HA can be tricky. The result will be the same, if the master is down, you'll lose the view in XO about what's going on the pool, until you get a master back.

@olivierlambert Interesting, thanks.

I had a similar issue and found that after changing the static IP directly by editing the network config file inside the XOA VM, things worked fine, but I had to double-check routing afterward. I also ran a quick ip stress test with multiple devices to make sure the new config didn’t cause conflicts or drops on the network. Everything stayed stable after that.

And that's the reason why we planned to keep displaying "out of sync objects" in XO 6

@bleader you have it right. I was checking before I started down the path of writing something myself. We are a public entity that operates very similar to an MSP so we have a ton of VLANs. We're migrating from vCenter/ESXi and have always used powerCLI with powershell to perform these functions.

No no, don't worry, it shouldn't be that frustrating. That's why I want to check what do we have in the pipes in the future to make it easier.

UPDATE, Its FIXED! I downloaded XCP-NG Center and it was able to connect to Xen-1 and I was then able to change xenbr3 to DHCP instead of the static IP that was the same as xenbr0. No idea how a power hit may have caused this but doing that allowed XO to immediately connect. Much appreciate the assistance, I think it would have taken much longer to figure out if I didn't have the support!

@olivierlambert Thanks for the quick fix - update worked fine when I tried again, right after I wrote my post

@DustinB I advise you not to decide for others what they should do. I'm tired.

@BSmithITGuy Thanks for your information. The temporary workaround now is put Xen Orchestra to the same XCP-ng management network. Update 1: Diving deeper, I discovered that the API was changed the host management address (where the VM is located) to the backup address: https://github.com/vatesfr/xen-orchestra/blob/92932dd54645838db58ecfdd872895c5ad461608/packages/xen-api/index.mjs#L1010 async _setHostAddressInUrl(url, host) { ... url.hostname = await this._getHostBackupAddress(host) }

This message shouldn't appear if the license is properly activated. Since you have an active XOA trial, you should open an official ticket through the support portal and we can take a look at this for you.

Still, I remember we had a dedicated CLI tool to test it

@bleader said in Created a new bond interface and lost management connectivity to hosts: The original problem could be a known issue when creating bond including the management interface that we have to investigate. Although the emergency network reset should have fixed that, so maybe it is a mix of the bond creation issue and MTU issue. In the reinstalled pool, did you create the bonds already? If so I would think changing the MTU should be fine, especially as it worked on other PIF, but with MTU issue it is often quite sneaky, so I would not make any promises either. Yes I have recreated them, but I am not game enough yet to change the management interfaces to MTU 9000, though I have done on bridge interfaces for VMs, because I was losing ssh sessions, and this solved the issue. Also, the bonded storage interface is MTU 9000 no problem.

@ph7 Thanks for the tip! Appreciate it.