XCP-ng 8.3 updates announcements and testing

stormi

This is a thread dedicated to testing update candidates for XCP-ng 8.3 before they are released to everyone.

We will announce it here everytime there is a new update candidate in our testing repositories, so that you can test them and give feedback before they are pushed to everyone through the updates repository.

Follow this thread

Use the bell on top of this thread to watch it, and make sure you enable email notifications in your forum settings. This way, you will be notified each time there's a new update candidate that needs feedback.

How to install the update candidate

This will be described in each announcement.

If a package breaks something, you can downgrade to the previous version:

yum downgrade package1 [package2 ...]

Then run any tests you find appropriate for the installed updates, and report here.

Most update candidates won't stay for long in the testing stage, so each update is to be tested as soon as possible.

What to test

The most important task is to make sure any update introduces no regressions. Test basic functionality related to the updated component, test that your setup is still functional. As a bonus, you can also test more complicated scenarios that involve the component.

If you can, when the update fixes a bug or security issue, try to reproduce before installing the update, then try to ensure the update does what it says it does.

If the update brings new features, it's good to test them too.

If you can only test parts of the above, it's still good. Just say so when you report here.

How to report

Say what and how you tested, and give the results, either positive or negative. When in doubt about your results, just ask!

Let's start

Now see you at the end of this thread, for any updates candidates currently being tested!

stormi

New security update candidates for XCP-ng 8.3 LTS (xen, intel-microcode)

Two new XSAs were published on November 12th 2024.
Intel published a microcode update on the November 12th 2024.

XSA-463 an unprivileged guest making two quick accesses to the VGA memory can deadlock a host.
XSA-464 an unprivileged PVH guest may access sensitive information from the host, control domain or other guests.

SECURITY UPDATES

xen-*:
- Fix XSA-463 - Deadlock in x86 HVM standard VGA handling. A mistake in the locking of process of the "standard" VGA memory makes it possible for a guest to make 2 quick accesses and create a deadlock that will hang the host.
- Fix XSA-464 - libxl leaks data to PVH guests via ACPI tables. The ACPI tables for PVH guests initialization left the excess memory space with its previous content, which was then copied to the guest memory as it was, resulting in possible leak of sensitive information. This doesn't affect XCP-ng in its normal configuration, as only HVM and PV-in-PVH (not affected) guests are supported.
intel-microcode:
- Latest Intel microcode update, published on November the 12th:
  - Security updates for INTEL-SA-01101
  - Security updates for INTEL-SA-01079
  - Updated security updates for INTEL-SA-01097
  - Updated security updates for INTEL-SA-01103
  - Multiple other updates for functional issues.

Other updates

XO Lite: updated to version 0.5.0, fixing its loading without internet access and bringing some other improvements. Changelog: https://github.com/vatesfr/xen-orchestra/blob/xo-lite-v0.5.0/%40xen-orchestra/lite/CHANGELOG.md

Test on XCP-ng 8.3

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

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

Versions:

Security updates:

xen: 4.17.5-4.xcpng8.3
intel-microcode: 20241016-1.xcpng8.3

Maintenance update:

xo-lite: 0.5.0-1.xcpng8.3

What to test

Normal use and anything else you want to test.

Test window before official release of the update

~ 2 day because of security updates.

flakpyro

@stormi Updated a test machine running only couple VMs. Everything installed fine and rebooted without issue.

Machine is:
Intel Xeon E-2336
SuperMicro board.
One VM happens to be windows based with an Nvidia GPU passed though to it running Blue Iris using the MSR fixed found elsewhere on these forums, fix continues to work with this version of Xen.

Andrew

@stormi Installed on several test and pre-production machines.

XCP-ng-JustGreat

Latest version 8.3 candidate updates installed and are working fine on three-host home lab pool. Received a couple of repo errors for a certain mirror, but yum tried another mirror and it completed successfully. After updates were applied, performed live migrations between hosts with no problems and updated a Windows 11 Version 24H2 VM to the November 2024 cumulative update without problems. (VM is currently running Citrix Tools 9.3.2 without issues.)

gduperrey

Update published: https://xcp-ng.org/blog/2024/11/15/november-2024-security-update-for-xcp-ng-8-3/

Thank you for the tests!

flakpyro

@gduperrey Installed on a 2 host AMD based test pool, as well as our 5 host Intel based production pool without issue using rolling pool update. Everything migrated, updated then migrated back perfectly.

Also installed on my home server without issue.

Greg_E

Has the kernel changed to a newer version, or still 4.xx.xx?

gduperrey

@Greg_E No, the kernel version has not changed.
There is no kernel update in this update series either.

dxym

The blog(https://xcp-ng.org/blog/2024/11/15/november-2024-security-update-for-xcp-ng-8-3/) states the following:

Host reboots are necessary after this update.

However, the command output indicates:

# needs-restarting -r
No core libraries or services have been updated.
Reboot is probably not necessary.

Which one is correct?
It might be better to reboot the host, but not everyone checks the blog regularly.

gduperrey

@dxym It is always important to follow the instructions given on the forum or on the blog. In both cases, we indicate that the hosts must be restarted.
This way, we are sure that the hosts will apply the changes coming from the updates, like here changes on Xen and the Intel microcode.

stormi

needs-restarting is a tool from CentOS, which is not aware of the reality of XCP-ng. It's not even able to detect that a Xen or a microcode update requires a reboot. So, as Gaël says.