XCP-ng 8.3 updates announcements and testing

gduperrey

@abudef In case of a shutdown, I turn off the secondary servers first. Once they are off, I shut down the primary server. This ensures that if the secondary servers have information to send to the primary, they can do so, whereas otherwise, they can wait to shut down.

In case of a pool reboot, I reboot the primary server first, and once it is accessible, I reboot the secondary servers.

abudef

@gduperrey Of course, the order matters. Now everything seems to be clear.

gduperrey

New security and maintenance update candidate for you to test!

A new security vulnerability, XSA-480, has been detected and fixed for xen.

Security updates

xen: A vulnerability has been discovered on x86 Intel systems with EPT support, where unintended host or guest memory regions can be accessed from a VM's memory cache under any workload. This can lead to privilege escalation, denial of service (DoS) attacks affecting the entire host, or information leaks.
On XCP-ng 8.3, x86 HVM/PVH VMs can leverage this vulnerability.
There are no mitigations.

A VSA was also published by our security team: https://docs.vates.tech/security/advisories/2026/vates-sa-2026-005/

Maintenance updates

We are taking this opportunity to release an update for ipmitool following some feedback from our users regarding the display of an error message in Xen-Orchestra, with certain models of DELL servers, in relation to the command ipmitool lan print.

Test on XCP-ng 8.3

yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates
yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates
reboot

The usual update rules apply: pool coordinator first, etc.

Versions:

ipmitool: 1.8.19-11.2.xcpng8.3
xen: 4.17.6-5.1.xcpng8.3

What to test

Normal use and anything else you want to test.

Test window before official release of the updates

~2 days

flakpyro

@gduperrey No issues to report on my test systems.

gduperrey

Thank you everyone for your tests and your feedback!

The updates are live now: https://xcp-ng.org/blog/2026/03/19/march-2026-security-updates-for-xcp-ng-8-3-lts/

manilx

@gduperrey reboot necessary?

stormi

@manilx Yes, as written

manilx

@stormi didn't see that (my old eyes)... guessed so anyway

acebmxer

@gduperrey

When applying updates at work. I started with first pool and choose the rolling pool updates and ran into issue after fist host came back up the second host didnt enter maintenance mode and the operation appeared to have just stopped. I then manually put host 2 in maintenance mode and applied updates. Once updates finished it restated the tool stack and took the host out of maintenance mode. I put it back into maintenance mode and rebooted the host. Once it came backup no migration occurred as expected to bring vms back to host2.

Moved on to pools 2 and 3 and just did everything manually. Each time load balance appears to be broken now just like home lab.

I have rebooted XOA deleted load balance config. rebuilt using different name and still no load balance.

Once manually migrated vms back over to second host in all three pools all seems ok.

gduperrey

@acebmxer Hello,

What you're describing sounds more like an RPU issue with Xen-Orchestra than a problem related to XCP-ng updates. But I could be wrong

However, since these updates affect Xen, a reboot was clearly indicated in our procedure. So a simple restart of the toolstack isn't enough. You did the right thing by rebooting afterward.

Are you using XO Appliance or from source?

If it's XO Appliance, you can open a ticket to ask for help analyzing the situation and see if anything in the logs or configuration explains this behavior.

If it's from source, for the same issue, I would suggest you start a separate thread on the forum so other users can help you with the analysis

In any case, it's great if your pool is working in the end