/etc/ssh/sshd_config is supposed to be supported. That's the only supported way to alter the SSHD configuration without the changes getting overwritten in future updates.

I'll see with the team why it isn't (anymore?).

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

Not one, but two blog posts, today!

https://xcp-ng.org/blog/2026/05/05/april-2026-security-and-maintenance-updates-for-xcp-ng-8-3-lts-2/
https://xcp-ng.org/blog/2026/05/05/qcow2-is-now-ga-in-xcp-ng/

I just published, in the xcp-ng-testing repository, what is hopefully the very last round of fixes before the feature goes live.

You’ll have about three days to share your feedback if you’d like to be part of this final sprint .

Details at https://xcp-ng.org/forum/post/104961

Yes, new update candidates, again!

This is, in theory, the very last round of fixes before QCOW2 support comes as an official update!

What changed

Storage

• sm + blktap:
  • Fix a never ending coalesce task and an associated tapdisk crash which would leave the QCOW2 VDI corrupted. Thanks @emerson for reporting the issue!
  • Attempting to migrate a QCOW2 towards a SR that supports QCOW2 but prefers VHD will now automatically create a QCOW2 disk at the destination if the disk is bigger than 2 TiB. Previously, it was documented as a known issue that it would attempt to create a VHD and fail.
  • Another known issue fixed: attempting to resize a QCOW2 VDI with a snapshot on a LVM-based SR no longer fails.
• xapi:
  • prevent long migrations for failing due to expiring XAPI session.
  • More security fixes related to XSA-489.

Versions:

• blktap: 3.55.5-6.6.xcpng8.3 -> 3.55.5-6.7.xcpng8.3
• sm: 3.2.12-17.6.xcpng8.3 -> 3.2.12-17.7.xcpng8.3
• xapi: 26.1.3-1.9.xcpng8.3 -> 26.1.3-1.10.xcpng8.3

Test on XCP-ng 8.3

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

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.

What to test

Anything related to storage, be it with VHD or QCOW2 disks.

Test window before official release of the updates

~3 days

@pkgw Our initial theory is that you might have applied updates at some point which had replaced the sm package with one that didn't support qcow2. Then a next update would have brought it back, but the metadata lost.

@pkgw Would it be possible to open a ticket and a support tunnel so that @Team-Storage can look at it?