Hi @pierrebrunet With commit c74a8 the problem is still present but the transfer was completed again. Unfortunately my installation does not recognize the "xen-bugtool" command. And both log files are not present. Is this something that needs enabling after install of XCP-NG? Unfortunately and unnoticed my syslog-server did not receive any messages from XCP-NG in the last 30 days. Other inputs work **Edit: I have deleted and re-added the syslog-server with port and now logs are being send to Graylog.** Thanks for your assistance y'all. Regards, Marc

IIUC, the Smart Reboot option found on the host's Advanced tab does what you are asking. [image: 1782309061091-3f858853-fe5c-4cd0-95c2-ce39859dedce-image.jpeg]

@jul1an [image: 1782285080688-2026-06-24_101114.jpg] [image: 1782285186489-2026-06-24_101302.jpg] I am using a translator because my English is limited. I have 5 identical servers equipped with Adaptec 6805 controllers. Previously, I bypassed the controller issues by using an alternative kernel, but that triggered network problems—specifically, network bonding is unstable on the alt-kernel.I have tested your evaluation image, but unfortunately, it did not resolve the issue. Later today, after my work shift, I will provide the logs and output from dmesg.I am ready to fully cooperate to fix this and can even arrange remote access via IPMI if needed.

Here is the log from when xen04 last crashed xen04-jun12-journalctl-crash-summary.txt

@Pilow pretty much

@olivierlambert said: I'm not sure it's a great idea, because even 64 hosts is huge in terms of VMs and fallout if you have a problem on your pool DB. Even if you drastically improve the current mechanism, the impact of a problem pool wide is far bigger with 64 hosts than 24 for example. It's more than purely tech, it's also a tech design/choice. Exactly, the failure domain just grows exponentially when going beyond a certain collective pool size. I was doing some more research and I found a few possible choices that Tesco may have moved too, but don't want to detract from this forum here.

@AlexanderK you could try to install perl-interpreter manually maybe? I happened to have a test host at hand that hasn't been updated since december, and the yum update went fine, perl interpreter was not installed before and yum update did install it on its own as a depency for openssl 3. Maybe others will have ideas as to why this would happen in your case.

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

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.

@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