Thank you everyone for your tests and your feedback!

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

New security update candidate for you to test!

A new security vulnerability has been detected and fixed for xen.

This was introduced by an upstream commit, and detected before the Xen Project did any new release. Therefore this does not impact any upstream release, and there is no Xen Security Advisory this time. But that change was backported into XCP-ng xen package, therefore XCP-ng is impacted.

---

Security updates

• xen: Fix a security issue where insufficient memory sanitization during guest creation can lead to information leakage from previous guests and potential privilege escalation

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:

• xen: 4.17.6-5.2.xcpng8.3

What to test

Normal use and anything else you want to test.

Test window before official release of the updates

~2 days

@acebmxer I invite you to open a ticket through the support ticketing system.

I do not connect remotely myself and I am also unable to provide support for Xen-Orchestra.

@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

An update for ipmitool has just been released, incorporating a fix for the issue you were experiencing: https://xcp-ng.org/blog/2026/03/19/march-2026-security-updates-for-xcp-ng-8-3-lts/

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/

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

@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.

For XO, I suggest you start a separate thread.

Regarding the host issue, without more details or information, it's difficult to say anything at the moment, especially since I haven't been able to reproduce it myself.

As explained, I haven't observed such a delay on our end during our testing.

As Maniix suggests, you can see what's happening by pressing "Esc" to see which step is taking longer.

From what I've heard internally, a common reason for this lengthy step is when a shared server was running on a VM and that VM was shut down. The host then takes a very long time to shut down or restart.

@abudef I've updated and rebooted numerous hosts with these updates and haven't noticed any significant slowdowns.

Do you have any additional information in the logs?

The update mentioned by Pau should has just been released along with other updates. For more information, you can consult the corresponding blog post: https://xcp-ng.org/blog/2026/03/10/march-2026-maintenance-updates-for-xcp-ng-8-3-lts/

@MajorP93 the diffusion of RPMs across different repositories around the world can take some time depending on your geographical location.

Sometimes a yum clean metadata can also help to clear the cache and better detect updates that have just arrived on certain repositories.

Thank you everyone for your tests and your feedback!

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

@Andrew I just pinged Philippe (rzr) internally to ask him to look into this

New update candidate for you to test!

A new update for the Xen packages is ready, which brings a significant improvement in live migration performance on AMD systems under heavy load, that we add to the previous batch of updates for a common publication.

---

Maintenance updates

• xen: Improve migration performance on AMD systems under heavy load.

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:

• xen: 4.17.6-4.1.xcpng8.3

What to test

Normal use and anything else you want to test. If you have a pool with AMD processors, we're interested in your feedback regarding live migration under heavy load.

Test window before official release of the updates

~4/5 days

Hello,

We have forwarded your questions internally, specifically to our storage team regarding a possible update to create an SR ISO on a SAN disk FC, and to our XAPI team regarding questions related to the RPU. We have also contacted the Xen-Orchestra team with questions about potential improvements to avoid the issues you encountered.

This has sparked discussions and reflection, but no conclusions have been reached yet.

In any case, thank you for sharing your experience

The update should now be available. You can view the announcement here: https://xcp-ng.org/blog/2026/01/29/january-2026-security-and-maintenance-updates-for-xcp-ng-8-3-lts/

So don’t hesitate to update it and confirm that it properly addresses the issue.

Thank you everyone for your tests and your feedback!

The updates are live now: https://xcp-ng.org/blog/2026/01/29/january-2026-security-and-maintenance-updates-for-xcp-ng-8-3-lts/

New security and maintenance update candidates for you to test!

Security vulnerabilities have been detected and fixed for xen and varstored. We also publish other non-urgent updates which we had in the pipe for the next update release.

Security updates:

• xen:

  • XSA-477 / VSA-2026-001: A buffer overflow in the Xen shadow tracing code could allow a DomU virtual machine to crash Xen, or potentially escalate privileges.
  • XSA-479 / VSA-2026-003: Some Xen optimizations to avoid clearing internal CPU buffers when not required could allow one guest to leak data of another guest. A mitigation can be applied without the fix by rebooting vulnerable Xen with "spec-ctrl=ibpb-entry=hvm,ibpb-entry=pv" on the Xen command line at the cost of decreased performances.

• varstored:

  • XSA-478 / VSA-2026-002: Within varstored, there were insufficient compiler barriers, creating TOCTOU issues with data in the shared buffer. An attacker with kernel level access in a VM can escalate privilege via gaining code execution within varstored.

Maintenance updates:

• guest-templates-json:

  • Update VM template labels
  • Sync RHEL10 template with XenServer's

• intel-microcode:

  • Update to publicly released microcode-20251111
  • Updates for multiple functional issues

• kernel: Bug fixes in the NFS and NBD stacks for various deadlocks and other race conditions.

• qemu: Backport for CVE-2021-3929, fixing a DMA reentrancy flaw in NVMe emulation, that could lead to use-after-free from a malicious guest and potential arbitrary code execution.

• smartmontools: Update to minor release 7.5

• swtpm: Synchronize with release 0.7.3-12 from XenServer. No functional changes.

• xapi: Fix regression on dynamic memory management during live migration, causing VMs not to balloon down before the migration.

• xcp-ng-release: Prevent remote syslog from being overwritten by system updates.

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

• drbd: Reduces 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" ErrorReports
  • Misc changes to robustify LINSTOR API calls and checks

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

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:

• guest-templates-json: 2.0.15-1.1.xcpng8.3
• intel-microcode: 20251029-1.xcpng8.3
• kernel: 4.19.19-8.0.44.1.xcpng8.3
• qemu: 4.2.1-5.2.15.2.xcpng8.3
• smartmontools: 7.5-1.xcpng8.3
• swtpm: 0.7.3-12.xcpng8.3
• xapi: 25.33.1-2.3.xcpng8.3
• xcp-ng-release: 8.3.0-36
• xcp-python-libs: 3.0.10-1.1.xcpng8.3
• xen: 4.17.5-23.2.xcpng8.3
• varstored: 1.2.0-3.5.xcpng8.3

XOSTOR

• drbd: 9.33.0-1.el7_9
• drbd-reactor: 1.9.0-1
• kmod-drbd: 9.2.16-1.0.xcpng8.3
• linstor: 1.33.0~rc.2-1.el8
• linstor-client: 1.27.0-1.xcpng8.3
• python-linstor: 1.27.0-1.xcpng8.3
• xcp-ng-linstor: 1.2-4.xcpng8.3

What to test

Normal use and anything else you want to test.

Test window before official release of the updates

2 days max.