@Greg_E Not sure what or why, but fresh install of everything in my lab has allowed a successful "standard" backup, I'll get into the other flavors when I have a chance as I build the lab back out. [image: 1745247353511-stuckbackup4.png]

@olivierlambert for what concern backup, I think you should ping @florent for XO-5...

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

Question for @lsouai-vates

@vkeven you can request a meeting with our sales teams, but technical discussion are better here if possible

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

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.