XCP-ng 8.3 updates announcements and testing

[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:

1. Check that Host 1 is up, enabled, and running the new packages.
2. 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.
3. 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.

[acebmxer]

@mpiton

Correct. Sorry yes did have to press rolling pool update after the Finalize. The first host was not connecting to the pool after 2-3 min from reboot. I disabled and renabled the pool got host 1 connected again. waiting for host2 to start it didnt so i then put into maintenance mode and applied the updates and rebooted.

rpu-64466023-8ef0-f5de-54ed-57e30eca644b-20261104T163948197Z.ndjson.txt
rpu-finalize-64466023-8ef0-f5de-54ed-57e30eca644b-20261104T163942579Z.ndjson.txt

https://drive.google.com/drive/folders/1wIBRm-8P5lqSOZmhX1ACWdSFLt3wbAQ9?usp=drive_link - to the other logs.

[mpiton]

@acebmxer thanks, the trace explains it. After the Finalize, the new RPU patched Host 1 and rebooted it at 11:42 your time, then waited for it to come back. When you disabled and re-enabled the pool in XO (I assume Settings > Servers?), XO dropped the connection the RPU was using and opened a new one. The running RPU kept watching the old connection, so it never saw Host 1 come back, and it failed on the 20 minute timeout at 12:02. That's also why it never started on Host 2. The stop you sent at 11:51 didn't cut that wait short either, which we'll look at on our side.

So next time, leave the pool connected during an RPU even if the master takes a few minutes to come back. XO reconnects on its own and gives each host 20 minutes.

The bugtool isn't needed for this run. Can you confirm two things: was "disable and re-enable" the toggle in Settings > Servers, and is Tilton Host 1 the pool master?

[acebmxer]

@mpiton said:

@acebmxer So next time, leave the pool connected during an RPU even if the master takes a few minutes to come back. XO reconnects on its own and gives each host 20 minutes. Can you confirm two things: was "disable and re-enable" the toggle in Settings > Servers, and is Tilton Host 1 the pool master?

Ok next time I wil just wait longer. yes that is correct. Only other thing to note if wasnt caught in the logs the pool is connected via xo-proxy.

[Greg_E]

@acebmxer

I will recommend a local monitor you can attach during RPU to make sure you can see what's happening. You can also go into the IPMI console and watch.

I'm old school, I still have a KVM switch on my stuff and used it during a recent move from temporary building back to permanent home. XCP2 didn't start up as expected and I had some fooling around to do. The KVM is often quicker than the IPMI option for me.

Probably going to do this update in the afternoon when things slow down a little, didn't realize we had more high priority bugs to fix. Damn AI! Have a firewall update I need to get done, and need to check Windows for the Paint update (yes paint has an exploit).

[acebmxer]

@Greg_E

these are Dell servers and yes i was connected over ipmi and saw it sitting at the main console screen with no errors visitable. Before i decided to take action and disconnect and reconnect the pool.

Again next update I will wait longer. Usually they are fast to reconnect i know the remote pools tend to take little longer but. its hard to wait.