That's great news, thanks, @christopher-petzel !

@mpiton Thanks for looking into this, I guess it wasn't apparent that I needed to click the Save Configuration button for that plugin. I did that and confirmed that the secret now survives an xo-server restart. Thanks again!

@poddingue Yes multipath is enabled and we have two target ips. When I scan the target it calls the sr.probeIscsiIqns method and return the iqns in the dropdown as *(ip,ip) and on the select of *(ip,ip) it calls sr.probeIscsiLuns method. Both method take time to return the response. 90+ LUNs will be listed in the Lun dropdown after 4-5 minutes. Then On selection of LUN with respect to the id it calls sr.probeIscsiExists to validate the LUN, this method also take 1-3 minutes. After all this on create button click if then calls a method sr.createIscsi . This takes too much time too. I have a pool of 3 hosts and all servers have verified connectives to the SAN Storage. If you need any information regarding this, I will be happy to share.

I measured this on a two-NIC 8.3 host. As far as I understand, there's no way to do it from XO: the call that edits a network doesn't take a bond mode, every bondMode in the codebase sits on a create path, and the REST API on a running XOA offers create_bonded_network plus get and delete on a network, with nothing that edits one. The CLI route looks cheap though. xe bond-set-mode on a live bond cost zero dropped packets in both directions I tried, pinging every 200ms across the change, and the command returned in about 1.4 seconds. Two caveats, and the second is about your case specifically: creating and destroying the bond did interrupt the host (roughly 8 and 16 seconds), and I only went active-backup to balance-slb and back, never touching lacp, because my switch port isn't configured as a LAG and I'd have dropped the box. So I can't tell you your lacp to active-backup move is free, only that mode changes in general didn't cost me anything. Worth putting on https://feedback.vates.tech either way so the votes have somewhere to gather.

I went digging and three threads turned up people who already have this hardware. @yeopil21 in https://xcp-ng.org/forum/topic/11799 had an LPe37102-D on a Dell R770 that never showed up at all, @jinju0504 in https://xcp-ng.org/forum/topic/11946 ended up on the -alt package on an R670, and @lukas in https://xcp-ng.org/forum/topic/8847 was running an LPe31002-M6-D with NVMe-oF back on 8.3 beta2. That last one is the older generation, so I'd guess it's the side where you most want to hear nothing regressed. Tagging them in case the cards are still on their benches.

@AtaxyaNetwork Merci pour tes recherches ! Oui "cd_label" serait cool comme ajout au plugin ce qui permet sur les distro type Fedora/Redhat de ne pas avoir de boot_command à gérer

No problem about the delay, of course. I put on better glasses, and guess what? There is a Container management section in the XO docs after all, in docs/xo5/manage_infrastructure.md. It doesn't describe the old xscontainer route though. It says you can run Docker inside a VM, then links out to Docker's own docs and the Kubernetes recipe, so there's no procedure sitting there to walk anyone into a wall, and no sign of the feature either. On the features matrix I can't check it the way I checked the rest, because the page builds itself in the browser and fetching it gives me nothing, so treat that one as unchecked rather than confirmed. The Feeder entry still isn't there, I looked again today, so that part stands.

Thanks, keep us posted!