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

After a good sleep, I resolved half of my issue. I got my LSI Cards messed up, I accidentally hidan internal LSI3108 (Address 01:00.0) instead of the PCI Card LSI3008 (Address 05:00.0)... My Boot Drives run off of the internal card. From the fallback kernel, I was able to Modify /etc/grub-efi.cfg to remove the internal card form the hidden list. I now have a separate issue, but will make another post.