I had this tab still open which lets me realize that despite we packaged vmfs6-tools and updated the documentation at https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/#local-migration-same-host, we didn't inform you here.

Now it's done

OEL 8 & 9 wouldn't contain the fix unless they applied extra patches for this to the RHEL 8 & 9 kernel(s). I'll let the hypervisor team check the current status.

I've had this thread in my TODO list for long.

I'm not sure what the different options we have mean for users.

As r8125-module is installed by default, we'll want to avoid breaking it for existing users. Would using the new code risk causing regressions? Maybe that's what you meant but I'm not sure. Does our current r8125 driver support both 8125 and 8126, and not 8127? Or just 8125?

If we can't update the driver without causing regressions, then can we offer an alternate driver based on the new code for each chip (8125, 8126, 8127), and what amount of work might this represent?

The target would be XCP-ng 8.3. In XCP-ng 9.0 we'll have a newer kernel and newer drivers anyway.

CCing @Team-Hypervisor-Kernel for their opinion.

@olivierlambert said in Limiting access to xo-lite to a specific IP address or ssubnet:

About iptables, there's /etc/sysconfig/iptables but I'm not sure it's the right place to put manual modification, that's why I pinged the @Team-OS-Platform-Release

In a way that's the right place, but one needs to be careful with modifications there.

This changes nothing regarding brute-forcing. XAPI still listens to RPC requests on port 443.

Without changing iptables rules (that's not very flexible and could conflict with XAPI's handling of the rules), there's a way to disable the webserver.

https://docs.xcp-ng.org/management/manage-locally/xo-lite/#disabling-xo-lite

Also note that there is a simpler approach if you don't need an "all-in-one" ISO image: driver disks.

You can build driver disks using https://github.com/xcp-ng/driver-disks and load them during the installation.

You can also ask us to provide driver disks for alternate drivers for which we haven't built them yet. We make them available on https://mirrors.xcp-ng.org/isos/drivers/8.x/...

That's also something we need to document in the official docs. It's mentioned in the release notes for 8.3 but not in other sections of the documentation.

And fixes for XCP-ng 8.2 are coming but they require more work to backport the patches.

I moved this discussion to its own topic, as we need the other one for update candidate testing.

That's actually a question for @Team-XAPI-Network

@gduperrey said in XCP-ng 8.3 updates announcements and testing:

Since it doesn't indicate that an updated 8.2 is actually 8.2.1, only the major version is displayed.

Not a very good example actually (but what's true is that for 8.2 we didn't add a "LTS" mention next to the version number in the system either).

But yes, we decided not to increment the version number for XCP-ng 8.3.0. That breaks compatibility with some third party software because they wouldn't recognize a "8.3.1".

However we're working on a secondary version identifier that would allow you to know your precise patch level.

@gb.123 Yes. If you think it's not clear in the blog post, I'll think how I can word it.

Current wording:

This announcement does not represent a new release. It applies to the existing XCP-ng 8.3.

If you're already running XCP-ng 8.3, you're on the LTS version. There's no need for a full upgrade. Standard package updates will keep your system current.

New update candidates for you to test!

A new batch of non-urgent updates is ready for user tests before a future collective release.

• openssh: Fix low priority CVE-2025-26465 DoS attack when VerifyHostKeyDNS is "yes" or "ask" (The Default value has not changed: "no")
• samba: Fix vulnerabilities which are very unlikely to be exploitable on XCP-ng but are reported by security scanners.
• xcp-ng-release: This update adds a certificate to resolve a TLS handshake error, particularly when deploying XOA from CLI using curl.

Test on XCP-ng 8.2

From an up to date host:

yum clean metadata --enablerepo=xcp-ng-testing
yum update --enablerepo=xcp-ng-testing
reboot

The usual update rules apply: pool coordinator first, etc.

No specific steps for these updates for XOSTOR users.

Versions

• openssh: 7.4p1-23.3.2.xcpng8.2
• samba: 4.10.16-25.el7_9
• xcp-ng-release: 8.2.1-16

What to test

Normal use and anything else you want to test. The closer to your actual use of XCP-ng, the better.

Test window before official release of the updates

None defined, but early feedback is always better than late feedback, which is in turn better than no feedback

