@MathieuRA I disabled Traefik and reverted to my old XO config (port 443, ssl encryption, http to https redirection), rebuild the docker container using your branch and tested: it is working fine on my end now Thank you very much! I did not expect this to get fixed so fast!

Because doing an update without rebooting doesn't reload the updated main programs, like XAPI. A host in only updated after a full reboot.

@nikade This is not related to Dom0 RAM. It's related to the host RAM.

@Pilow error reporting is a feature in itself . Thanks

Yes!! Congrats for everyone (including you for the feedback @dcskinner !)

@vaewyn There is an emergency transition to new master xe command. Also, make sure all your hosts are properly time syncronized to each other or there can be pool issues. Try first: xe pool-designate-new-master host-uuid=<new-master-uuid> If that fails, you will need to run on the slave server: xe pool-emergency-transition-to-master

@benapetr Thanks, I will have to play with this when I have time.

@MathieuRA Thank you, perfect Br,

@Pilow I will take a look in deep later, but the key/delta and disk usage is set during backup, even if they are merged during LTR retention

Yay! Santa came early this year!!

@olivierlambert said in Xen Orchestra Node 24 compatibility: Can you reproduce the issue on XOA? Or it's only on the sources + your current OS? We do not have a XOA license (yet) which is why I am currently solely using XO from sources. Therefore currently not able to reproduce on XOA. OS is Debian 13.

@olivierlambert said in 2FA doesn't load graphics properly after XO6 went default (XO from source): Does it work OK without the proxy? Testing on my secondary lab, and the results are the same. Secondary lab runs privileged service, 443 without proxy.

@olivierlambert Thanks for the tip — it’s a very interesting mechanism. I’m going to read the docs now

@DwightHat No I did schedule a reboot of XO every morning and it seems it has worked because I "forgot" about it No idea if anyone have "fixed" anything

@hitechhillbilly no it doesn't, it just ensures the N-th vCPU of Dom0 only runs on N-th pCPU of the machine. Not sure about the practical impact of it, in the past it has been used for getting meaningful CPU temperatures from coretemp (with physical core matching virtual one), but that doesn't work anymore since Xen filters MSR accesses (including Dom0).

@MajorP93 Thanks for your feedback. I'll look into it over the christmas hollidays

@firereverie Sorry, these last few weeks was very-very busy. So I REALLY hope will do something on this before the december end and come back to you.

In case anyone wonders how this played out. At the end of the day, I shutdown the host with the running workloads on it, kept it at BIOS boot so the 8.3 installer would upgrade it cleanly, and then booted it back up. For reasons related to my particular setup, the down time was more than 60 minutes. But that's not related to XCP-ng. The XCP-ng installer was maybe 10 of that. 20 of that was 3 reboots on a server that takes ages to boot. One thing that is a bit difficult is that the 8.3 installer doesn't notice ZFS volumes or help with ZFS. So after the upgrade, I have to follow a modified set of these instructions (modified because the package names have changed over time) to install ZFS and its components into the system. So the sequence is: Shutdown Install via ISO Reboot to single user mode Run yum update to pull in all the updates Run the ZFS commands to install ZFS on the host Reboot again Run normally Of course, I ended up rebooting more than just those 2 times, because I forgot that I would need to install ZFS (even though I did it on 2 different hosts already ) So now the pool is fully upgraded, everybody is happy. I'm now working on creating shared storage across the nodes. It's amateur hour over here. I appreciate all the help.