Hello @XCP-ng-JustGreat,

I cannot comment on RPU issues via XO. I would recommend creating a new topic to report the problem directly to the XO team so they can analyze it.

As you can see, we recommend validating updates via the command line directly on XCP-ng before releasing them. That is a different scenario.

However, if several of you are experiencing RPU issues with XO, a dedicated topic will allow that team to investigate the situation and consult other teams if necessary. This would ensure the issue is better addressed and analyzed

Hello @acebmxer,

I can see from the support ticket and the summary that the issue appears to be resolved and was linked to the NFS update on the Synology. It’s great that you were able to find the solution.

@manilx If the pools are up to date, I would try restarting the XO VM to see if the task persists.

If it does persist, it might be best to open a separate topic for the XO team.

Thank you everyone for your tests and your feedback!

The updates are live now: https://xcp-ng.org/blog/2026/08/27/august-2026-updates-2-for-xcp-ng-8-3-lts/

Hello @MajorP93,

Several things in your message raise questions for me.

First, this SR:

• 1x Linstor vSAN iSCSI configured as QCOW2

What is this storage and how is it configured?
Currently, we do not support QCOW2 on Linstor/Xostor. So, is it simply an iSCSI device to which you have applied the QCOW2 format, or is it a Xostor on the XCP-ng pool?

Regarding jumbo frames, we do not use them internally and are not currently testing them. It is often recommended not to use them for the management interface, as indicated in the XCP-ng documentation: https://docs.xcp-ng.org/networking/

Non-standard MTUs (such as jumbo frames) are not supported on management interfaces. Using them can lead to serious issues, including failed pool member joins or unexpected network outages.

Is that the case here?

Thank you everyone for your tests and your feedback!

The updates are live now: https://xcp-ng.org/blog/2026/08/18/august-2026-updates-1-for-xcp-ng-8-3-lts/

@acebmxer This error does not appear to be linked to the update, but rather to a repo that has not yet had time to synchronize or is in the process of doing so at the time of your update.

Hello,

We have just made "refreshed" XCP-ng installation ISOs available for everyone; these include all updates released over the past year, up to the present day.

You can read the blog post here: https://xcp-ng.org/blog/2026/08/14/xcp-ng-8-3-lts-refreshed-installation-isos/

@yllar Hello,

We are still validating the ISOs, but we are getting closer to releasing them.
We hope to make them available soon.

We can reproduce the issue on our end as well.

This problem concerns Team XO; I've reported it to them with a link to this forum post.

ping @julienxovates

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.