XCP-ng 8.2 updates announcements and testing

JeffBerntsen

@gduperrey
Applied on my test systems and all seems to be working well here.

stormi

@Louis There's no immediate evidence that the update candidates that this thread is about are related to your issues, so I second @gduperrey's request that you open one or more separate threads for your issues.

Expected feedback in this thread is something like : "I was on a fully updated XCP-ng 8.2.1 pool which worked well and then I installed the update candidates, and now I notice something doesn't work anymore" (regression due to the update candidates) or "I have tested this and that after installing the update candidates, and it looks fine".

AlexD2006

Updated and tested:

one single Host
lab-Pool (3 Hosts) - NFS Storage
lab-Pool (4 Hosts) - iscsi Storage

Everthing seems to work as expected.
(new VM, live-migration, snapshots, clone VMs, import/export VMs)

Ajmind 0

updated and tested:

test pool (2 hosts) iscsi storage
no problems so far.
(live-migration, snapshots, changed master in pool)

guest tools updated on
Debian 10 / 11 / Rocky Linux 8.5

AlexD2006

Sorry for my impatience.
Is there any news on ETA?

We are actually planning a maintenance downtime for firmware Upgrades and some other changes on a bunch of hosts and it would be cool do the updates on the same time slot to avoid double reboot/shutdown in short time.

Kind Regards
Alex

olivierlambert

Ping @stormi

stormi

If no last minute issue is discovered with the updates, they should be released next week.

AlexD2006

@stormi
Thx for your reply.
I try to wait so i can do it all in one Task.

Kind Regards
Alex

gduperrey

The update is published. Thanks for your tests!

Blog post: https://xcp-ng.org/blog/2022/10/05/october-2022-maintenance-update/

Louis

I am completely lost in relation to the way new software or updates are released.

If I download the actual file, I get exactly the same file as I used to get for months
there is an 8.2.1 which is not visual in the release overview
I would have expect that an update has the name 8.2.2 ........

So, I am lost .....

ravenet

@Louis said in Updates announcements and testing:

I am completely lost in relation to the way new software or updates are released.

If I download the actual file, I get exactly the same file as I used to get for months

there is an 8.2.1 which is not visual in the release overview

I would have expect that an update has the name 8.2.2 ........

So, I am lost .....

This is not a major release triggering a dot version update. This is a set of patches.

yum update

Louis

IMHO every set of patches should lead to a new version number and a changed initial download,
so if this is only a small update than it could be 8.2.1.1

My opinion of course but I would like to see a far more traceable update process

olivierlambert

Take a look at what other distros are doing: at some point, Debian will add a new "patch version". Initially you had Debian 11.0, but after some time and patches added, there's a bump (now we are at Debian 11.5).

There's not a patch increment at each update released

Louis

This is not a new available patch like the ones which become available on any OS every day!

It is a tested set of patches which become available as a "package". So I stay which my opinion that it is lets say a "dot-release". With a new number, a new download and a version history.

And yep of course you can update via the regular update method .

olivierlambert

@Louis said in Updates announcements and testing:

This is not a new available patch like the ones which become available on any OS every day!

Why? It's exactly that. It's up to us to decide if we want to group them more or less (depending on the urgency of the patch) but that's entirely on us.

stormi

The only reason we group them is so that you get notifications about available patches less often, as they're not security patches nor urgent fixes. We could also have released them as soon as they were ready, but you would have had to update more often.

stormi

@Louis said in Updates announcements and testing:

IMHO every set of patches should lead to a new version number and a changed initial download,
so if this is only a small update than it could be 8.2.1.1

My opinion of course but I would like to see a far more traceable update process

Changing version numbers may have unwanted adverse effects in third party software which interacts with XCP-ng and relies on versions to determine whether they consider themselves compatible or not. This happened with cloudstack and the 8.2.1 release, which was nothing but an updated 8.2 LTS. Each time a version number changes, they think they need to qualify the solution again. So I would not change version numbers lightly. Plus, when version numbers change, users may think there were more changes than just a maintenance update of the LTS release, and be wary of updating.

Regarding updated ISO images each time we release patches, we might do this automatically at some point in the future. But an updated installer image must be fully re-tested each time there's a change. It's not as simple as just bumping a version number and updating a few packages in an ISO image.

gduperrey

New security update candidates (xen, linux-firmware, edk2, xapi)

Xen and XAPI are being updated to mitigate some vulnerabilities:

XSA-410: Two privileged users in two guest VMs, in collaboration, can crash the host or make it unresponsive.
XSA-411: Correct a flaw in XSA-226 that allows DoS attacks from guest kernels to harm the whole system.
XSA-413: The management service on the host can become unresponsive or crash by the means of an unauthenticated user on the management network.

In this release, there are also the following fixes and improvements:

XAPI, issues resolved:
- When you had an active VIF connected on dom0, you couldn't delete that VIF or the associated network, including VLAN.
- When certificates contain the \r character, the xe host-get-server-certificate command can incorrectly output it.
xen, linux-firmware, edk2:
- Issues resolved:
  - Sometimes a VM freezes when a graphics-intensive application run
  - Sometimes guest UEFI firmware hangs
- Improvements:
  - AMD microcode is updated to version 2022-09-30
  - Improvements to Xen diagnostics.

Test on XCP-ng 8.2

From an up to date host:

yum clean metadata --enablerepo=xcp-ng-testing
yum update edk2 linux-firmware xen-dom0-libs xen-dom0-tools xen-hypervisor xen-libs xen-tools forkexecd message-switch xapi-core xapi-tests xapi-xe xcp-rrdd xenopsd xenopsd-cli xenopsd-xc --enablerepo=xcp-ng-testing
reboot

Versions:

edk2-20180522git4b8552d-1.4.6.xcpng8.2
linux-firmware-20190314-5.xcpng8.2
xen-*: 4.13.4-9.26.1.xcpng8.2
forkexecd-1.18.1-1.1.xcpng8.2
message-switch-1.23.2-3.2.xcpng8.2
xapi-*: 1.249.26-2.1.xcpng8.2
xcp-rrdd-1.33.0-6.1.xcpng8.2
xenopsd-*: 0.150.12-1.2.xcpng8.2

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

~2 days.

JeffBerntsen

@gduperrey
Installed on my test lab systems, 2 very old AMD systems with shared NFS storage with a mix of different types of guests. All working so far.

gskger

@gduperrey Update installed successfully on my 2 host playlab with shared NFS TrueNAS Core storage on a 10G network. Let's see how VM usage works during the next days.