@manilx we will consider it in XO-6 to improve the backup view, thanks for you reply

Question for @lsouai-vates

We ran into the same issue as well. We removed ALL snapshots of this vm and then it started working again. Comes at a cost since we had to remove the non-backup-related snapshots as well...

Great! Enjoy

Hi @florent Here is the log. https://drive.google.com/file/d/1y3bPuyQPfYKHH54mIniyHBZ9Mloqjeec/view?usp=share_link Thanks!

Ping @thomas-dkmt

Hi, This error comes directly from XAPI (XCP-ng) and not from XO. Sadly, XAPI doesn't give much details…

@thomas-wood "Remotes" are for XO backups and SR are for VM Storage. Once you add a SR to a pool it's available to all hosts. Also, all hosts should be able to access the IP of the NFS server before setting that up. I have a video explaining storage in XCP-ng here: https://youtu.be/xTo1F3LUhbE?si=QHYkABgElsEVOj6H

This is not a backup but a replication

Ping @lsouai-vates

@Danp Thanks for your response. I already tried those steps but the problem is that I am getting authorisation error. [17:17 xcp-ng-2 ~]# iscsiadm -m session tcp: [10] 10.204.228.100:3260,1026 iqn.1992-08.com.netapp:sn.302cea4af64811ec84d9d039ea3ae4de:vs.5 (non-flash) tcp: [7] 10.204.228.101:3260,1027 iqn.1992-08.com.netapp:sn.302cea4af64811ec84d9d039ea3ae4de:vs.5 (non-flash) tcp: [8] 10.204.228.103:3260,1029 iqn.1992-08.com.netapp:sn.302cea4af64811ec84d9d039ea3ae4de:vs.5 (non-flash) tcp: [9] 10.204.228.102:3260,1028 iqn.1992-08.com.netapp:sn.302cea4af64811ec84d9d039ea3ae4de:vs.5 (non-flash) Not sure why its giving authetication error [17:18 xcp-ng-2 ~]# iscsiadm -m discovery -t sendtargets -p 10.204.228.100 iscsiadm: Login failed to authenticate with target iscsiadm: discovery login to 10.204.228.100 rejected: initiator failed authorization iscsiadm: Could not perform SendTargets discovery: iSCSI login failed due to authorization failure [17:18 xcp-ng-2 ~]# If iscsi daemon has logged out then how I am able to access the VMs? If iscsi daemon has logged out then how I am able to migrate VM from one xcp-ng node to another? For migration and accessing VM, xcp-ng should be able to communicate SR, right? However, I tried restart iscsi service in one of the xcp-ng node on which 2 VMs were there. One on local storage of the xcp-ng and another on the SR. When I restarted the iscsid service and logged out and logged in to the storage, login failed giving authorisation error (not sure why it gave error, strange) and then both the VMs alongwith the xcp-ng node rebooted automatically Once xcp-ng node came up, iscsi daemon automatically logged in to the storage. I am not sure what to do in this case. Your support is much appreciated.

Hi, It's not supported because you have a PCI device attached, so memory snapshot aren't supported, because this cause crash on resuming it while the PCI device had another context in the meantime. Offline means the VM will be shutdown, snap then started. edit: "In memory" is like a live migration, so not compatible with PCI passthrough

@tjkreidl said in Issue with SR and coalesce: @nikade Am wondering still if one of the hosts isn't connected to that SR properly. Re-creating teh SR from scratch would do the trick, but a lot of work shuffling all the VMs to different SR storage. Might be worth it, of course, if it fixes the issue. Yeah maybe, but I think there would be some kind of indication in XO if the SR wasn't properly mounted on one of the hosts. Lets see what happends, its weird indeed that its not shown.

@ph7 Thanks for the help...I think that gets me close. I will tinker with it some more. Thanks again for the answers.

@ph7 Yep, that's what I've done. Actually, I've powered off the prior XOA instance. Not ideal, but a workable solution.

@olivierlambert - I'm not sure who would be the best person at Vates to ping or whether there is another channel I should be using to request enhancements. I'm happy to be directed to the correct place if that's not here. Despite the fact that I brought this upon myself... I do think that it would be nice if Xen Orchestra could improve the error handling/messaging for situations where a task fails due to an invalid object UUID. It seems like the UI is already making a simple XAPI call to lookup the name-label of the SR, which, upon failure results in the schedule where an invalid/unknown UUID is configured displaying the invalid/unknown UUID in Red text with a red triangle.

@DustinB OK. I think I'm between a rock and a hard place! Thanks for the advice.

@jshiells i believe this is by design for a mirror backup. it checks every vm to mirror (if no filter is selected that will be all on the SR), if there is no new recovery point it will not copy anything as it allready does have the latest version of that backup on the destination recovery point. When a filter is selected it checks every vm on the sr but it does not copy data.