We pushed the tested packages (of 3 batches) to the xcp-ng-updates repository, check blog post for summary and related advisories:

https://xcp-ng.org/blog/2026/06/23/june-2026-updates-2-for-xcp-ng-8-3-lts/

Thanks everyone for the tests!

New maintenance update candidates for XCP-ng 8.3 LTS

This release batch contains fixes, and a security fix on an optional package,

Note: the two previous batches of updates has not been released yet, so if you haven't tested it, you will see more updates than described here when you'll install the update candidates. Refer to the previous announcements.

What changed

Virtualization & System

• kexec-tools: Update to sync with Xen Server:
  • Add checks to reboot a crashed host if kernel crash handling doesn't complete.

Control Plane

• xapi: Fix the VM revert regression introduced in earlier "testing" version.

Optional package

• lldpd: Fix CVE-2026-46433, a buffer over-read when processing the "VLAN tags" from an Ethernet frame.

Versions

• kexec-tools: 2.0.15-20.1.xcp-ng8.3 -> kexec-tools-2.0.15-21.1.xcpng8.3
• xapi: 26.1.11-1.1.xcpng8.3 -> xapi-26.1.11-1.2.xcpng8.3

Optional packages:

• lldpd: 1.0.4-1.1.xcpng8.3 -> 1.0.4-1.2.xcpng8.3

Test on XCP-ng 8.3

Warning: XOSTOR users, refer to the instructions in the previous announcement, which apply here if you haven't installed the previous update candidates.

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

~2 days

We would like to thank users who reported feedback since our last call for testing:
@Andrew, @ScarfAntennae, @XCP-ng-JustGreat, @acebmxer, @bufanda, @flakpyro

@JeffBerntsen said:

@rzr

I'm seeing 30 updates as well but they're installed and seem to be working fine on my test systems.

I think I only listed sources packages (which contains several binaries sub-packages having the same versions), so that's expected

BTW thank you for reactivity on testing

New security update candidates for XCP-ng 8.3 LTS (kernel, xen, intel-microcode)

This release batch contains security fix on kernel, version updates, some bug fixes.

What changed

Virtualization & System

• kernel: Update to 4.19.19-8.0.46.3
  • Fixes CVE-2026-43284 (used by the DirtyFrag and CopyFail2 exploits)
• intel-microcode: Update to 20260416-1
  • Improve Intel support and security INTEL-SA-01420
• xen: Update to 4.17.6-8.1
  • Minor bugfixes for x86 systems, including calibration of various timers and handling of PCI devices when disabling SR-IOV

Control plane

• xapi: Update to 26.1.4
  • Minor NUMA fixes

UI

