Helped if i read the error message.... raise RuntimeError(f"{vm_type} {vm_uuid} is {power_state}, expected Halted; refusing to fix") Shut down vm ran the fix again, and fix applied. Edit - I did have to disable secure boot on windows vms for them to boot afterwards.

said in Unable to enable High Availability - INTERNAL_ERROR(Not_found): said in Unable to enable High Availability - INTERNAL_ERROR(Not_found): @psafont Would designating a new pool master do the same thing? I ran the above command and its had no effect Well, I tried changing the pool master and when VMHost11 was the master I was able to enable HA. Switching back to VMHost13 as the master now so will see how that goes Everything is working as expected/hoped. So for anyone reading through this and wants a TL;DR Issue was related to the pool master setting, changing the pool master to a different host and then back to the original fixed the incorrect settings allowing HA to be enabled

[image: 1762051714128-screenshot-2025-11-01-at-9.47.20%C3%A2-pm-resized.png] Weird it is not showing CPU temperatures, that was shown in the test command. (H13SRA-TF super micro board)

@olivierlambert Host started and issue resolved.

Thanks for the information. @Chico008, does the information at https://xcp-ng.org/blog/2025/10/30/xcp-ng-8-3-varstored-update-unbootable-vm-risk-and-remediation/ resolve the issue for you?

@Davidj-0 i'll ping back here whenever the app is ready to be tested will be MS O365 auth to access

@Andrew many thanks. As do I. See my OP. A failed build doesn't break XO. It leaves the previous successful build in place. My post wasn't to ask how to fix my problem, but to point out the issue to others who might care to know (see my last post). Cheers.

@Bastien-Nollet said in Full backup - new long-retention options: Yes, a backup is kept if it matches one of the retention criteria, either the schedule's retention or the LTR. (the backup is not duplicated, we just check for both criteria to know if we should keep the backup or not) Could we have an option to choose wich LTR day from month to keep ? and even for weekly, what weekday ?

@Cyrille is back next week

New version release ! A new patch version of the OME appliance is now available [image: 1761814461561-606721a0-e549-47b3-8b69-55d7b233d21f-image-resized.png] What I changed: Add xen-blkfront and xen-netfront driver Add guest tool (so RAM/network is reported, soft shutdown is working) /dev/sd* is replaced by /dev/xvd* Remove grub password Change admin and root password SSH is now enabled SElinux is working correctly DHCP is enabled by default As usual, please send a DM if you want the link to the vhd Feedback is welcome !

See https://docs.xen-orchestra.com/load_balancing

So first, it's not an XO issue, which helps to diagnose it. Then, it might be a subtle XCP-ng bug indeed.

@dinhngtu No, I haven't tried those. The host reboot appeared to fix the original issue and I had forgotten about them when I was troubleshooting the restart yesterday. I'll do a bit more playing around with this in a few days and report back.

Whelp had 2 of them get stuck, and one fail from the automated backup this time. The first one where it failed completely doesn't happen very often, so I'm less worried about it. Just including it in case it might be relevant. [image: 1761925465159-98feeae2-c301-4c92-bb33-bb4a029b0bc3-image.png]

@edsilber Yeah I'm not really sure, I also assumed that cron (and XO would use the cron pattern for months). Clearly it doesn't. Using AT on the CLI of your host/pool should work (I imagine). But yeah having a "Run Now" function in XO would be killer.

@rhkean I used an old laptop for my very first XCP-ng server and ran into similar problems. I plugged a $5 USB network adapter into the laptop and used wired networking. It let me get to the fun parts faster. If you want to get wifi working, keep us posted!

It's not the main "problem", and yes, XCP-ng 9.0 will use a far more recent kernel It's also a question of vendor partnership and so on. But as I said, we are working on it

Have you read the link I've sent? It explains exactly the reasons and answer your question You can imagine that if we have hundreds of 3rd party scripts, each doing their own way to install, it means we'll have to de facto support them all, despite it's unrelated to Xen Orchestra itself. Which means spending resources instead of working on Xen Orchestra directly (or fixing XO bugs). That's why it's preferable to open a ticket in the Github repo of the script creator, because that's exactly there you'll find the right answer, and also making sure the script creator could even fix their scripts if needed. If you need community support in here, you have to install it by following the official documentation: https://docs.xen-orchestra.com/installation#from-the-sources

@linuxmoose The guest Secure Boot situation needs some fixing from our end (see https://xcp-ng.org/blog/2025/10/30/xcp-ng-8-3-varstored-update-unbootable-vm-risk-and-remediation/ for context). I can produce for you a test update which resolves all known problems and makes guest Secure Boot work again if you wish.

@andSmv Thanks for taking a look at it. It's not really needed for a modern platform.