New maintenance update candidates for XCP-ng 8.3 LTS

gduperrey

We have just released security updates for xen and blktap. Full details are available on the blog: https://xcp-ng.org/blog/2026/10/13/october-2026-security-updates-2-for-xcp-ng-8-3-lts/

gduperrey

Hello,

We have received your request and thank you for the feedback on this matter.

A task card has been created and assigned to one of our teams. It has not yet been assigned to a specific developer, but we will be sure to get back to you once it has been addressed and resolved.

gduperrey

Thank you everyone for your tests and your feedback!

The updates are live now: https://xcp-ng.org/blog/2026/10/05/october-2026-updates-1-for-xcp-ng-8-3-lts/

We decided not to release the xen update that was initially included in the testing phase of this update cycle. It introduced changes related to support for Windows VMs with more than 64 vCPUs; a feature that is not yet fully supported and requires further work to be completely implemented.

We therefore chose to postpone it to avoid any regressions or user confusion, aiming to release a properly finalized and documented version in the near future.

This version should have no impact on your test environments, and they can continue to operate as is. Any future xen update should have a higher version number and should install over the current one.

However, if you do not wish to keep this update on your test environments, you can downgrade using the command yum downgrade xen-*.

stormi

@JamesG Thanks. I'll let @teddyastie see. I think he would be more confortable with having the card in our lab, which should be imminent now, but I won't speak for him.

stormi

@pandusen said:

But I would in any case where PCI passthrough for edge cases like the GPU marked kind of is, is not a requirement, Always recommend XCP-ng over the others.

Thanks for that :).

There's no problem to state faithfully what works and what doesn't with a solution, and adapt the advice to the actual needs.

I just felt compelled to react because I didn't find it entirely right to state that GPU passthrough has low priority. It's supported in general, but there are devices that come with technical challenges not fully addressed yet in Xen or in XCP-ng, and we treat that as part of the general hardware support we aim for.

Same as we work on device drivers for devices mostly found in home labs, without dismissing them as low priority.

And it's a good point to state that the needs around GPUs are growing fast due to AI, indeed.

stormi

@pandusen said:

99 percent of the dev team is working security and basic hypervisor

The numbers don't match any reality though. Yes, maintenance is important, but we have a developer working on AMD iGPU passthrough fixes, and Teddy here is following the Intel Arc topic closely and obtained hardware (waiting for it to be available in the lab). We also work on AMD MxGPU for vGPU support on the supported devices. We also have work on virtio-gpu. Without producing something that can become an actual feature yet, as it's complex, but there's clearly investment on those fronts.

gleh

New maintenance update candidates for XCP-ng 8.3 LTS

This batch of updates contains performance improvements, fixes, a guest tools update, and other improvements.

What changed

Virtualization & System

kernel: Fix potential deadlocks in the NFS subsystem.
xen:
- Enable Viridian enlightenments to prepare for support of Windows VMs with >64 vCPUs
- Sync with XenServer release 4.17.7-2. It fixes XSA-511, which didn't affect XCP-ng.
systemd: Fix detection of NVMe controllers with multiple namespaces

Control Plane

xapi:
- Improve RPU stability by only migrating VMs to already-updated hosts
- Improve VDI migration performance by pipelining NBD writes
guest-templates-json:
- Sync with XenServer's guest-templates-json-2.0.16-1. It removes the Kylin Linux 7 Guest template.
- Disable Viridian in the "Other install media" template by default. As a reminder, Windows VMs must use Windows templates.

Storage

blktap:
1. A fix for a tapdisk crash happening when tapdisk pauses a VDI when a coalesce is in progress. This issue was caused by a use-after-free bug. We took time to thoroughly audit the code around pause/commit/cancel operations, and thus robustify the pause and commit code in this release.
2. Customers could get tapdisk with infinite stalled IO on QCOW2 VDI. A race-condition was identified that could allow to miss a notification from the front-end and therefore never check the blkif ring for new requests.
3. On a tapdisk running on a supporter node, CBT metadata does not flush before a pause operation. During the pause operation, the master host modifies the CBT metadata, then after the unpause the old metadata are flushed and discard master's modifications. Finally the CBT logs are detected as inconsistent and discarded.
4. Grow up the QCOW2 metadata cache to help on big disks.
sm:
- Robustify iSCSI calls against race condition and bad access using lock context manager.
- Retry host key tag removal when XAPI is unreachable or restarted to prevent errors and finish action.
- Explicitly notify a missing LINSTOR resource definition instead of displaying a human-unreadable trace.
- Repair LINSTOR RAW volume creation. Regression caused by QCOW2 code refactoring.
- Fix LINSTOR SR creation when a VG is missing on a host. Changes in behavior brought by an update of LINSTOR RPMs broke this feature, which prevented the creation of an SR in this situation. We're expanding the test suite to prevent this in the future.
- To help recovering from an eventual LINSTOR database corruption, it's now backed up regularly and after every major operation, locally on the master, and on the DRBD LINSTOR database volume.
- Fixed an issue on shared LVM-based SR (LVMoISCSI, LVMoHBA) where a failed live leaf coalesce of a QCOW2 image on a slave host caused the SRs to remain in an SR_FAILURE_1200 error state until the VM using the VDI was stopped or tapdisk was manually paused.
- Reduce qemu-img log verbosity in SMlog.
- Fix LVM metadata corruption on slave when CBT log deletion is triggered on VDI activation.
- Prevent an incorrect online coalesce to be reported as successful and causing issues with the QCOW2 chain.
- Add QCOW2 support during interrupted leaf-coalesce operations on file-based SRs.