• xo-lite: Update to 0.21.0
  • chore: upgrade dependencies with known security vulnerabilities (#9640)
    • These vulnerabilities are not believed to affect XO Lite itself. They are fixed as defence-in-depth.
  • Changelog

Versions:

• gpumon: 24.1.0-83.2.xcpng8.3 -> 24.1.0-84.1.xcpng8.3
• intel-microcode: 20260115-1.xcpng8.3 -> 20260416-1.xcpng8.3
• kernel: 4.19.19-8.0.46.2.xcpng8.3 -> 4.19.19-8.0.46.3.xcpng8.3
• xapi: 26.1.3-1.10.xcpng8.3 -> 26.1.4-3.1.xcpng8.3
• xcp-featured: 1.1.8-6.xcpng8.3 -> 1.2.1-1.xcpng8.3
• xen: 4.17.6-6.2.xcpng8.3 -> 4.17.6-8.1.xcpng8.3
• xo-lite: 0.20.0-1.xcpng8.3 -> 0.21.0-1.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

~1 day

We would like to thank users who reported feedback since our last call for testing:
@Andrew, @FritzGerald, @IgorGlock, @bufanda, @flakpyro, @manilx, @marcoi, @ovicz, @ph7.

Feature fixes, security and maintenance update candidates for you to test!

This release batch contains fixes on the major storage feature previously announced,
read the RC2 announcement for QCOW2 image format support for 2TiB+ images.

The whole platform has been hardened with back-porting security patches from the latest version of OpenSSH.

An additional driver fix is part of this minor package set.

What changed

Storage

QCOW2 image format support is the major feature of this release batch,
check related announcement in forum.

Some fixes have been applied to fix issues found during the testing phase. Many thanks go to @Andrew who found a CBT-related bug on file-based SRs!

• sm: 3.2.12-17.5
  • Fix a regression on CBT (Changed block tracking) on file-based SRs (EXT, NFS, ...), causing backup jobs using the "purge snapshot data when using CBT" option to create full backups each time instead of deltas.
  • Deactivate unused LVM snapshot base before deletion to prevent LVM leak. This fix is not related to the QCOW2 feature, but is important and localized enough for us to provide it in addition the other changes.
  • Minor fix that prevents a warning when updating the package.
• blktap: 3.55.5-6.5
  • Fix install warning when triggering mdadm to generate a udev rule.

Network

• openssh: Update to 9.8p1-1.2.3
  • Two vulnerabilities disclosed along with the OpenSSH 10.3 release have been fixed.
    • In authorized_keys, when principals="" was defined along with a CA with a common CA, an interpretation error occurred, which could lead to unauthorized access.
    • When one ECDSA algorithm was active, it activated all others regardless of their configuration. (By default, all ECDSA algorithms are active.)
  • For more details please track the upcoming Vates Security Advisories.

Drivers updates

More information about drivers and current versions is maintained on the drivers wiki page.

• qlogic-fastlinq-alt: 8.74.6.0-1
  • Fixes 2 issues in the qede module driver:
    • Driver does not retain configured MAC and MTU post reset recovery
    • Driver does not recover from TX timeout error

Versions:

• blktap: 3.55.5-6.4.xcpng8.3 -> 3.55.5-6.5.xcpng8.3
• openssh: 9.8p1-1.2.2.xcpng8.3 -> 9.8p1-1.2.3.xcpng8.3
• sm: 3.2.12-17.2.xcpng8.3 -> 3.2.12-17.5.xcpng8.3

Optional packages:

• qlogic-fastlinq-alt: 8.70.12.0-1.xcpng8.3 -> 8.74.6.0-1.xcpng8.3

Test on XCP-ng 8.3

If you are using XOSTOR, please refer to our documentation for the update method.

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

The most important change is related to storage: adding QCOW2 support also affects the codebase managing VHD disks. What matters here is, above all, to detect any regression on VHD support (we tested it deeply, but on this matter there's no such thing as too much testing). Of course, you are also welcome to test the QCOW2 image format support.

See the dedicated thread for more information.

Other significant changes requiring attention:

• SSH connectivity

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

Test window before official release of the updates

~4 days

We would like to thank users who reported feedback on the QCOW RC2 release: @acebmxer, @andrew, @bufanda, @flakpyro, @jeffberntsen, @ph7

New security and maintenance update candidates for you to test!

The whole platform has been hardened with crypto libraries updates.
We also publish other non-urgent updates which we had in the pipe for the next update release.

Important notice

️ Xen Orchestra's sdn_controller users should be aware that OpenSSL was updated to major version 3, causing XCP-ng to reject previously generated self-signed certificates for the SDN Controller: they must be updated manually, accordingly to the guide's procedure.

User feedback is valuable to all, feel free to report success or ask for clarification in the related forum thread.

What changed

OpenSSL and OpenSSH major version update

• openssl: Update to 3.0.9
  • The OpenSSL 3 upgrade is improving the security and maintainability of the system, but has impact regarding certificates generation in sdn_controller, as documented above.
  • To enable backward compatibility with older deprecated APIs, a new package, openssl-compat-10 has been introduced.
• openssh: Update to 9.8p1
  • Note that older ssh-clients (with weak ciphers) will need to update, if connection is rejected.
• libssh2: Update to 1.11.0

Maintenance updates

Virtualization & System

• xen: Update to 4.17.6
  • Xen sources updated to v4.17.6 and synchronization of previously released patches for XSA-477 and XSA-479.
• qemu: Bug fixes
  • qemu would crash when a framebuffer is relocated on a migrated HVM guest.
  • A race condition could cause events to be sent before capabilities negotiation.
• varstored: Update to 1.3.1
  • No further functional change from 1.2.0-3.5 (Fixes for XSA-478 / CVE-2025-58151 were backported).
  • Just syncing with XenServer, rebuilt with openssl-3.

Control plane

• xapi: Update to 26.1.3
  • User agents of clients are now tracked. Fetchable by using Host.get_tracked_user_agents.
  • Now it's possible to delete a VM with a snapshot that has a vTPM associated.
  • Speed up exports for mostly empty disks.
  • Now the tags of VDIs are copied when they are cloned or snapshotted done.
  • Fixed RPU scenario where pool members don't get enabled.
  • Added API for controlling NTP.
  • Fixed falling back to full backups instead of delta backups in cases where a VM was hosted in a local SR with more than 256 disks. This could also cause migrations to fail.
  • Added API to limit the number of VNC connections to a single VM.

UI

• xolite: Update to 0.19.0
  • [VM/New] Added vTPM support.
  • [VM/New] Fix wording in "Memory" section.
  • [TreeView] Scroll to current item in list view.
  • ChangeLog

Storage

• sm: Bug fixes
  • Improve Robustness FileSR GC when a host is offline.
  • Ensure LVM VDI is always active before relink.
  • Remove GC flag DB_GC_NO_SPACE when necessary to avoid errors.
  • Improve error messages when vdi_type is missing on LVM VDIs.
• blktap: Bug fix
  • Fixes a crash happening when scanning a SR with corrupt VHDs.
• lvm2: Update to 2.02.180
  • Add scini device support (Dell PowerFlex).

Network

• netsnmp: Update to 5.9.3
• openvswitch:
  • Rebuild with openssl-3 plus minor maintenance change.
• gnutls: Remove dane tool

Misc

• xcp-ng-release: UX improvement
  • The shell command history now record timestamps to improve consumer support.
• createrepo_c: Update to 0.21.1
• krb5: Synchronized with XenServer 8.4 and rebuilt for OpenSSL 3.
• ipmitool: Update to 1.8.19
• libarchive: Update to 3.6.1
• trousers: Update to 0.3.15 and rebuild for OpenSSL 3.
  • This version includes security fixes for known vulnerabilities in earlier upstream version, deemed not exploitable realistically on XCP-ng.
• wget: Update to 1.21.4

Note that libraries updates (libopenssl, notably) impacted several other packages which had to be rebuilt (some had to be patched too). Refer to the package list below.

Drivers updates (check details below)

More information about drivers and current versions is maintained on the drivers wiki page.

• broadcom-bnxt-en: Update to v1.10.3_237.1.20.0
  • No functional changes expected.
• intel-i40e : Update to 2.25.11
  • PTP-related kernel crash bugfixes for Intel i40e driver version 2.25.11.
  • ️ Google for the "intel <model-name> compatibility matrix" and make sure to update the non-volatile memory in NIC with the matching NVM version, after updating the driver.
  • This is also applicable for the intel-i40e-alt flavour of the driver package.
• intel-ixgbe: Update to 6.2.5
  • More Ethernet PCI Express 10 Gigabit Intel NIC devices are handled (E600 et E610 series).

XOSTOR

In addition to the changes in common packages, the following XOSTOR-specific packages received updates:

• drbd: Reduce the I/O load and time during resync.
• drbd-reactor: Misc improvements regarding drbd-reactor and events.
• linstor:
  • Resource delete: Fixed rare race condition where a delayed DRBD event causes "resource not found.
  • Misc changes to improve robustness LINSTOR API calls and checks.
• sm:
  • Wait for DRBD UpToDate state during LINSTOR VDI resize.
  • Improve LINSTOR error messages in the case of an excessively long VDI resize.
  • Simplify LINSTOR SR scan logic removing XAPI calls.
  • Use worker threads during LINSTOR SR's scan to improve performance.
  • Ensure a XOSTOR volume can't be destroyed if used by any process (outside of the SMAPI environment).
  • Use ss to obtain the controller IP: it's a significant improvement to avoid relying on DRBD commands or XAPI plugins.
  • Avoid issuing errors if the size of a LINSTOR volume cannot be fetched after a bad delete call.
• python-linstor: updated to version 1.27.1. LINBIT's changelog:
  • "Added api method to check the controller’s current encryption state (locked/unlocked/unset)"
• linstor-client: updated to version 1.27.1. LINBIT's changelog:
  • "Added new alias --drbd-diskless to command r td to mimic the option from r c.
  • "Added new sub-command encryption status to show the current locked-state of the controller.

Versions:

• bind: 32:9.9.4-61.el7_5.1 -> 32:9.9.4-63.1.xcpng8.3
• blktap: 3.55.5-6.1.xcpng8.3 -> 3.55.5-6.3.xcpng8.3
• broadcom-bnxt-en: 1.10.3_232.0.155.5-1.xcpng8.3 -> 1.10.3_237.1.20.0-8.1.xcpng8.3
• coreutils: 8.22-21.el7 -> 8.22-22.xcpng8.3
• createrepo_c: 0.10.0-6.el7 -> 0.21.1-3.xcpng8.3
• curl: 8.9.1-5.1.xcpng8.3 -> 8.9.1-5.2.xcpng8.3
• gnutls: 3.3.29-9.el7_6 -> 3.3.29-10.1.xcpng8.3
• gpumon: 24.1.0-71.1.xcpng8.3 -> 24.1.0-83.2.xcpng8.3
• intel-i40e: 2.25.11-2.xcpng8.3 -> 2.25.11-4.xcpng8.3
• intel-ixgbe: 5.18.6-1.xcpng8.3 -> 6.2.5-1.xcpng8.3
• intel-microcode: 20251029-1.xcpng8.3 -> 20260115-1.xcpng8.3
• ipmitool: 1.8.18-7.el7 -> 1.8.19-11.1.xcpng8.3
• iputils: 20160308-10.el7 -> 20160308-10.1.xcpng8.3
• krb5: 1.15.1-19.el7 -> 1.15.1-22.1.xcpng8.3
• libarchive: 3.3.3-1.1.xcpng8.3 -> 3.6.1-4.1.xcpng8.3
• libevent: 2.0.21-4.el7 -> 2.0.21-4.1.xcpng8.3
• libssh2: 1.4.3-10.el7_2.1 -> 1.11.0-1.xcpng8.3
• libtpms: 0.9.6-3.xcpng8.3 -> 0.9.6-3.1.xcpng8.3
• lvm2: 7:1.02.149-18.2.1.xcpng8.3 -> 7:2.02.180-18.3.1.xcpng8.3
• mdadm: 4.0-13.el7 -> 4.2-5.xcpng8.3
• net-snmp: 1:5.7.2-52.1.xcpng8.3 -> 1:5.9.3-8.1.xcpng8.3
• openssh: 7.4p1-23.3.3.xcpng8.3 -> 9.8p1-1.2.1.xcpng8.3
• openssl: 1:1.0.2k-26.2.xcpng8.3 -> 1:3.0.9-2.0.1.3.xcpng8.3
• openvswitch: 2.17.7-2.1.xcpng8.3 -> 2.17.7-4.1.xcpng8.3
• python: 2.7.5-90.el7 -> 2.7.5-92.1.xcpng8.3
• python3: 3.6.8-18.el7 -> 3.6.8-20.xcpng8.3
• python-pycurl: 7.19.0-19.el7 -> 7.19.0-19.1.xcpng8.3
• qemu: 2:4.2.1-5.2.15.2.xcpng8.3 -> 2:4.2.1-5.2.17.1.xcpng8.3
• rsync: 3.4.1-1.1.xcpng8.3 -> 3.4.1-1.2.xcpng8.3
• samba: 4.10.16-25.2.xcpng8.3 -> 4.10.16-25.3.xcpng8.3
• sm: 3.2.12-16.1.xcpng8.3 -> 3.2.12-17.1.xcpng8.3
• ssmtp: 2.64-14.el7 -> 2.64-14.1.xcpng8.3
• stunnel: 5.60-4.xcpng8.3 -> 5.60-5.xcpng8.3
• sudo: 1.9.15-4.1.xcpng8.3 -> 1.9.15-5.1.xcpng8.3
• swtpm: 0.7.3-12.xcpng8.3 -> 0.7.3-12.1.xcpng8.3
• tcpdump: 14:4.9.2-3.el7 -> 14:4.9.2-3.1.xcpng8.3
• trousers: 0.3.14-2.el7 -> 0.3.15-11.1.xcpng8.3
• varstored: 1.2.0-3.5.xcpng8.3 -> 1.3.1-2.1.xcpng8.3
• wget: 1.14-15.el7_4.1 -> 1.21.4-1.1.xcpng8.3
• xapi: 25.33.1-2.3.xcpng8.3 -> 26.1.3-1.3.xcpng8.3
• xcp-featured: 1.1.8-3.xcpng8.3 -> 1.1.8-6.xcpng8.3
• xcp-ng-release: 8.3.0-36 -> 8.3.0-37
• xen: 4.17.5-23.2.xcpng8.3 -> 4.17.6-2.1.xcpng8.3
• xo-lite: 0.17.0-1.xcpng8.3 -> 0.19.0-1.xcpng8.3

XOSTOR:

• linstor: 1.33.1-1.el7_9
• linstor-client: 1.27.1-1.xcpng8.3
• python-linstor: 1.27.1-1.xcpng8.3
• xcp-ng-linstor: 1.2-6.xcpng8.3

Optional packages:

• iperf3: 3.9-13.1.xcpng8.3
• ldns: 1.7.0-21.1.xcpng8.3
• socat: 1.7.4.1-6.1.xcpng8.3

Test on XCP-ng 8.3

If you are using XOSTOR, please refer to our documentation for the update method.

If you are using XenOrchestra's SDN controller please apply the OpenSSL upgrade procedure.

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

• XAPI tests:
  • Check that the NTP servers used by hosts are set to Factory, test changing them to DHCP, or Custom.
  • Check that the console limit is 0 by default, test changing it to 1, and set a timeout.
• System: Check updated tools (ssh, wget, samba, mdadm...)
• Normal use and anything else you want to test.

Test window before official release of the updates

~1 week

@MajorP93

Fix has been merged, expect a package in your updates soon.

Meanwhile check this notice about upcoming changes regarding remote syslog.

https://github.com/xcp-ng-rpms/xcp-ng-release/pull/41#issuecomment-3800419449

rzr said:

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

Test window before official release of the updates

~3 days

The testing window is extended a bit, expect also a next batch (to be tested later this month).

It has been planned to group updates for the convenience of administrators (stay tuned in blog).

Meanwhile If you didn't notice yet, an updated xen-4.17.6-9.2.xcpng8.3 package landed in testing repo, it addresses some low risk vulnerabilities as reported at:

• VSA-2026-017 (XSA-491, CVE-2026-42487)
• VSA-2026-018 (XSA-492, CVE-2026-42489 - CVE-2026-42490),
• VSA-2026-019 (CVE-2025-10263, XSA-493)
• VSA-2026-020 (CVE-2026-42488, XSA-494)

More to come soon

@Andrew said:

Thank you for this report, I fear this issue appeared when we rebuilt bind with openssl-3

nslookup vates.com 8.8.8.8

I confirm this issue, note that bind-utils is not installed by default, let me investigate.

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

This release batch contains security fixes on the Linux kernel in dom0, version updates, some bug fixes and a few improvements.

What changed

Virtualization & System

• kernel: Update to 4.19.19-8.0.46.5

  • Fixes multiple vulnerabilities:
    • CVE-2026-46300: A logic error in the network stack could allow an unprivileged local user to escalate its privileges to root by modifying page caches for file-backed files that were not supposed to be writable. The modifications are not persistent to a reboot (i.e. no disk corruption). This vulnerability is used by the public exploit Fragnesia.
    • CVE-2026-46333: Incorrect tracking of users privilege level when a task is exiting in the ptrace sub-system could allow an unprivileged local user to escalate its privileges to root by writing to file descriptors they are not supposed to have access to. The changes made to potentially root-owned files are persisted across reboots. This vulnerability is used by the public exploits ssh-keysign-pwn as well as ptrace_may_dream.
    • CVE-2026-43494: A double-free of pinned pages in the RDS kernel module in the transmit error path could allow an unprivileged local user to escalate its privileges to root by modifying page caches for file-backed files, allowing them to for example overwrite a SUID binary in page cache with a shellcode. Changes are not persistent across reboots. This vulnerability is used by the public exploit pintheft.

• qemu: Fix a potential issue in guest memory mapping lookup.

• edk2:

  • Fix issues while booting from physical CD/DVD drive.
  • Bump UEFI guest vCPU limit to 128 vCPU (was 96 vCPUs)

• dmidecode: Update to 3.6-3

  • Version able to read type 42 tables (redfish)

• varstored: Update to 1.3.2-2.1

  • Sync with upstream.

• ipxe: PXE boot support of BIOS VMs on a VLAN with 802.1Q priority tags

Control plane

• xapi: Enable USB passthrough of smartcards

Storage

• blktap: No functional change. Only sync with upstream.

Network

• openssh: Drop support of insecure clients
  • Old OpenSSH clients (version less than 7.2) can no longer connect with ssh-rsa (due to SHA-1 being no longer accepted by the server).
  • The solution is either to update OpenSSH-clients (to a version >= 7.2), or to generate and use ED25519 keys.

Others

• libtasn1: Update to 4.21.0 (hardening)
• fuse: Rebuild
• slang: Rebuild
• systemtap: Rebuild

Optional packages

• libreswan: Rebuild
• netdata: Rebuild

Versions:

• blktap: 3.55.5-6.7.xcpng8.3 -> 3.55.5-9.1.xcpng8.3
• dmidecode: 1:3.0-5.el7 -> 1:3.6-3.xcpng8.3
• edk2: 20220801-1.7.10.1.xcpng8.3 -> 20220801-1.7.11.1.xcpng8.3
• fuse: 2.9.2-10.xcpng8.3 -> 2.9.2-10.1.xcpng8.3
• ipxe: 20121005-1.0.7.xcpng8.3 -> 20121005-1.0.8.xcpng8.3
• kernel: 4.19.19-8.0.46.3.xcpng8.3 -> 4.19.19-8.0.46.5.xcpng8.3
• libreswam: 4.12-2.3.1.xcpng8.3 -> 4.12-2.3.2.xcpng8.3
• libtasn1: 4.10-1.el7 -> 4.21.0-1.xcpng8.3
• openssh: 9.8p1-1.2.3.xcpng8.3 -> 9.8p1-1.2.4.xcpng8.3
• netdata: 1.47.5-4.2.xcpng8.3 -> 1.47.5-4.3.xcpng8.3
• qemu: 2:4.2.1-5.2.17.1.xcpng8.3 -> 2:4.2.1-5.2.18.1.xcpng8.3
• slang: 2.3.2-11.xcpng8.3 -> 2.3.2-11.1.xcpng8.3
• systemtap: 4.0-5.2.xcpng8.3 -> 4.0-5.3.xcpng8.3
• varstored: 1.3.1-2.1.xcpng8.3 -> 1.3.2-2.1.xcpng8.3
• xapi: 26.1.4-3.1.xcpng8.3 -> 26.1.4-3.2.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

~1 day

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

@Andrew, @acebmxer, @flakpyro, @greg_e, @jeffberntsen, @marcoi, @ovicz, @ph7, @probain.

New feature, security and maintenance update candidates for you to test!

This release batch contains a major storage feature,
read the RC2 announcement for QCOW2 image format support for 2TiB+ images.

The whole platform has been hardened with a major OpenSSH update.

The updated Windows Guest Tools bring support for the XSTDVGA driver, allowing display resizing.

We also publish other non-urgent updates which we had in the pipe for the next update release.

What changed

Storage

QCOW2 image format support is the major feature of this release batch,
check related announcement in forum.

• sm: 3.2.12-17.2
  • Add support for the QCOW2 image format
• blktap: 3.55.5-6.4
  • Add support of new QCOW2 disk type

Maintenance updates

Virtualization & System

• xen: 4.17.6-6.1
  • Sync with XenServer's xen-4.17.6-6.xs8
    * Fix boot failure on some UEFI systems. WIP
• kernel: 4.19.19-8.0.46.1
  • Fix regarding use of the correct MAC address in the rndis_host driver
  • Backport fix regarding a potential bug in the ext4 driver (CVE-2020-14314)
  • Backports fixes in SUNRPC (related to NFS). This prevents host crashes under some circumstances.

Control plane

• xapi: 26.1.3-1.6
  • Several fixes to QCOW2 enablement for importing and exporting, like reducing memory usage on disk import
• xcp-ng-xapi-plugins: 1.16.0-1
  • sdncontroller.py: add support for new optional cookie argument to add-rule and del-rule functions
• xcp-ng-pv-tools: 8.3-16
  • Update to XCP-ng Windows PV Tools 9.1.146.0
  • Include the XSTDVGA driver and improvements to the guest agent/installer

UI

• xo-lite: Update to 0.20.0-1
  • [VM/New] Added secureBoot support (PR #9423)
  • [Dashboard] Fix reactivity of dashboard (PR #9378)
  • [VM] Fixed duplicated ip addresses in the network tab Forum#101359 (PR #9547)
  • [Stats] Return null instead of 0 when no stats available (PR #9634)
  • [Treeview/Pool/Host] Add button to download bugtools (PR #9419)

Network

• gnutls: 3.3.29-10.2
  • Fix dane removal (no more replacing dane with devel package)
• openssh: Update to 9.8p1-1.2.2
  • Deprecate old OpenSSH clients (7.2 and lower) that use weak SHA1 with ssh-rsa:
    • For now, a warning will ask to use an up to date client, on next update weak configurations will be rejected.
• net-snmp: 5.9.3-8.2
  • Fix SNMP regression (daemon configuration was lost in earlier version)
• xcp-ng-deps: 8.3-14
  • Install traceroute to troubleshoot connectivity problems

Additional packages

Best effort support is provided for additional packages provided by the XCP-ng project.

• lldpd: version 1.0.4-1.1 provided for convenience in our repositories, as the EPEL version is not compatible anymore with the latest XCP-ng 8.3 updates. However, please prefer the pre-installed lldapd whenever possible.
• nut: version 2.8.0-2.1 provided for convenience in our repositories, as the EPEL version is not compatible anymore with the latest XCP-ng updates.
  • User feedback is welcome

Drivers updates

More information about drivers and current versions is maintained on the drivers wiki page.

• emulex-lpfc-alt: 14.4.393.31-1.1
  • This is an alternative driver which handles newer Emulex lpfc devices.
• sfc-module-alt: 5.3.18.1012-1
  • Initial alternate driver for Solarflare SFN5XXX|6XXX|7XXX|8XXX|X2, version 5.3.18.1012

Versions:

• blktap: 3.55.5-6.3.xcpng8.3 -> 3.55.5-6.4.xcpng8.3
• gnutls: 3.3.29-10.1.xcpng8.3 -> 3.3.29-10.2.xcpng8.3
• kernel: 4.19.19-8.0.44.1.xcpng8.3 -> 4.19.19-8.0.46.1.xcpng8.3
• net-snmp: 1:5.9.3-8.1.xcpng8.3 -> 1:5.9.3-8.2.xcpng8.3
• openssh: 7.4p1-23.3.3.xcpng8.3 -> 9.8p1-1.2.2.xcpng8.3
• sm: 3.2.12-17.1.xcpng8.3 -> 3.2.12-17.2.xcpng8.3
• traceroute: 3:2.1.5-2.xcpng8.3
• xapi: 26.1.3-1.3.xcpng8.3 -> 26.1.3-1.6.xcpng8.3
• xcp-ng-deps: 8.3-13 -> 8.3-14
• xcp-ng-pv-tools: 8.3-15.xcpng8.3 -> 8.3-16.xcpng8.3
• xcp-ng-xapi-plugins: 1.15.0-1.xcpng8.3 -> 1.16.0-1.xcpng8.3
• xen: 4.17.6-5.2.xcpng8.3 -> 4.17.6-6.1.xcpng8.3
• xo-lite: 0.19.0-1.xcpng8.3 -> 0.20.0-1.xcpng8.3

Optional packages:

• lldpd: 1.0.4-1.1
• nut: 2.8.0-2.1

Test on XCP-ng 8.3

If you are using XOSTOR, please refer to our documentation for the update method.

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.

Known issues

• On blktap update a non blocking error is reported,the fix is ongoing and will be delivered soon

What to test

The most important change is related to storage: adding QCOW2 support also affects the codebase managing VHD disks. What matters here is, above all, to detect any regression on VHD support (we tested it deeply, but on this matter there's no such thing as too much testing). Of course, you are also welcome to test the QCOW2 image format support.

See the dedicated thread for more information.

Other significant changes requiring attention:
* SSH connectivity
* SNMP, if you use it

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

Test window before official release of the updates

~2 weeks

Thank you every visitors and for those who did not had the chance to visit fosdem check this report:

https://xcp-ng.org/blog/2026/02/19/fosdem-2026-follow-up/

One question, I promised to forward to the forum, how many VM are you running on XCP-ng ?

Dozen, hundreds, thousands or more ?

XCP-ng is back to FOSDEM again for the 10th time, come to visit the Xen/XCP-ng stands !

https://fosdem.org/2026/stands/

Check Vates announcement at:

https://vates.tech/blog/fosdem-2026/

Ask us for demos

https://rzr.github.io/rzr-presentations/docs/xcp-ng

https://www.youtube.com/embed/eYOUKrU75XE

ps: Post to be updated before the event for up to date info

Keep connected until #FOSDEM2027

https://matrix.to/#/#xcp-ng:vates.tech

Package landed in testing repo please check the related announcement:

https://xcp-ng.org/forum/topic/9964/xcp-ng-8-3-updates-announcements-and-testing/432

Then please confirm the issue is gone by editing post topic with "[SOLVED]" prefix

@FritzGerald said:

@rzr Just for curiosity.

As far as I understand you assess the risk as low for the nut package - and only for that - to use ci-repo. I am fine with that for my personal servers.

• Would you consider to integrate this into "stable" branch?

yes it's the plan, we usually test packages in ci repos for a couple of weeks and once we're happy of the packages set it goes to testing repo, then users can officially test it (and based on feedback (or absence of feedback) then everything lands in update repo after a week or more (it depends on risk or hurry)..

• What would be the next steps on our side to support this?

I think nothing should be done your side you did your job before the testing window, early feedback is always appreciated (as long people know what they are doing )

But If I were you, just to be safe i would keep trace of packages i have installed from ci or testing repo, in case anything is not going as expected, you can still reinstall those packages from update channel.

• How long would does that roughly take?

It depends usually a couple of weeks, but this next batch might be a bit longer because there is a long waited feature planned.

Check the future announcement in the forum.

Thank again!

thank you for the detailed howto, if there is traction for this feature maybe it worth documenting officially, I'll ask product managers.

@Kajetan321 said:

It looks like "yum remove nut" does the trick.

Yes this "extra" tool was not (never?) supported ,

If you really need it, there are 2 options to consider:

• 1st is convince us to add it to the distro
• 2d rebuild it yourself (to link with updated dep, and also rebuild its deps like neon)

I managed to install xcp-ng and alpine on a Single Board Computer : seco b68 powered by Intel(R) Celeron(R) CPU N3350 @ 1.10GHz and 2GB of RAM !!!

https://mastodon.social/@rzr/114970751940254294

Then 400MB can be allocated for a VM (or several)

Let me track the power consumption and imagine some minimalist-homelab use-cases ...

XCP-ng 8.3 LTS Updated installer ISO

The installer ISO has been refreshed with up date packages already published.

The image can be downloaded from:

https://repo.vates.tech/tmp/xcp-ng-8.3.0-20260709.testing.iso

The procedure to install XCP-ng 8.3 remains the same.

The refreshed installer ships updated Xen, Linux kernel and some drivers/firmware, which help with deploying XCP-ng 8.3 on hardware that needs changes introduced by updates not present in previous ISO image releases.

This refreshed ISO has been validated on a subset of supported hardware. Additional testing on any hardware from the community would be greatly appreciated.

As with previous installer releases, it can be used to upgrade XCP-ng from a previous major release (8.0, 8.1 or 8.2). Refer to the Upgrade documentation. For existing XCP-ng 8.3 installations, there’s no need to use this ISO image. Regular yum updates achieve the same results as a fresh installation with that ISO image.

Installer improvements include minor enhancements related to software RAID1 support for the system disks, including support for more than 2 disks in the RAID1 array if anyone really wants that.

New maintenance update candidates for XCP-ng 8.3 LTS

This release batch includes a VBD leak regression fix in XAPI and minor changes needed to build the installer ISO.

A regression was introduced to the VM.revert operation in xapi-26.1.4-3.3, which left VBDs attached to the VM when they are not present in the reverted-to snapshot (instead of destroying such VBDs, as was done before).

VMs that were reverted to their snapshots after xapi-26.1.4-3.3 may have such "leftover" VBDs. Advanced users can use the leaked_vbds script to detect possible cases in your pools. Sadly, there is no way to automatically distinguish a VBD that was created after a VM.revert from a VBD that survived the VM.revert, so this script relies on the user to determine if the suspicious VBDs are indeed affected or not.

What changed

Control Plane

• xapi: Fix non-snapshotted VBDs staying attached after VM.revert

Versions

• xapi: 26.1.11-1.2.xcpng8.3 -> 26.1.11-1.3.xcpng8.3
• xcp-ng-release: 8.3.0-37 -> 8.3.0-38

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

~5 days

We would like to thank users who shared feedback since our last call for testing: @Andrew, @XCP-ng-JustGreat, @acebmxer, @bufanda, @flakpyro , @marcoi.

New maintenance update candidates for XCP-ng 8.3 LTS

This release batch contains mostly fixes, tools version update, a some improvements.

Note: the previous batch of updates has not been released yet, so if you haven't tested it, you will see more updates than described here when you'll install the update candidates. Refer to the previous announcements.

What changed

Virtualization & System

• xen: Add support for xenpm get-core-temp to query CPU temperature on Intel platforms.

  • Use xenpm get-core-temp to get the temperature on Intel's CPU, to fallback unsupported coretemp. Doc update being reviewed.

• grub: Sync with XenServer 8.4: Fix a rare out-of-memory error.

• dracut: Fixes

  • Fix to force reboot/shutdown/halt.
  • Fix issue where the omission of 'override' kernel modules from the initrd image could, in rare instances, prevent a freshly installed XCP-ng host from booting.

Control Plane

• xapi: Update to 26.1.11, add fixes and improvements.
  • Fixed an issue where a newly installed host wouldn't be able to join a pool due to incompatible features exposed by storage.
  • Fix shutdown VMs not being migratable due to errors generated when the VM was running.
  • Allow moving VMs back to DHCP from static IP with configure_ipv4/6.

Network

• stunnel: Fixed stunnel only considering one of the self-signed certificates with the same DN.

Tools

• xcp-ng-pv-tools: Update to XCP-ng Windows Guest Tools 9.1.200 (full changelog).

Drivers

• mpi3mr-module: Update to version 8.17.1, adding newly supported SAS5116 devices.

Optional:

• mellanox-mlnxen-alt: Fix build error with kernel 4.19.19-8.0.42.1+.

Storage

• kmod-drbd: Update to 9.2.18 (full changelog)

  • Improve XOSTOR stability when evacuating/evicting an host.

• xcp-ng-release-linstor: Relocate config file to v8.3-linstor repository.

Versions

• dracut: 033-538.xcpng8.3 -> 033-539.1.xcpng8.3
• gpumon: 24.1.0-84.1.xcpng8.3 -> 24.1.0-91.1.xcpng8.3
• grub: 1:2.06-4.0.2.1.xcpng8.3 -> 1:2.06-4.0.5.1.xcpng8.3
• mpi3mr-module: 8.6.1.0.0-1.xcpng8.3 -> 8.17.1.0.0-1.xcpng8.3
• stunnel: 5.60-5.xcpng8.3 -> 5.60-6.1.xcpng8.3
• xapi: 26.1.4-3.2.xcpng8.3 -> 26.1.11-1.1.xcpng8.3
• xcp-featured: 1.2.1-1.xcpng8.3 -> 1.2.1-2.xcpng8.3
• xcp-ng-pv-tools: 8.3-17.xcpng8.3 -> 8.3-18.xcpng8.3
• xen: 4.17.6-9.1.xcpng8.3 -> 4.17.6-9.3.xcpng8.3

Optional packages:

• mellanox-mlnxen-alt: 5.4_1.0.3.0-2.xcpng8.3 -> 5.4_1.0.3.0-3.xcpng8.3

XOSTOR users: specific update procedure

Some XOSTOR packages are provided in separate repository, and should be installed along xcp-ng regular packages, using the following commands:

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

Note: linstor packages themselves have not been updated, only kmod-drbd and xcp-ng-release-linstor. Thus, this time it's not necessary to restart the satellites before rebooting.

The following XOSTOR-specific package received updates (and must be updated in the same transaction, which the above update commands will do):

• xcp-ng-release-linstor: 1.4-2.xcpng8.3 -> 1.5-1.xcpng8.3 (from xcp-ng-testing repo)
• kmod-drbd: 9.2.16-1.0.xcpng8.3 -> 9.2.18-2.0.xcpng8.3 (from xcp-ng-linstor-testing repo)

Test on XCP-ng 8.3

Warning: XOSTOR users should skip this part and follow the instructions of the previous section.

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

~2 days

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

@Andrew, @XCP-ng-JustGreat, @acebmxer, @bufanda, @flakpyro, @jeffberntsen, @majorp93, @manilx, @marcoi, @ph7.

@acebmxer said:

@rzr
No issues to report initially other then nslookup still an issue.

openssl_link.c:132: INSIST(dst__memory_pool != ((void *)0)) failed, back trace

Yes I looked at it, it looks like it's a design isssue that was fixed in later version of bind.

In details If I understand correctly this patched version of nslookup is facing a SIGARBT caused by an assert on previously cleanup resources (dst__memory_pool) which is unexpected in finishing part of the openssl thread (dst__openssl_destroy).

This bind patched version (where ssl support is in progress) is also known to have memory leaks, but those are resolved in later version, so until we catch up you'll probably have to live with this little annoyance on process exit unless we find (and validate) a better fix.