@jgrafton said: @laszlobortel We concluded that older Linux kernels plus live migrations plus lvmohba storage seems to trigger the issue. Our workaround was to upgrade to a mainline 6.x kernel packaged by ElRepo https://elrepo.org/wiki/doku.php?id=start for Rocky 8 systems that were especially prone to the CPU hang. The kernel upgrades effectively stopped the issue from occurring. That's ultra helpful interesting @jgrafton Maybe it's even worth a KB/known issue in our official doc, let me ping @thomas-dkmt I suppose https://docs.xcp-ng.org/troubleshooting/common-problems/ might be the right place to document it.

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"

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

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

Good to hear, thanks a lot for your feedback.

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.

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.

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