I don't know what's the /xen path? Install via this docker isn't the official/documented way, so it's hard to assist.

Please try to build it according the doc and double check if reverse work as documented too. Otherwise, it's an issue of the Docker you use with our doc, so you'll better time to create an issue on the 3rd party "installer".

It depends where you decided to install it (basically where you cloned to repo). Also remove the redis database if it's only used for XO.

@borzel I added a feature request here. ANy opinion or insight to help this feature along would be appreciated.
https://github.com/vatesfr/xen-orchestra/issues/4153

If you didn't, I strongly suggest that you watch the live YT webinar I did on XO backups. IIRC, there is a part talking about smart backup.

https://www.youtube.com/watch?v=FfUqIwT8KzI

You have a problem on your XCP-ng, this is not related to a XO issue. It's stuck doing a snapshot, which is really a basic operation that shouldn't fail at all.

Double check your SMlog on the host.

It looks like I can remove the remotes and set them up again, and configure the backup jobs to address the new share. That's okay, there are not too many.

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.

I was able to fix my issue by adding http to firewalld.

No XCP-ng/XenServer workaround, it's a "built-in"/by design limitation (it's considered as "stalled").

So your goal would be to avoid these extremely long tasks (ie: to finish before the task is destroyed)

You'll end up with a chain, yes (so every read will need to make "hops" on each member of the chain).

Longer the chain, slower the operation. But it shouldn't be too catastrophic either (for a heavily IOPS loaded VM, you'll notice the difference, but not in other less IOPS hungry scenarios)

The error I get when changing snapshot schedule is
delta-fail_1.png

Sure, thanks. I'm using xoa and desktop app simultaneously. I hope that the desktop app will be available for long time.

No, because those logs are useful in case of problem (to find a potential bug). However, they are garbage collected automatically (the oldest ones) after a while.

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.

@S-Pam Having a VIF for management and one for storage-traffic is a good solution, we do it that way to avoid crippling management during backups.

sorry mate - you are correct - will do

Any ideas for a more elegant way than to write a script? For my point of view vApps should work without HA mode but unfortunately it doesn't work on my XCP-ng server. Only console/script start of the vApp using

is working. But it is again rework for the next XCP-ng version, I think manually set vices in systemd are not persistent through an update. Will vApp supported also in future? there are some discussions about it, if really needed.

sorry for that
okay will change it