You probably saw it, but just in case: https://xcp-ng.org/blog/2025/06/16/xcp-ng-8-3-is-now-lts/

Today marks several important updates for XCP-ng 8.3. In a nutshell:

• It officially becomes a Long-Term Support (LTS) release, as previously announced when it was first released on October 7th, 2024.
• We are releasing updated installation images ("ISOs") that include installer improvements and all updates published since the original release.
• XOSTOR, our hyperconverged storage solution powered by LINSTOR, is now officially supported on XCP-ng 8.3.
• A new, dedicated upgrade ISO is available to support upgrading from an 8.2 pool that includes a XOSTOR storage repository.

The above issue is solved in packages that we haven't released as an update yet, that @Andrew tested.

We do advise to jump to 8.2 from earlier releases, before jumping to 8.3.

@Andrew Does restarting the toolstack bring the stats back?

CC @Team-XAPI-Network

Regarding coretemp, @r1's module doesn't work anymore with Xen 4.17. See https://github.com/xcp-ng/xcp/issues/669. A possible workaround is using IPMI readings, when available. For a better solution, there's work needed in Xen.

(CC @Team-Hypervisor-Kernel, FYI)

mikhail-shevtsov-wiregate created this issue in xcp-ng/xcp

open XCP 8.3 coretemp module doesn't detect any sensors #669

said in XCP-ng 8.3 updates announcements and testing:

here are the pre-release ISO images for a refreshed XCP-ng 8.3 installer

Last call

A few days late because internal tests led to a few fixes, here are the pre-release ISO images for a refreshed XCP-ng 8.3 installer:

https://repo.vates.tech/tmp/

$ cat SHA256SUMS
22deae59e7c5cff7d4691c447af9dbf27b29a372748c1844c280bdc212ef2a5f  xcp-ng-8.3-20250606-linstor-upgradeonly.pre3.iso
9a5dcc8d98949ee207d28307b8b94320d1ffd24841e34ca74e1c0f0422e5ecab  xcp-ng-8.3-20250606-netinstall.pre3.iso
4d6f5a99da0d70920bc313470ad2b14decab66038f0863ca68a2b81126ee2977  xcp-ng-8.3-20250606.pre3.iso

1. No need to upgrade XCP-ng 8.3 with these. It is not a new release. It's refreshed installation images, with all updates included.
2. When we release them, at the same time, XCP-ng 8.3 will be officially labeled LTS. Again, the existing XCP-ng 8.3 that you already use. Not a new XCP-ng release.
3. This is also when XOSTOR becomes officially supported in XCP-ng 8.3 .
4. 8.2 to 8.3 upgrade with XOSTOR required a specific treatment, to get a compatible LINSTOR version installed on upgrade. This constraint we had to handle was caused by Linstor not supporting rolling upgrade. For this, we provide a dedicated upgrade ISO (-linstor-upgradeonly). After the upgrade, if there are available updates in 8.3 for linstor, then you can follow the usual update process (which also contains specific steps for XOSTOR such as updating linstor-satellite first on all hosts and restarting the services on all of them, still due to linstor not supporting rolling update. That's something that XOA's RPU handles automatically since a few releases, by the way).
5. Some packages are slightly newer in the ISOs than in 8.3's update repositories. The only reason is because I didn't want to push updates so soon right after the previous batch, so that XOA doesn't tell you that you are outdated and need to update. But of course these updates will also come to existing XCP-ng 8.3 hosts soon. They're not just for the ISOs.
6. The netinstall ISO image will pull the original 8.3.0 packages at the moment, so if you want to use it you first need to create a netinstall reposistory somewhere by extracting the full installation ISO, and point at it.

Regarding testing we are interested on all kind of feedback. Installations, upgrades with and without XOSTOR, and everything you want to test that seems pertinent to ensure there are no regressions when compared to the original 8.3.0 installation ISOs.

said in XSA-468: multiple Windows PV driver vulnerabilities - update now!:

@Tristis-Oris

3. We do plan a way to remove the warning for VMs that you would choose.

That's now done and will be included in the next update to the latest update channel for XOA. VMs with the HIDE_XSA468 tag will not be included in the vulnerability detection.