-
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
-
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 .
-
@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.
-
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.
-
@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.1My 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.
-
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.
- Issues resolved:
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.
-
@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. -
@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.
-
@gduperrey So far, so good with normal operations.... I'm not affected by the issues but updated everything anyway (15 hosts). Intel Xeon, E5, Core 7th/10th/11th, AMD Opteron, AMD Zen3...
-
The update is published. Thanks for your tests!
Blog post: https://xcp-ng.org/blog/2022/10/14/october-2022-security-update/
-
New security update candidates (xen)
Xen is being updated to mitigate some vulnerabilities:
- XSA-326: Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored.
- XSA-419: Xenstore: Cooperating guests can create arbitrary numbers of nodes
- XSA-414: A malicious guest can cause xenstored to crash, resulting in the inability to create new guests or to change the configuration of running guests.
- XSA-415: Xenstore: Guests can create orphaned Xenstore nodes
- XSA-416: Xenstore: Guests can cause Xenstore to not free temporary memory
- XSA-417: Xenstore: Guests can get access to Xenstore nodes of deleted domains
- XSA-418: Xenstore: Guests can crash xenstored via exhausting the stack
- XSA-420: Oxenstored 32->31 bit integer truncation issues. A malicious or buggy guest can write a packet into the xenstore ring which causes 32-bit builds of oxenstored to busy loop.
- XSA-421: Xenstore: Guests can create arbitrary number of nodes via transactions
Test on XCP-ng 8.2
From an up to date host:
yum clean metadata --enablerepo=xcp-ng-testing yum update xen-dom0-libs xen-dom0-tools xen-hypervisor xen-libs xen-tools --enablerepo=xcp-ng-testing reboot
Versions:
- xen-*: 4.13.4-9.27.1.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.
-
@gduperrey I upgraded my home/lab machines. One replication backup machine updated. No problems so far but I was not affected by any of the bugs.
-
Tested here, seems to work
-
@gduperrey Updated my playlab and did some basic tests (create, copy, snapshot, (life-) migrate VMs and disks). Looking good so far.
-
@gduperrey Tested and working in my lab as well. So far, so good...
-
The update is published. Thanks for your tests!
Blog post: https://xcp-ng.org/blog/2022/11/04/november-2022-security-update/ -
@gduperrey Rolling update of my homelab through Xen Orchestra worked flawlessly. Thanks!
-
New update candidates (xen, microcode_ctl)
In this release, there are the following fixes and improvements:
- xen, microcode_ctl:
- Issues resolved: Minor bug fixes.
- Improvements: Intel microcode is updated to version IPU 2022.3.
Test on XCP-ng 8.2
From an up to date host:
yum clean metadata --enablerepo=xcp-ng-testing yum update microcode_ctl xen-dom0-libs xen-dom0-tools xen-hypervisor xen-libs xen-tools --enablerepo=xcp-ng-testing reboot
Versions:
Ā * xen-*: 4.13.4-9.28.1.xcpng8.2
Ā * microcode_ctl: 2:2.1-26.xs23.xcpng8.2What 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
No precise ETA, but the sooner the feedback the better.
- xen, microcode_ctl:
-
Applied on my EPYC host at home. Nothing specific to report
-
So far fine on an epyc 7002 and a xeon e5 v3