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

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

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

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.

@tuxen Doing some research, it doesn't look like the Xeon's I have are affected. But I'm willing to try the next time I need to reboot. Will report back after that.

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"

Hello, Thanks for all !

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.

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

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

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