XCP-ng 8.3 updates announcements and testing

rzr

New maintenance update candidates for XCP-ng 8.3 LTS

This release batch contains mostly fixes, tools version update, a some improvements.

Note: the previous batch of updates has not been released yet, so if you haven't tested it, you will see more updates than described here when you'll install the update candidates. Refer to the previous announcements.

What changed

Virtualization & System

xen: Add support for xenpm get-core-temp to query CPU temperature on Intel platforms.
- Use xenpm get-core-temp to get the temperature on Intel's CPU, to fallback unsupported coretemp. Doc update being reviewed.
grub: Sync with XenServer 8.4: Fix a rare out-of-memory error.
dracut: Fixes
- Fix to force reboot/shutdown/halt.
- Fix issue where the omission of 'override' kernel modules from the initrd image could, in rare instances, prevent a freshly installed XCP-ng host from booting.

Control Plane

xapi: Update to 26.1.11, add fixes and improvements.
- Fixed an issue where a newly installed host wouldn't be able to join a pool due to incompatible features exposed by storage.
- Fix shutdown VMs not being migratable due to errors generated when the VM was running.
- Allow moving VMs back to DHCP from static IP with configure_ipv4/6.

Network

stunnel: Fixed stunnel only considering one of the self-signed certificates with the same DN.

Tools

xcp-ng-pv-tools: Update to XCP-ng Windows Guest Tools 9.1.200 (full changelog).

Drivers

mpi3mr-module: Update to version 8.17.1, adding newly supported SAS5116 devices.

Optional:

mellanox-mlnxen-alt: Fix build error with kernel 4.19.19-8.0.42.1+.

Storage

kmod-drbd: Update to 9.2.18 (full changelog)
- Improve XOSTOR stability when evacuating/evicting an host.
xcp-ng-release-linstor: Relocate config file to v8.3-linstor repository.

Versions

dracut: 033-538.xcpng8.3 -> 033-539.1.xcpng8.3
gpumon: 24.1.0-84.1.xcpng8.3 -> 24.1.0-91.1.xcpng8.3
grub: 1:2.06-4.0.2.1.xcpng8.3 -> 1:2.06-4.0.5.1.xcpng8.3
mpi3mr-module: 8.6.1.0.0-1.xcpng8.3 -> 8.17.1.0.0-1.xcpng8.3
stunnel: 5.60-5.xcpng8.3 -> 5.60-6.1.xcpng8.3
xapi: 26.1.4-3.2.xcpng8.3 -> 26.1.11-1.1.xcpng8.3
xcp-featured: 1.2.1-1.xcpng8.3 -> 1.2.1-2.xcpng8.3
xcp-ng-pv-tools: 8.3-17.xcpng8.3 -> 8.3-18.xcpng8.3
xen: 4.17.6-9.1.xcpng8.3 -> 4.17.6-9.3.xcpng8.3

Optional packages:

mellanox-mlnxen-alt: 5.4_1.0.3.0-2.xcpng8.3 -> 5.4_1.0.3.0-3.xcpng8.3

XOSTOR users: specific update procedure

Some XOSTOR packages are provided in separate repository, and should be installed along xcp-ng regular packages, using the following commands:

yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates,xcp-ng-linstor-testing
yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates,xcp-ng-linstor-testing
reboot

Note: linstor packages themselves have not been updated, only kmod-drbd and xcp-ng-release-linstor. Thus, this time it's not necessary to restart the satellites before rebooting.

The following XOSTOR-specific package received updates (and must be updated in the same transaction, which the above update commands will do):

xcp-ng-release-linstor: 1.4-2.xcpng8.3 -> 1.5-1.xcpng8.3 (from xcp-ng-testing repo)
kmod-drbd: 9.2.16-1.0.xcpng8.3 -> 9.2.18-2.0.xcpng8.3 (from xcp-ng-linstor-testing repo)

Test on XCP-ng 8.3

Warning: XOSTOR users should skip this part and follow the instructions of the previous section.

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

As usual, normal use and anything else you want to test.

Test window before official release of the updates

~2 days

We would like to thank users who reported feedback since our last call for testing:

@Andrew, @XCP-ng-JustGreat, @acebmxer, @bufanda, @flakpyro, @jeffberntsen, @majorp93, @manilx, @marcoi, @ph7.

acebmxer

@rzr

Just installed updates on host 1. Once host rebooted it took an extra min or two to reconnect to xo, but did finally connect. Applying updates on host 2 now.

Update - host2 no issues. Once reboot complete it connected to xo as expected without delay.

I see these updates include -

xen: Add support for xenpm get-core-temp to query CPU temperature on Intel platforms.
Use xenpm get-core-temp to get the temperature on Intel's CPU, to fallback unsupported coretemp. Doc update being reviewed .

My host are AMD so can verify these. I might be able to deploy a Intel host later tonight. Will this come to AMD later?

TeddyAstie

@acebmxer said:

@rzr

