Developers of Xen Orchestra
@k_hamilton The issue is that XO tries to store some config in ${HOME}/.config/xo-server and the setting user=username does not set the home to the specified user.
You can work-around this by explicitly setting the $HOME var when starting xo-server.
@joearnon It means that there is already another job working on this VM at the same time.
@notscottsmith So apparently, the old protocol also adds x/ipv4/x fields with space-delimited IPs. That's what causing the issue, so we'll have to handle them too. Thanks!
@notscottsmith Ok, could you run this inside XO's directory with the VM's host and its password:
./packages/xen-api/dist/cli.js --au <HOST> root <HOST ROOT PASSWORD>
It should start a CLI. And then run this with the VM's UUID:
> find({ uuid: '<VM UUID>' }).$guest_metrics.networks
@olivierlambert Most likely, yes. But it shouldn't be an issue anymore after this change (XO 5.60) so I don't understand why the error is still happening.
@notscottsmith Do you see those space-delimited IPs in the UI too?
@zevgeny Detached backups are backup files present on remotes but not related to any existing backup jobs or schedules.
Restoring the XO config in the new install should properly recreate the backup jobs and avoid this issue.
@bazzacad The replicated VM has its start operation blocked which means that it cannot automatically power-on.
But, if you force started this replicated VM via XO, it removed the blockage and now the VM will automatically power-on.
Hello @Zevgeny .
Finally, we won't be able to display if the vm has changed since the snapshot.
That should not be the case as the replicated VMs have their start operation blocked 
What version of XCP-ng are running on this secondary host?