@Danp - thank you. Yes, I did, but that was not helping in this case. Found the solution: Both machines are on a hostserver, which has NOT all networks. So the real reason must be a network problem, therefore a quite missleading error message After moving both VMs to the master of this pool (which is connected to the same network where the xoa resides), everything went fine. Same storage, same vhds.

@darkbeldin Any additional idea, why this still happens after the suggested change? Many thanks!

@olivierlambert You are absolutely right: tags are enough. My fault. We will code some cronjobs that find the current SR, set the right tag and that's it. If the cronjob runs before the CR job is running, we should be fine. If you will implement the other idea: I guess (as you can specify only one backup target atm) an option to choose: 'store all vdis in target SR' or 'store only vdis from source SR in target SR' would be great, but if less work should be done: just store all vdis in the target SR - no matter where the source vdis are laying around Anyway: great work! Keep on!

Hi, Please open a support ticket so we can take a look remotely. In theory, just removing the SR should be enough.