-
@stormi said in Updates announcements and testing:
November 2019 security update for XCP-ng
New security update candidates are available (XCP-ng 7.6 and 8.0). As usual, I will only release them to everyone after enough testing, so if you can please install the update candidates.
Instructions there: https://github.com/xcp-ng/xcp/issues/302
Please use the github issues to provide feedback so this thread here remains clean.
The security issues are serious and public, and I haven't had any feedback about the update candidates yet, so I'm doubling my call.
-
Last chance to test before I release them based only on our internal testing.
-
Updates published: https://xcp-ng.org/blog/2019/11/08/xcp-ng-security-bulletin-november-2019/
-
No problem here, RHEL 8 support for guest tools works as expected (tested on the last RHEL 8.1 release), good job
-
Updated a two node XCP-ng 8.0 homelab without any issues
-
updates ran with no problems
-
I did the November 2019 updates for XCP-ng 8 on a standalone host as well as a 3 node cluster. No problems so far.
-
Get ready for testing. New (previously unforeseen) security updates are coming soon for testing. You can thank hardware bugs in CPUs (and it's only starting)
-
Testing: November 2019 security update for XCP-ng, 2nd Impact
New security update candidates are available (XCP-ng 7.6 and 8.0). As usual, I will only release them to everyone after enough testing, so if you can please install the update candidates.
Instructions there: https://github.com/xcp-ng/xcp/issues/308
Please use the github issues to provide feedback so this thread here remains clean.
closed Nov 2019 security updates, 2nd impact #308
-
End of WE soon, still interested in feedback for release tomorrow.
-
@stormi intel only it seems?
-
There's a misunderdstanding when I ask for tests. What hardware you have doesn't really matter. Even if you don't have Intel CPUs, your hosts will receive the updates. So they are impacted. If there are regressions in the updates, you'll be impacted.
That's why what's the most important with all the updates I ask feedback for is not what they fix, it's what they don't break. A large number of "I installed them, things seem to still function normally" is what we really need.
Testing the actual changes the updates bring is a plus, but not a requirement to be able to contribute.
-
Security Updates released. Intel hardware again. You'll need to choose between safety and performance regarding one of the flaws if you are running untrusted guests. https://xcp-ng.org/blog/2019/11/18/security-updates-for-intel-hardware/
-
I just pushed a bugfix update for XCP-ng 8.0:
sm-2.2.3-1.0.3.xcpng8.0.If fixes a never-ending coalesce issues described at https://github.com/xcp-ng/xcp/issues/298 and https://bugs.xenserver.org/browse/XSO-966
If you had alread applied all the security updates, there's no hurry. You can wait for the next batch of security updates if you don't strictly require the fix. If you apply it alone, no reboot is required.
xe-toolstack-restartis enough.closed XCP-ng 8.0 / CH 8.0 coalesce issues #298
-
@stormi Thank you!
I'll be applying and validating the patch. -
@stormi the update actually solves the problem of zombies process, but the coalesce, all disks after backup/snapshot (removal) still continue with a 1 disk stuck in the leaf chain.
I am also testing the update made available in https://support.citrix.com/article/CTX265619 in an XS 7.1 pool.
-
I'm interested in the results because it's the same patch!
-
@stormi The perception I have is as follows in XCP8:
- After backup, all the disks were left with 1 disk frozen in the leaf tree.
- Even pausing the VM and rescanning disk, the coalesce process does not start.
For CH7.1 with the XS71ECU2020 update, the coalesce process completed 100% by pausing the VMs. We will now re-back it up and see if the coalesce runs again 100%.
I used standard times in LIVE_LEAF_COALESCE_TIMEOUT=10.
The new test will be with LIVE_LEAF_COALESCE_TIMEOUT=300. -
@stormi The strange thing is, I had to turn off the VMs, rescan disk and then turn on again.
The coalesce process began with the linked VMs (in production) and successfully completed. The following values have been changed at /opt/xensource/sm/cleanup.py :
LIVE_LEAF_COALESCE_MAX_SIZE = 1024 * 1024 * 1024 # bytes LIVE_LEAF_COALESCE_TIMEOUT = 300 # secondsWell, apparently everything ok... we will see in our next backup if it will be necessary to turn off the VMs for the coalesce to start and complete correctly.
-
@stormi After the informed change, the backup occurred with 100% success, on no disk in the coalesce chain.
We're migrating another cluster to XCP-ng 8!
Thanks for the support, quick return and attention.
