Thanks for the reports and the detailed analysis. I'll make sure that the XOA team is notified.

So, as planned, I changed the snapshot to “normal” in the backup job and performed a forced shutdown on the replicated VMs. This morning, the job status is “successful,” but two VMs (both of which have the ADDS role—this may be a coincidence) are showing this warning: [image: 1784879446703-xcpng.png] The type is still delta despite the warning message. For alle the other VM, the backup seems ok.

@Jonathon I think @mathieu-l asked it you rebooted after installing drbd 9.2.18 from test repository. Your message sounds like you rebooted after installing 9.2.16 but not after applying the 9.2.18 update from test repository.

@ataxyanetwork , just checking in on this. No rush at all. Thanks!

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]

@anthoineb Thank you. We have now installed the required packages on all three hypervisors hosting the OpenSearch data VMs: blktap-3.55.5-6.7.xcpng8.3.x86_64 blktap-debuginfo-3.55.5-6.7.xcpng8.3.x86_64 devtoolset-11-gdb The debuginfo package was not exposed by our internal yum mirror metadata, but we found the exact matching RPM in the official XCP-ng 8.3 stable-updates repository. No services or hypervisors were restarted during the installation. Could you please provide the recommended gdb commands for attaching to the affected tapdisk process and inspecting the blkif ring? In particular, it would be helpful to know which structures, fields and threads should be captured. We plan to test the attach procedure manually on a healthy tapdisk first. After that, we can add a short pre-reboot diagnostic pause to our recovery controller so that the GDB data can be collected during the next occurrence before the VM is rebooted.

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