@TrapoSAMA You can build XO from sources and have full access to all. You may use my script if you like - https://github.com/acebmxer/install_xen_orchestra

@florent I'm doing more backup runs. And not all of the VMs trigger the warning and fall back. But it seems quite random so far. I did one adjustment thoug. My number of NBD connections are set quite high, 20. And after reading this post I decided to try if lowering to 1 would have an effect. And it seems that it does. The latest backup-run hasn't showed any warnings this time... Maybe it's a false lead. But it is a behaviour I noticed this time

@acebmxer all good and thank you again for sharing your discovery on the forums

All hosts are restarted with 9.2.18 loaded now. Will see what happens next. [15:56 ovbh-pprod-xen05 ~]# drbdadm --version DRBDADM_BUILDTAG=GIT-hash:\ 71c8bcff6ea77a022b272a7eba649a774251bac4\ build\ by\ @buildsystem\,\ 2025-11-03\ 10:21:36 DRBDADM_API_VERSION=2 DRBD_KERNEL_VERSION_CODE=0x090212 DRBD_KERNEL_VERSION=9.2.18 DRBDADM_VERSION_CODE=0x092100 DRBDADM_VERSION=9.33.0

Hello @anthoineb, Thank you. I have attached the requested evidence as separate text files because the forum does not accept ZIP archives: two complete GDB/tap-ctl captures taken during the same incident, before reboot; the corresponding daemon.log excerpt from the hypervisor; the corresponding SMlog excerpt from the hypervisor; a README containing the timeline and identifiers; SHA-256 checksums. Both host-log excerpts cover 2026-07-25 04:35:00-05:10:00 MSK (UTC+03:00). The first GDB capture started at 04:45:44, the independent repeat capture started at 04:48:03, and the forced VM reboot was requested at 04:58:33. Both captures show the same state: the tapdisk main thread was in scheduler_wait_for_events(); n_reqs=32 and n_reqs_free=32; req_prod=req_cons=rsp_prod=rsp_prod_pvt=0; tap-ctl reported reqs_outstanding=0; the guest still reported 31 requests in flight and all 32 blkfront tags busy. The host logs contain no tapdisk error before the reboot. At 04:58:34-04:58:36 they show the expected sring disconnect, tapdisk close/detach and clean shutdown after the forced reboot request. The new QCOW2 tapdisk was opened at 04:59:57 and its sring connected at 05:00:27. Please let me know if you need another structure printed from GDB or a wider host-log interval. Our recovery controller can preserve the same pre-reboot diagnostic window during the next occurrence. SHA256SUMS.txt README.txt osott-193-SMlog-20260725-0435-0510.txt osott-193-daemon-20260725-0435-0510.txt 20260725-044732-gdb-172.30.52.193.txt 20260725-044544-gdb-172.30.52.193.txt