Thanks for coming back to close it out. That's useful to know. So I was plenty wrong, as it was the XOSTOR licensing backend rather than the repo side I guessed at; those -32000 errors really don't give much away. For anyone landing here later: sounds like -32000 on XOSTOR creation can come from either end, a licensing/entitlement issue that support sorts, or a host not reaching the package repo, so both are worth checking. @alcoralcor, did support get yours sorted too, or is yours still the repodata / repo-reachability one? Glad you're unblocked either way.

@laszlobortel We never reached a definitive root cause and did end up fully migrating to XCP-NG from VMware. We still have roughly 100 VMs running Rocky 8.10. The 4.18.0-553.94.1 kernels and above don't seem to have the same CPU issues but I'm not sure if that's because a kernel bug was mitigated or because we upgraded our backend storage to all flash arrays (Pure Storage C50's). The CPU still gets pegged on a Rocky 8 VM every once in a blue moon but not often enough to warrant more time being spent tracking it down.

@poddingue Since setting NBD=1, I have not seen the problem. SR is NFS on dual 40G ethernet with a TrueNAS scale 25.10 server using all NVMe SSD, so storage performance is as good as I can make it. I'll have to enable NBD=2 again to see if it still happens and if I can find the relevant part of the logs. As this is a random problem I can't recreate it on a normal test environment.

@poddingue I need to update a few things and then I plan on trying to see if this was fixed for me. I think I only had 2 Windows machines that were a problem, and only on machines that had a larger disk and were basically empty. The counting zeros seemed to lead to a time out. Just haven't had the time to look at much of anything lately.

Hi, IP conflict?

That leftover NIC is probably a stale PIF that XAPI is still holding, even though the card is physically gone, and the Refresh button re-scans rather than removing it. The docs have proper "remove a physical NIC" steps that end in forgetting the old PIF with xe pif-forget: https://docs.xcp-ng.org/networking/#remove-a-physical-nic. For the GPU side, the PCI passthrough flow (hiding the device from dom0, then assigning it) is here: https://docs.xcp-ng.org/compute#detaching-a-pci-device. If the GPU still won't show up as assignable once the stale PIF is gone, it might be worth a mention to @Team-Hypervisor-Kernel.

Closing the loop on this one — VSA-2026-021 went up yesterday (June 10) covering CIFSwitch / CVE-2026-46243: https://docs.vates.tech/security/advisories/2026/vates-sa-2026-021 A few things worth flagging for anyone following along: Severity landed at Moderate 🟠 — same ballpark as CopyFail/DirtyFrag, as Lucien anticipated. XCP-ng 8.3 and XOA both confirmed affected. XCP-ng 8.3 fix isn't in the main repo yet. The advisory notes there's a publicly available package with the fix, but it's not in the standard channel — Vates is asking people to reach out for the install procedure so you don't break future Rolling Pool Updates. So don't go hand-rolling the kernel commit yourself if you want to stay on the RPU path. XOA is already handled — fixed in Debian kernel 6.1.174-1, pushed via the unattended update mechanism. Just note the XOA VM needs a restart for it to take effect, and anything older than Debian 11/12 won't get the update and needs an OS upgrade first. Mitigation is unchanged from what we discussed: blacklist the cifs module if you're not using SMB-based SRs (which breaks SMB SRs, so only if you don't rely on them). Good turnaround given the disclosure-to-advisory window. Thanks again @LucienLassalle and the security team.

Pilow's right that moving a VM to another SR forces one full pass while the CBT bitmap is rebuilt; that part is expected. But your screenshot actually shows the likely culprit for the all-VMs-fall-back-to-full pattern: you have Purge snapshot data when using CBT enabled, and XO's incremental backup docs flag exactly that combination as a known issue where you can occasionally get unexpected fulls: https://docs.xen-orchestra.com/xo5/incremental_backups#known-issues. It might be worth running a few jobs with that toggle off to see if the deltas hold. It is a known rough edge on the CBT side, so following the central CBT feedback thread and maybe a nudge to @Team-XO-Backend wouldn't hurt.

Commit 1ba82 did change something. It transferred the VDI but then fails with the VDI_IN_USE on that particular machine. Regards, Marc