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

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

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

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.

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

@mthird said:

Spoke to soon. While the updates succeeded, one of the nodes is rebooting every few minutes due to an HA self-fence.

Could you open a dedicated thread and ping me there?

@rzr said:

As this is my first time installing these update candidates,

Actually we moved first batch of packages that landed in testing to candidates repo, to avoid mix up in the second batch that just landed in testing repo. Since nothing new appeared in candidate you should probably already had them before, home this is clarifying what is actually happening

Next yum update should just pull the latest stable versions?

Not if you already have installed then from testing (or candidate) repo, because versions are same, it's only the distribution channel that change, no impact for testers.

I'm not sure what you understood from @scarfantennae's question, but that we moved packages from xcp-ng-testing to xcp-ng-candidates doesn't seem on topic here.

The question is: "now that I've applied this update candidates from the testing repositories, am I definitively in testing mode?".

The answer is: no, because:

• The --enable-repo switch only applies to the two commands you ran: clearing the cache and applying updates. The repositories remain disabled by default, so yes, next time you update you'll only get stable updates if there are any.
• Either the exact packages that you installed will be pushed as official updates (in which case there will be nothing for you to do), or we'll push newer updates that will supersede them automatically next time you update.

Hope it's clear.

@rzr said:

Thank you again for feedback we will try to address reported issues on next batch (to come soon).

Note that some issues are not related to this specific update batch, but might have been introduced on previous ones (TBC).

Not knowing myself what it meant, I asked Philippe: it's about the nslookup issue. And potentially the issue reported by @ph7 but it's not clear to me yet if there was a problem with XCP-ng or Xen Orchestra.

Anyway, basically this means that there's no known issue caused by this batch of updates, and that we'll keep addressing any relevant issue in the next updates if necessary, as usual.

@Andrew We'll publish a fix for bind-utils, indeed, even if it's not part of the officially supported additional packages for XCP-ng, as it can be useful and we don't have strong reasons not to fix it.

Regarding other packages affected by the openssl update, @rzr handled many of them as part of the OpenSSL update back then already, so now we'll mostly rely on reports such as yours in case we missed something which is actually used by the user community.

Forwarding to @Team-Storage

@probain said:

Now receiving UUID_INVALIDwhen trying to disable CBT on a VDI.
Perhaps a result of fixing the "List index out of range"-bug?

Let me call @Team-Storage about this.

We pushed the updates to the xcp-ng-updates repository: https://xcp-ng.org/blog/2026/05/21/may-2026-updates-3-for-xcp-ng-8-3-lts/

Changed since the initial announcement, xen was updated with the proper vulnerability fix and an update to sm was added to fix an issue on LVM-based SRs with CBT enabled.

Thanks everyone for your feedback!

Indeed we only list source packages. xapi's source RPM alone creates a lot of RPMs each time, for example. In this case, all those with version 26.1.4-3.1.xcpng8.3.

Ping @Team-Storage again, about the last comment.

@andrewperry We're preparing a release of the workaround script that our developers made.

As for the proper fix, it's actually more complex that it may seem, and developers have been working on it for a few months already. If I understood correctly, it's related to the way VDI snapshots are reverted, with responsibilities shared between the storage stack and XAPI, the fixes requiring deep changes in both stacks.

@Chuckz said:

So far no reply to that question but I only asked earlier today. I presume it is a complex technical question that cannot be answered without discussion with upstream Xen developers.

Actually I think Stormi is just extremely busy.

I'm pretty sure core isolation requires nested virtualization and thus is not supported at the moment.

XenServer developers recently contributed a patch series that removes a bit of technical debt from Xen, doing which was one of the steps towards proper nested virtualization support. There still remains a large amount of work onwards.

Ping @Team-Storage

Indeed, no reboot required if those are the only patches that you are applying, as indicated in the blog post.

This is it, it's now out!

https://xcp-ng.org/blog/2026/05/05/qcow2-is-now-ga-in-xcp-ng/