XCP-ng 8.3 updates announcements and testing

acebmxer

@lmolina

I applied updates and nothing broken for me to report. I have done delta backup and a full backup both were successful.

JeffBerntsen

Updates applied to my systems, test and live. All is working well so far.

Andrew

@lmolina All updated. RPU successful. Systems running normally.

gduperrey

@MajorP93

We discussed your feedback yesterday, but we don't have an explanation at the moment. Our Windows expert tried to reproduce the behavior but was unable to trigger this error.

Furthermore, we haven't encountered any issues on our end with the RPU (Rolling Pool Update) operations performed during our tests, whether done manually or via XO. It is possible, however, that we are missing the specific scenario (VMs or configuration) required to trigger this one.

Have you been able to find any further information in the host logs?

If not, could you export and send us a status report using xen-bugtool? Perhaps one of our developers will be able to spot something in it that helps explain the issue.

jr-m4

3 pools updated. RPU went fine, where one is HA. A couple of test-backups went fine as well.

robertblissitt

Greetings, @majorp93 . I have always heard that Dynamic Memory should not be used in XenServer/XCP-ng as it is not 100% stable, and that has been my experience as well.

lmolina

We have just released a security update for a critical Linux kernel vulnerability CVE-2026-98432 / VSA-2026-056.

Full details are available on the blog: https://xcp-ng.org/blog/2026/11/04/november-2026-security-updates-2-for-xcp-ng-8-3-lts/

manilx

@lmolina And you couldn't have waited yesterday's update for ONE DAY!

Give me a break, another 1hr updating.....

It's GREAT that you address security updates.... BUT come on.

gduperrey

@manilx

If we could have waited, we would have. However, the xen security update released yesterday, given its critical nature, did not allow for that.

Please rest assured that we are aware of this issue and are doing our utmost to keep the number of releases to a minimum. We are also discussing how to communicate regarding the most critical updates and how to limit the need for reboots.

acebmxer

applying the updates on hosts at work. So far 2 out of 3 pools updated succesfully. however when i go to attempt to apply updates on the last pool i see this...

Screenshot 2026-11-04 105107.png

Screenshot 2026-11-04 104921.png

ThierryC01

@lmolina When will we be able to update or patch everything from XO6? It's kind of a bummer to switch from a slick UI to the legacy, yet functional one, just to apply some patches.

john205

Hi,
There is a bug in the blog post:

https://xcp-ng.org/blog/2026/11/04/november-2026-security-updates-2-for-xcp-ng-8-3-lts/

"apply the iptables-based mitigation described below"

but no mitigation is described!

Thanks,

John

lmolina

@john205 said:

"apply the iptables-based mitigation described below"

Thanks for reporting the mistake. The mitigation is described in the VSA.

The blog is now fixed!

lmolina

@acebmxer said:

applying the updates on hosts at work. So far 2 out of 3 pools updated succesfully. however when i go to attempt to apply updates on the last pool i see this...

@acebmxer, thanks for the feedback. We have no explanation at the moment. So far, all our tests have been successful. We may be missing a specific scenario that triggers this error.

Do you have any additional information in the host logs?

If not, could you export and send us a status report using xen-bugtool? One of our developers may be able to spot something that helps explain the issue.

mpiton

@acebmxer that banner comes from XO, not from the hosts. The previous RPU on Tilton Pool 1 stopped because Host 1 didn't come back within 20 minutes of its reboot (XO waits for the host to be enabled again with a restarted toolstack), and Host 2 is still pending. As long as an RPU is left incomplete, XO won't start a new one on that pool. That's why the button is greyed out.

What I'd do:

Check that Host 1 is up, enabled, and running the new packages.
Click Finalize. If the failed run left something it had changed (HA, WLB, load balancer, backup schedules, a disabled host, VMs moved or halted), XO refuses and lists it. Put those back, or force it if you're fine leaving them as they are. Forcing only lists them in the task, it doesn't change anything on the pool.
Run the RPU again to update Host 2. If the master is already up to date but the other host isn't, XO asks you to confirm first.

If that host is just slow to boot (long POST, RAID init, that kind of thing), you can raise restartHostTimeout in the [xapiOptions] section of the xo-server config. The default is 20 minutes.

If it never came back enabled at all, then the host logs lmolina asked for are still the way to go.

acebmxer

@lmolina, @mpiton

I was able to get the two host in the pool updated. I did finalization and it did the updates on host 1 but would not kick of the updates on the second host. I put that host into maintenance mode and did the updates and rebooted.

Do you still want to pull anything.. My guess the error was last round of updates as I never touched the pool till just then to apply the updates.

Edit - @lmolina - have downloaded the logs via the xen-bugtool the file size is large where would you like for me to upload or to my google drive ok?

mpiton

@acebmxer good to hear the pool is up to date. Your guess makes sense: the banner shows the last RPU XO recorded on that pool, so if you hadn't touched it since, the timeout is from that earlier run.

One thing I'd like to understand: Finalize only closes the record, it doesn't install anything. Did you start a new RPU after that, and did it stop after Host 1? If so, could you post the error from that
"Rolling pool update" task in XO? Its trace files would help too, they're in /var/lib/xo-server/data/rpu-traces on XOA (the exact path is in the task's traceFile property). The rpu-<poolId>-<timestamp>.ndjson file for that run is enough.