@poddingue Thank you for the analysis. I'd give you a rep if I could

If the list is only complete after you've been through the Storage view first, that smells like the VM view not loading the whole SR collection, so the dialog only knows about the SR the disk already sits on. I could easily be wrong about the mechanism though. 6.7.0 went out on 30 July, so it would help to know whether it still does this there, and whether anyone else on 6.6.2 sees the same thing. Might be worth a mention to @Team-XO-Frontend, since they'd know straight away whether that dropdown is meant to come from a shared collection or get fetched per view. The nearest thing I found in the tracker is https://github.com/vatesfr/xen-orchestra/issues/7392, but that one is ISO SRs turning up in the wrong list rather than SRs going missing, so probably not the same thing.

Hello @mike.potapov , on n_reqs=32 and n_reqs_free=32, I think you're watching td_blktap_t structure. This structure is only used if the pvdriver are not install in the VM, so it's normal this ring is not used. You should watch struct td_xenblkif that is the ring use normally and that must contains 256 requests on max_order=3. The tapdisk will wakeup periodically, you could put a breakpoint on tapdisk_xenio_ctx_ring_event to confirm that the ring is check periodically. You can investigate td_xenblkif here. Ultimatly, you can try to send a notification from the tapdisk under gdb to the linux kernel with call (int)xenevtchn_notify(blkif->ctx->xce_handle, blkif->port); to see if it unlock something on the guest side. It it's the case it will confirm a notification was lost. If not you will get a message about spurious interrupt in the dmesg of the guest kernel.

Your xe host-list output kills my guess. All three addresses are real LAN IPs with nothing on loopback, so the loopback is probably coming from the XO side rather than from XAPI. I did test one thing: given a name that resolves to both families, Node reports connect ECONNREFUSED ::1:443 and connect ECONNREFUSED 127.0.0.1:443 together, which is what your log shows, while the literal 127.0.0.1 only ever names one address. That suggests something is handing XO a name rather than an IP, and localhost is the obvious candidate, so it's worth checking what you have registered for that pool under Settings then Servers, which is where the address comes from in the first place: https://docs.xen-orchestra.com/xo5/manage_infrastructure#add-a-host . The migration failure I'd keep separate for now, and could you paste the exact error XO gives when one fails? I don't know whether the two are the same problem and I'd rather have the text than keep making wild guesses.

@yllar said: @yannsionneau Hi, any news on the new iso? Hello @yllar In case you missed it, the ISO was released a few days ago: https://xcp-ng.org/blog/2026/08/14/xcp-ng-8-3-lts-refreshed-installation-isos/

For anyone who finds this in the future, I ran into a similar issue today when passing through a LSI Card, Coincidentally on Address 05:00.0, also coincidentally on a Supermicro Board (mine is X10DRH-CT, OPs was a X8DA8) I was originally writing a comment here to see if a solution had ever been found, but while taking/marking up screenshots of my Motherboards System Block Diagram, I discovered my problem... Human Error of course. Long story short, I added a PCI to 2xM.2 card, and in my BIOS, I bifurcated the wrong CPU/PCI Port. Instead of Bifurcating the M.2 Card, I accidentally Bifurcated the LSI Card, which caused the Unknown Header Error AND since there was an unknown header, the VM Would throw the "Device or Resource is busy" error when trying to start. Correcting the Bifurcation fixed the issue in my case. Not sure if that was the issue in OPs case, but this might help someone else who stumbles across this