XCP-ng 8.3 updates announcements and testing

gb.123

Did minor testing. Seems ok.
Haven't tested Backups.

Andrew

@stormi Upgrade problem... I upgraded a good working busy 8.2.1 server to 8.3 (using the new ISO). The upgrade went well without error. No guest VMs were changed.

Same issue in XO (Master 7be70) and XOA (5.107.2), so it must be an XCP issue. There are three new problems (all was working before);

XCP coretemp no longer loads/works. Error: coretemp coretemp.0: Adding Core 0 failed
XO Host CPU stats and Load are now reported as zero (It's a busy machine, they are not zero)
XO All guest VMs report zero CPU usage. Some just report No stats. for CPU. They do have current recognized guest tools (Linux and Windows). They do report other stats (memory, network, disk).

Other older XCP 8.3 hosts/guests are working.

stormi

@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

Andrew

@stormi Got it... I missed that one for coretemp. Vates ticket opened for the XOA stats problem after 8.3 upgrade.

stormi

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

stormi

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.

JeffBerntsen

@stormi @olivierlambert I did see it! Contratulations and a huge thank you for the new LTS release!

gb.123

@stormi
Just for clarification sake (I know this might have been said before), installing patches is the same as upgrading from iso in this case ?
(Unlike with previous update where it was mandatory to upgrade using iso)

stormi

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

john.c

Congratulations to all the staff at Vates at getting XCP-ng version 8.3 to the LTS stage.

TrapoSAMA

Hi!!

Then 8.3 dont show LTS flag in the console?

Thx

gduperrey

@TrapoSAMA No, as with 8.2, this isn't something displayed in the console.
Since it doesn't indicate that an updated 8.2 is actually 8.2.1, only the major version is displayed. We have the same behavior here.

However, as with many other products, this is clearly displayed on the XCP-ng homepage, in addition to the announcement on the blog.

stormi

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

gduperrey

New security and maintenance update candidate

A new XSA (Xen Security Advisory) was published on the 1st of July, and an update to Xen addresses it. We also publish other non-urgent updates which we had in the pipe for the next release.

Security updates

xen-*:
- Fix XSA-470 - An unprivileged guest can cause a hypervisor crash, causing a Denial of Service (DoS) of the entire host.

Maintenance updates

http-nbd-transfer: moved some logs into debug to reduce log spam
sm:
- XOSTOR: avoid a rare migration error when the GC would run on our migration snapshot
- Use GC daemon code for LINSTOR like other drivers (no changes for users)
  This updated package is already included in the refreshed 8.3 installation ISOs.
xapi:
- Fix remote syslog configuration being broken on updates
- Fix several RRD (stats collection) issues and make the plugins more robust:
  - Cap Derive values within a certain range without making them NaN
  - Use a computed delay time for RRD loop to prevent gaps in metrics collection
  - Avoid duplicating datasources on plugin restore
  - Protect against a resource leak in the plugins
  - Avoid running out of mmap-ed pages in xcp-rrdd-cpu for large numbers of domains
  - Prevent exceptions from escaping and introducing gaps into metrics collection
  - Avoid missing metrics from new and destroyed domains
- Prevent xapi concurrent calls during migration from indirectly make each other fail (already fixed in the refreshed ISOs)
- Fix a deadlock in xenopsd due to atom nesting (already fixed in the refreshed ISOs)
xo-lite: update to 0.12.0
- [VM/system] Display system information in vm/system tab
- [Host/system] Display system view information in host/system tab
- [Host/Dashboard] Fix color of tag list (PR #8731)
- [Table] add pagination on table (PR #8573)
- [Pool/system] Display pool information in pool/system tab (PR #8660)
- [VM/Dashboard] Display VM information in dashboard tab (PR #8529)
- [Tab/Network] Updated side panel in tab network behavior for mobile view (PR #8688)
- [Stats] Fix graphs that were sometimes not displayed or displayed incorrectly (PR #8722)

Optional packages:

Alternate Driver: Updated to newer version.
- broadcom-bnxt-en-alt: Update to version 1.10.3_232.0.155.5

Test on XCP-ng 8.3

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

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

Versions:

http-nbd-transfer: 1.6.0-1.xcpng8.3
sm: 3.2.12-3.2.xcpng8.3
xapi: 25.6.0-1.9.xcpng8.3
xen: 4.17.5-13.2.xcpng8.3
xo-lite: 0.12.0-1.xcpng8.3

Optional packages:

Alternate drivers:
- broadcom-bnxt-en-alt: 1.10.3_232.0.155.5-1.xcpng8.3

What to test

Normal use and anything else you want to test.

Test window before official release of the updates

~2 days.

flakpyro

@gduperrey Updated both of my test hosts.

Machine 1:
Intel Xeon E-2336
SuperMicro board.

Machine 2:
Minisforum MS-01
i9-13900H (e-cores disabled)
32 GB Ram
Using Intel X710 onboard NIC

Everything rebooted and came up fine. Ran a backup job which also completed without issue. Using a mix of ext, XFS and NFS SRs

ph7

@gduperrey
Ran some test on my old i7 and it seems to work fine

bufanda

Did install on my lab pool

2 HP EliteDesk 800 G3 mini

One with i7 6700T, one with i5 6500T
Both 32GB RAM
iSCSI SR, NFS SR and local NVMe SR. VMs from all SR run. Migration during update worked. Migration of VMs after update worked. Backups (exporting VMs) is working
Didn't see any issue so far.

One thing the pool had the qcow2 patches installed since XAPI and sm packages gto updated I guess it won't support qcow2 at the moment right?

dthenot

@bufanda Hello,

There is equivalent sm packages in the qcow2 repo for testing, XAPI will be coming soon.
You can update while enabling the QCOW2 repo to get the sm and blktap QCOW2 version and get the XAPI version letter if you want.

bufanda

@dthenot No worries, just wanted to make sure I understand the expected behavior when I had the qcow2 patches installed.

dthenot

@bufanda You just need to make sure to have a sm and blktap qcow2 version.
Otherwise, having a normal sm version would drop the QCOW2 VDI from the XAPI database and you would lose VBD to VM aswell as name of VDI.
So it could be painful depending on how much you have
But in the case, you would install a non QCOW2 sm version, you would only lose the QCOW2 from DB, those would not be deleted or anything. Reinstalling a QCOW2 version then rescanning the SR would make them re-appear. But then you would have to identify them again (lost name-label) and relink them to VM.
We try to keep our QCOW2 version on top of the testing branch of XCP-ng but we could miss it