XCP-ng 8.3 updates announcements and testing

rzr

We pushed the tested updates to the xcp-ng-updates repository, check blog post for summary and related advisories:
https://xcp-ng.org/blog/2026/06/02/june-2026-updates-1-for-xcp-ng-8-3-lts/

Thank you again for feedback we will try to address reported issues on next batch (to come soon).

Note that some issues are not related to this specific update batch, but might have been introduced on previous ones (TBC).

stormi

@Andrew We'll publish a fix for bind-utils, indeed, even if it's not part of the officially supported additional packages for XCP-ng, as it can be useful and we don't have strong reasons not to fix it.

Regarding other packages affected by the openssl update, @rzr handled many of them as part of the OpenSSL update back then already, so now we'll mostly rely on reports such as yours in case we missed something which is actually used by the user community.

stormi

@rzr said:

Thank you again for feedback we will try to address reported issues on next batch (to come soon).

Note that some issues are not related to this specific update batch, but might have been introduced on previous ones (TBC).

Not knowing myself what it meant, I asked Philippe: it's about the nslookup issue. And potentially the issue reported by @ph7 but it's not clear to me yet if there was a problem with XCP-ng or Xen Orchestra.

Anyway, basically this means that there's no known issue caused by this batch of updates, and that we'll keep addressing any relevant issue in the next updates if necessary, as usual.

acebmxer

Applied patches at work. 3 pools updated with zero issues.

marcoi

latest patches, host1 /master patches went well and rebooted. moved vms over.
host 2 in pool click on patch and it just sat there.

i ssh into the host2 yum clean metadata and yum update manually applied updates.
XO still showed host 2 needing patching, so i reboot it. XO still showed host 2 need patches.
I rebooted XO. host 2 shows patch, and task still remains in XO. Any idea how to clear it out from XO. or is it wait 24 hours kinds of thing?

rzr

@marcoi said:

i ssh into the host2 yum clean metadata and yum update manually applied updates.

Did you try to reboot it just after ?

XO still showed host 2 needing patching, so i reboot it

Seems not.

What about rebooting the host too ?

Let me pass the world to @Team-XO-Backend

MathieuRA

Hi @rzr,
When you say, "XO still showed host 2 needing patching", does that mean XO is still showing missing patches?

If so, can you run the following command: xe host-call-plugin host-uuid=<uuid-host2> plugin=updater.py fn=check_update

marcoi

after i manually applied the patches, i used XO to reboot the host 2.
After the host 2 rebooted, XO still showed the task running and the host2 showed it needed to be patched. I rebooted XO and the task is still there ( been there for 13 hours now lol. ) but now host 2 shows patched

Pilow

@marcoi perhaps a restart toolstack would correct the phantom task ?
but at the end of patching of the master a restart toolstack should have happened already, automatically...

rzr

New security update candidates for XCP-ng 8.3 LTS (kernel)

This release batch contains security fix on kernel, version update, some bug fixes and a few improvements.

What changed

Virtualization & System

kernel: Fix Vulnerability: CVE-2026-46243
- Fixed the CIFSwitch security vulnerability that could allow privilege escalation from a user with low privileges.
intel-microcode: Fix a hang on boot on some platforms (Revert Granite Rapids AP/SP ucode back to IPU 2026.1)

Drivers

intel-ice: Update to 2.4.5
- Adds support for E825-C and E830.
- Adds support for Link Aggregation (LAG).
- Various stability, performance, and bug-fix updates.

Versions:

intel-ice: 1.15.5-2.xcpng8.3 -> 2.4.5-8.1.1.xcpng8.3
intel-microcode: 20260416-1.xcpng8.3 -> 20260416-2.xcpng8.3
kernel: 4.19.19-8.0.46.5.xcpng8.3 -> 4.19.19-8.0.46.6.xcpng8.3

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.

What to test

As usual, normal use and anything else you want to test.

Test window before official release of the updates

~3 days

We would like to thank users who reported feedback since our last call for testing:

@Andrew, @acebmxer, @flakpyro, @jeffberntsen, @majorp93, @marcoi, @ph7, @pilow, @probain.