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

Good news that it sorted itself out. Both changes went in at once and the next run came back clean on the ADDS VMs too, so I don't think there's anything left to pin down here, and I'd rather say that than invent an explanation after the fact. Your question about the snapshot modes was the useful thing to come out of this thread. I went looking, they genuinely aren't documented anywhere, and that's written up on our side now If the fall back to a full ever comes back on the ADDS VMs specifically, that would deserve its own thread with the SMlog output @tjkreidl asked for, since nobody got to look at that part.

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

@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 Running delta backup with CBT to S3. NBD connections=1 Yes, NBD. No VHD only. Yes, NBD is enabled and working on all pool hosts. Yes, XO can access the network used for NBD. No, a default backup network as not been assigned. No more logs from journalctl. My normal large nightly delta backup to S3 ran and did not produce any new errors. So far, just the one error once.

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

@yannsionneau That's great to hear, I can't wait to see what it'll look like.

@olivierlambert I have a full Realtek 8125/8126/8127 update to replace the existing r8125 driver, as required to support newer chips. The new 8125 driver drops the 8126 support but you just install the 8126 if needed (requires newer 8125 driver to avoid module conflicts).

I got this running and when I set up a catalog and baseline the report tells me that it has nothing in the catalog. Is that because it doesn't understand XCP-ng or because my hardware is old enough that it has dropped out of the catalog? I have two PE R630 and one PE R730. I tried both the full default Dell catalog as well as the one that limits to BIOS and firmware updates.

Two PRs out of the lowest priority bug ever, that made my morning.

I have been in the Network Enterprise business for 28 years. I live in Virginia which is heavily populated with Data Centers and adding more all the time. However, we have quite a few customers especially municipalities which are saying NO to having anything hosted with cloud computing due to security and endless rising cost. We have been deploying xcp-ng in quite a few installations, on customer premise. I think VATES will find there is a whole other market in these areas they can reach. That being said, Thanks to VATES and all who have worked on solutions for this! It truly benefits everyone!

i think im seeing the same with fake cpu spikes. I started a second pool yesterday to patch and left it on over night. typically i just shut it down once done so the servers dont get too far behind patching. Under the pool stats im seeing spikes but under hosts nothing. It doesnt really bother me, but figure i add to the thread that im also seeing it. [image: 1784817154694-c75fecec-d618-4f05-a931-edea6bc6ecce-image-resized.jpeg] [image: 1784817189696-1b9ea5aa-d349-4ff8-af89-30a970d36fbb-image-resized.jpeg] [image: 1784817219194-0f579999-cd96-4216-a0d4-d637ea5febf1-image-resized.jpeg]

@john.c See this post - https://xcp-ng.org/forum/post/105564