Two things, and the first is a correction to what I posted earlier. I was wrong about the memory option. I said your reasoning matched the docs, and it does, but the docs are wrong on this point. I checked with the backup team: we do not handle application consistency in backups at the moment, quiescing was removed, and restoring a domain controller from a RAM image can roll replicated state backwards and cause replication problems. Nobody would vouch for SQL Server either way. So "with memory" is not the safer choice for AD or SQL, and it may be the riskier one. That was my mistake, and you acted on it. On this morning's failure, the error is worth reading closely. VM_BAD_POWER_STATE(..., halted, suspended) means XAPI wanted the VM halted and found it suspended. That is the same mismatch you hit at the top of this thread with "Start a copy", except it is now breaking the delta job that ran fine for months before you added the CR. Two things would help pin it down: does it fail the same way tonight, and does the delta job succeed if you disable the CR job for a single run? If it does, that is a clean reproduction and worth a GitHub issue with this screenshot. @Team-XO-Backend, this one now has an XAPI error and a clear before and after, so it has moved past being a docs question.

Oopsie, I was wrong. I owe you a correction on the version, and that one is on me. I said 8.3 ships 9.2.18, but I was reading the spec file on the branch rather than what you actually get from the stable repo. Your yum check-update output answers it better than I did: stable leaves you on 9.2.16, and 9.2.18 only turns up once xcp-ng-linstor-testing is enabled. The screenshot in that same post is the part the still puzzles me. XO says "All good, patches up to date" while the module underneath is two point releases back, which I assume is what everyone else running XOSTOR sees too. If the connection-teardown fixes you found really are in 9.2.19, that is three releases of distance on the exact code path your traces land in, not the single bump I described.

@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.

My script is still able to fetch the master commit. [image: 1784801015866-screenshot_20260723_060314.png]

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

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

Thanks for the feedback @norpan , worth it! Ping @florent