Hello, Thanks for all !

@laszlobortel Hehe yeah, those are pretty old kernels. I'd say there's a good chance kernel upgrades will go a long way to alleviating the CPU hangs. I can't say it's exclusively a problem with lvmohba storage, that's just what we use because of our previous VMware infrastructure was block storage over fiber channel. We knew a physical infra overhaul wasn't in the cards for us for this migration so we stayed with our existing storage system. This bug bit us half way through the migration until we figured out upgrading the kernel generally fixed it.

@psafont Thanks for the quick response and clarification. I appreciate you opening a work item for this. Looking forward to seeing this improvement in a future release.

For people running XCP-ng, wanting to use NUT client to power down gracefully during longer power outages, it could be interesting to note that Unifi now has two very affordable UPS models that feature a built in NUT server. So no need to run your own NUT server.

Hi, XCP-ng got an event system that will propagate things like this instantly, at least that's the way it works normally Do you have the same behaviour in Xen Orchestra? Have you reported the issue to CloudStack? If you have an XCP-ng support subscription, you can also open a ticket so we can take a look on XCP-ng status to catch any obvious issue.

Quick Update: Was looking good with commit cf26d. After the transfer completed the VDI of that particular VM was still in use, according to XO. So still failure on the job. Regards, Marc

Wearing my best Lazarus cosplay outfit, I'll apologise for the resurrection. Today I had an issue with my UPS which caused me to reboot XCP a few times. During those reboots I had at least 2, maybe 3, re-occurrences of this where when TrueNAS was booting, XCP would lock up. Most of the time, after a power cycle of the server, the next boot would start TRUENAS cleanly. One time it took 2 power cycles before success. Unfortunately only one of the crashes resulted in a /var/crash report, but that did have the same symptoms as my original report: (XEN) [ 81.101362] Non-responding CPUs: {24-47} (XEN) [ 81.101363] (XEN) [ 81.101364] **************************************** (XEN) [ 81.101365] Panic on CPU 5: (XEN) [ 81.101366] FATAL TRAP: vec 2, NMI[0000] IN INTERRUPT CONTEXT (XEN) [ 81.101366] **************************************** (XEN) [ 81.101367] (XEN) [ 81.101368] Reboot in five seconds... (XEN) [ 81.101369] Executing kexec image on cpu5 (XEN) [ 82.101441] Failed to shoot down CPUs {24-47} Between my original report and today, I have rebooted other times, following updates, when this issue has not surfaced. Does anyone think this could be hardware related, despite all the memory testing and stress testing I did when I built the server and again after the original issue, all with no faults. Or have I just got an unlucky set of circumstances with some sort of race condition.

@TrapoSAMA https://updates.xcp-ng.org/isos/8.2/ And https://updates.xcp-ng.org/8/8.2/ appears fine.

The same as @john.c and also XO Lite tends to be less a priority because less critical than the full fledged XO (the priority is to replace entirely XO 5 in the next releases). Why you would need XO Lite outside basic actions? It's mostly meant to bootstrap XO itself and do basic operations (which is already the case, at least with many basic features already). Initially, the goal hasn't moved: replacing XenCenter. We are moving in that direction, but again, I think it's more important to get XO 6 finished first. I'm curious to understand more the use case of XO Lite in your context @unreal-shizzle ?

The rule is oddly written, and may conflict with another similar one that already exist in the distro (hence may not be useful to begin with). The modern generic rule for doing vCPU hotplug is, which would be preferable to the current z10-xen-vcpu-hotplug.rules. ACTION=="add", SUBSYSTEM=="cpu", ATTR{online}=="0", ATTR{online}="1"

@pierrebrunet ticket created https://help.vates.tech/#ticket/zoom/59723

Good to hear, thanks a lot for your feedback.

@poddingue My colleage managed to workaround the issue by re-installing the lab on other hardware, I think it is now Cisco UCS-servers. It was HP ProLiant-servers before. Maybe it was an issue with some of the NIC or firmware, im not really sure, but it works now.

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.

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

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.