Just installed updates on host 1. Once host rebooted it took an extra min or two to reconnect to xo, but did finally connect. Applying updates on host 2 now.

Update - host2 no issues. Once reboot complete it connected to xo as expected without delay.

I see these updates include -

xen: Add support for xenpm get-core-temp to query CPU temperature on Intel platforms.

Use xenpm get-core-temp to get the temperature on Intel's CPU, to fallback unsupported coretemp. Doc update being reviewed .

My host are AMD so can verify these. I might be able to deploy a Intel host later tonight. Will this come to AMD later?

AMD rely on a different method to expose the temperature, that don't require this xenpm-based approach. In principle, it should already work with plain sensors (through k10temp), but our driver may not be up to date for recent AMD CPUs.

flakpyro

No issues on the same test hosts i used for the last 2 batches of updates.

acebmxer

@TeddyAstie said:

@acebmxer said:

@rzr

Just installed updates on host 1. Once host rebooted it took an extra min or two to reconnect to xo, but did finally connect. Applying updates on host 2 now.

Update - host2 no issues. Once reboot complete it connected to xo as expected without delay.

I see these updates include -

xen: Add support for xenpm get-core-temp to query CPU temperature on Intel platforms.

Use xenpm get-core-temp to get the temperature on Intel's CPU, to fallback unsupported coretemp. Doc update being reviewed .

My host are AMD so can verify these. I might be able to deploy a Intel host later tonight. Will this come to AMD later?

AMD rely on a different method to expose the temperature, that don't require this xenpm-based approach. In principle, it should already work with plain sensors (through k10temp), but our driver may not be up to date for recent AMD CPUs.

From AMD 7950x

[17:51 xcp-ng-haznrrtw ~]# xenpm get-core-temp
[Package0] Unable to fetch temperature (61 - No data available)
[CPU0] Unable to fetch temperature (61 - No data available)
[CPU2] Unable to fetch temperature (61 - No data available)
[CPU4] Unable to fetch temperature (61 - No data available)
[CPU6] Unable to fetch temperature (61 - No data available)
[CPU8] Unable to fetch temperature (61 - No data available)
[CPU10] Unable to fetch temperature (61 - No data available)
[CPU12] Unable to fetch temperature (61 - No data available)
[CPU14] Unable to fetch temperature (61 - No data available)
[CPU16] Unable to fetch temperature (61 - No data available)
[CPU18] Unable to fetch temperature (61 - No data available)
[CPU20] Unable to fetch temperature (61 - No data available)
[CPU22] Unable to fetch temperature (61 - No data available)
[CPU24] Unable to fetch temperature (61 - No data available)
[CPU26] Unable to fetch temperature (61 - No data available)
[CPU28] Unable to fetch temperature (61 - No data available)
[CPU30] Unable to fetch temperature (61 - No data available)

Intel 13700k

[17:50 xcp-ng-kulwlwbp ~]# xenpm get-core-temp
Package0: 28°C
CPU0: 26°C
CPU2: 23°C
CPU4: 23°C
CPU6: 25°C
CPU8: 25°C
CPU10: 24°C
CPU12: 23°C
CPU14: 25°C
CPU16: 24°C
CPU18: 24°C
CPU20: 28°C
CPU22: 28°C

Andrew

@rzr Up and running on several pools. Rolling pool reboot worked (after fixing a few non-upgrade issues). Running normal operations, replication, backup, migration, NFS, ISO, etc.

xenpm get-core-temp is mostly working. Not working on AMD Ryzen 5 5600U as expected. HP DL G8 Intel E5-2673 v2 shows 64 CPUs. The actual CPUs show correctly, the higher ones (that don't exist) show [CPUxx] Unable to fetch temperature (19 - No such device). HP DL G10 Intel Xeon(R) Gold 62xx and Desktop Core i7 11th and 7th are good.

bufanda

@rzr Installed on my 2 node lab pool, so far no issues.

TeddyAstie

@Andrew said:
HP DL G8 Intel E5-2673 v2 shows 64 CPUs. The actual CPUs show correctly, the higher ones (that don't exist) show [CPUxx] Unable to fetch temperature (19 - No such device)

Machines with hotpluggable CPUs are a pretty tricky case, the logic tries up to "maximum possible CPU" and fails here because the CPU is not online (No such device error). That doesn't prevent the temperature from getting fetched for CPU that exists.
I can try to add a check to hide this specific error, so it's doesn't create noise for offline CPUs on such machines.

ScarfAntennae

Temps seem to be working on i5-10500T:

[11:46 delta-2 ~]# xenpm get-core-temp
Package0: 57°C
CPU0: 56°C
CPU2: 57°C
CPU4: 56°C
CPU6: 56°C
CPU8: 55°C
CPU10: 57°C

As this is my first time installing these update candidates, is there no other action required after doing:

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

Meaning I am not permanently in testing mode now? Next yum update should just pull the latest stable versions?

rzr

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.

stormi

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