Network

openvswitch: The openvswitch package no longer installs the unused openvswitch-cfg-update XAPI plugin file, which has been superseded by openvswitch-config-update from xapi-core. This is only meant to avoid confusion and brings no functional change.

UI

xo-lite:
- [Treeview] Add VM tree actions (PR #10304)
- [Pool/networks] Add the possibility to create new network or bonded network (PR #10145)
- [VM] Add VDIs page with table and side panel (PR #10269)
- [Host/Network] Add ability to rescan physical network interfaces (PIFs) (PR #10147)
- Fix inconsistent spacing in side panel cards (PR #10279)
- Fix missing collapse buttons on pools and hosts in the tree sidebar (added hasChildren prop) (PR #10244)
- [Pool/networks] Add the possibility to create new internal network (PR #10235)

Drivers and Middleware

vendor-drivers: The out of tree microsemi-aacraid driver from the RPM has proven to be unreliable. It has several issues, is missing patches from upstream and hasn't been updated for a while. So, we switch back to the in-tree driver just like XCP-ng 8.2 was doing.
xcp-ng-pv-tools:
- Update to XCP-ng Windows Guest Tools 9.2.385.
- Include the XenTools-fix-9.2.351.msp hotfix tool for users running 9.2.350.

Others

openssl: Update to 3.5.5

Versions

blktap: 3.55.5-9.5.xcpng8.3 -> 3.55.5-11.1.xcpng8.3
gpumon: 24.1.0-96.1.xcpng8.3 -> 24.1.0-98.1.xcpng8.3
guest-templates-json: 2.0.15-1.1.xcpng8.3 -> 2.0.16-1.1.xcpng8.3
kernel: 4.19.19-8.0.46.10.xcpng8.3 -> 4.19.19-8.0.46.12.xcpng8.3
openssl: 3.0.9-2.0.1.3.xcpng8.3 -> 3.5.5-1.3.xcpng8.3
openvswitch: 2.17.7-4.1.xcpng8.3 -> 2.17.7-4.2.xcpng8.3
sm: 3.2.12-23.5.xcpng8.3 -> 3.2.12-25.1.xcpng8.3
systemd: 219-57.5.xcpng8.3 -> 219-57.5.1.xcpng8.3
vendor-drivers: 2.0.3-1.1.xcpng8.3 -> 2.0.3-1.2.xcpng8.3
xapi: 26.1.16-1.2.xcpng8.3 -> 26.1.19-1.1.xcpng8.3
xcp-featured: 1.2.1-4.xcpng8.3 -> 1.2.1-5.xcpng8.3
xcp-ng-pv-tools: 8.3-18.xcpng8.3 -> 8.3-19.xcpng8.3
xen: 4.17.6-12.3.xcpng8.3 -> 4.17.7-2.3.xcpng8.3
xo-lite: 0.24.0-1.xcpng8.3 -> 0.25.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

4 days

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

stormi

CCing @Team-XAPI-Network and @Team-Hypervisor-Kernel for them to have a look at this strong vs weak host model and the impact on HA.

stormi

@pandusen said:
its scary that GPU passthrough still has a low priority for XCP-ng, during the boom of AI and local LLM Inferencing.

As XCP-ng product owner, and someone who sees how much work developers put into such topics, may I ask you to elaborate on this "has low priority" statement?

gduperrey

We have just released security updates for xen and blktap. Full details are available on the blog: https://xcp-ng.org/blog/2026/09/08/september-2026-security-updates-1-for-xcp-ng-8-3-lts/

Team - OS Platform Release

Posts

New maintenance update candidates for XCP-ng 8.3 LTS

What changed

Virtualization & System

Control Plane

Storage

Network

UI

Drivers and Middleware

Others

Versions

Test on XCP-ng 8.3

What to test

Test window before official release of the updates

Member List