Indeed, no reboot required if those are the only patches that you are applying, as indicated in the blog post.
Team - OS Platform Release
Private
Posts
-
RE: XCP-ng 8.3 updates announcements and testing
-
RE: Second (and final) Release Candidate for QCOW2 image format support
I just published, in the
xcp-ng-testingrepository, what is hopefully the very last round of fixes before the feature goes live.You’ll have about three days to share your feedback if you’d like to be part of this final sprint
.Details at https://xcp-ng.org/forum/post/104961
-
RE: XCP-ng 8.3 updates announcements and testing
Yes, new update candidates, again!
This is, in theory, the very last round of fixes before QCOW2 support comes as an official update!
What changed
Storage
sm+blktap:- Fix a never ending coalesce task and an associated tapdisk crash which would leave the QCOW2 VDI corrupted. Thanks @emerson for reporting the issue!
- Attempting to migrate a QCOW2 towards a SR that supports QCOW2 but prefers VHD will now automatically create a QCOW2 disk at the destination if the disk is bigger than 2 TiB. Previously, it was documented as a known issue that it would attempt to create a VHD and fail.
- Another known issue fixed: attempting to resize a QCOW2 VDI with a snapshot on a LVM-based SR no longer fails.
xapi:- prevent long migrations for failing due to expiring XAPI session.
- More security fixes related to XSA-489.
Versions:
blktap: 3.55.5-6.6.xcpng8.3 -> 3.55.5-6.7.xcpng8.3sm: 3.2.12-17.6.xcpng8.3 -> 3.2.12-17.7.xcpng8.3xapi: 26.1.3-1.9.xcpng8.3 -> 26.1.3-1.10.xcpng8.3
Test on XCP-ng 8.3
If you are using XOSTOR, please refer to our documentation for the update method.
yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates rebootThe usual update rules apply: pool coordinator first, etc.
What to test
Anything related to storage, be it with VHD or QCOW2 disks.
Test window before official release of the updates
~3 days
-
RE: Second (and final) Release Candidate for QCOW2 image format support
@pkgw Our initial theory is that you might have applied updates at some point which had replaced the
smpackage with one that didn't support qcow2. Then a next update would have brought it back, but the metadata lost.
