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.

Do you have any logs in the browser console or in XO server output? Maybe a parsing error

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

@olivierlambert Host started and issue resolved.

@dinhngtu Hi For my i made on offline Install to solve my issue, installed failed when downloading the kernel from servers, so offline install worked fine for me.

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

@Forza I started experimenting with this function in dec -24 and have run it in "production" in my homelab since jan -25 I suggest You keep the Backup retension (52) to 1. this is my setup [image: 1762170193505-e080cadf-7ad0-48e1-aac5-72bfbec88900-image.png] Sequence [image: 1762171293182-9a7ab8d6-057a-459e-b026-657580a47116-image.png] Schedules [image: 1762171204769-541c3859-b8bf-4230-bc49-871d1fdc0897-image.png] And this is the result from one of my VMs [image: 1762170304133-da4b3ef8-3abc-4663-b287-d87cbe98f152-image.png] [image: 1762170378949-e1040285-6f50-42c3-af90-052774bc8ecf-image.png] As You can see all the backups from jan - apr and most of may are removed I am waiting to see what will happen when we go into 2026, If I remember correctly,there was some bug at 2024 -> 2025 but hopefully I get my first yearly backup

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

@rhkean note we did not publish any build yet (there is code available, but I wouldn't advise anyone to jump on it yet )

@edsilber After exploring the UI, I confirmed that it's not possible to schedule a one-time cron job from the XO-5 interface. We're prioritizing the development of new features for XO-6, so we'll take your suggestions regarding scheduling into account for the new interface. I propose an alternative: using the REST API to run schedules by creating your own execution script (if you are on linux: https://www.veeble.com/kb/scheduling-one-time-jobs-in-linux-using-at-command/). The REST API link is: {your-xo-url}/rest/v0/docs/#/schedules Please feel free to contact me if you have any further questions.

@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

@ph7 that's fine, keep on testing our new XO-6, we are very concerned by our community feedback

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

What GPU do you have? I thought I read something about NVidia's newer stuff having vGPU without the expensive licensing and hardware. But it's possible I'm just conflating that with the increase in concurrent NVENC encodes. On the bright side, you can always get a cheap GPU and just do passthrough with it. I do that for my Jellyfin server with a 2060, it's very easy to do in XCP-ng now and works super reliably.

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

I think we have a lead, I've seen a discussion between @florent and @dinhngtu recently about that topic

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