Thanks for the feedback @mathiashedberg !

Thanks for the input @tony and @stormi. Turns out I've managed to get most of the machines back on the second node after getting some help to force it back to being the master and powering off dead VM's etc. so I think I've avoided having to do this. It is really useful info however, and I will probably give this a try at some point just so I can if I ever need too. Thanks again.

Yep.. that did it... started it on the older host, and can now migrate it backwards and forwards with on issues... Thanks Olive... as always. Peter.

@badrAZ Yep.. that did the trick.. All working now.. nice.

Thanks for the input. I'll give the ""'s a go. Portainer is interesting, have it running on the cores machine with ease alongside pihole. This is all starting to look interesting P.

OK, seems I wasn't trying hard enough. I was trying to mount the tools under the iso list, but when I look further down the list to xc-ng Tools it turns out I can mount the tools from there as long as I do it manually (mount /dev/sr0 /media/blahblah). Installed now, all good.

OK, thanks @fohdeesha that's really valuable information. Helps a lot. Peter.

Advanced tab of the VM view, "Start on…" button. Cross server private network will be a Xen Orchestra plugin for our next release.

See also https://xcp-ng.org/forum/post/21792

You need one XOA, connected to both pools. It will stream the VM content (delta) from the source to the destination. You don't need any directly link between your SR in both DCs. You DCs can be isolated with just one XOA connected to both, and it will work.

All I can tell is that's not an usual issue. Never heard of problem of this kind before… So yeah, there is something weird. Could be related to NFS permissions maybe, or something between XCP-ng and your NFS host. It's not XCP-ng code directly, because otherwise everyone else using NFS will endure the same problems. So it's more a "combo" between XCP-ng and your NFS within your infrastructure. Please read the wiki on where to check logs (especially SMlog) to spot potential hints on where's the issue.