@olivierlambert said in XCP-NG server crashes/reboots unexpectedly:
Check the /var/log/xen* stuff (on top of my head, @stormi probably knows that better than me)
I think this would be the output of xl dmesg.
Also, if the kern.log file is empty, this means that there were no messages for this day, but older messages may be visible in kern.log.1, kern.log.2.gz, etc.
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.
@JeffBerntsen Do you have XOSTOR on the pool?
Two new XSAs were published on November 12th 2024.
Intel published a microcode update on the November 12th 2024.
xen-*:
intel-microcode:
yum clean metadata --enablerepo=xcp-ng-candidates
yum update --enablerepo=xcp-ng-candidates
reboot
The usual update rules apply: pool coordinator first, etc.
Security updates:
xen: 4.17.5-4.xcpng8.3intel-microcode: 20241016-1.xcpng8.3Maintenance update:
xo-lite: 0.5.0-1.xcpng8.3Normal use and anything else you want to test.
~ 2 day because of security updates.
This is the end for this nice and useful thread, as XCP-ng 8.3 is not a beta nor a RC anymore: it's a supported release now.
However, we still need your feedback, as we publish update candidates ahead of their official release, for users to test them.
Right now, there's a security update candidate which is to be tested.
I strongly invite everyone who is currently subscribed to this thread to now subscribe to the new, dedicated thread: XCP-ng 8.3 updates announcements and testing, and to verify that their settings allow sending notification e-mails and/or other forms of notification.
We also need you to test updates for XCP-ng 8.3. I created a new thread dedicated to XCP-ng 8.3, and renamed this present thread to make it dedicated to XCP-ng 8.2.
Please ensure you follow the new thread if you plan to help on testing XCP-ng 8.3.
New thread: https://xcp-ng.org/forum/topic/9964/xcp-ng-8-3-updates-announcements-and-testing
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.
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.
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.
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.
Say what and how you tested, and give the results, either positive or negative. When in doubt about your results, just ask!
Now see you at the end of this thread, for any updates candidates currently being tested!
This is absolutely something to write about in the release note of 8.3.Agreed, this should be in the release notes. I'll add it.
It's now in the release notes: https://docs.xcp-ng.org/releases/release-8-3/#pool-metadata-backup-temporarily-unavailable-from-console
@Prilly said in XCP-NG 8.3 xsconsole backup, restore pool metadata:
Snicky this one from vates
If you mean sneaky, I'm not sure I appreciate what this word implies.
This is absolutely something to write about in the release note of 8.3.
Agreed, this should be in the release notes. I'll add it.
when is it expected back?
I had a look, and it was fixed on XenServer side. So it will be back in XCP-ng 8.3 once we rebase on their latest updates. Hopefully before the end of the year.
How do you restore this metadata backup in xcp-ng 8.3 without the use of XO?
If you really can't use XO, you can use the same API that XO uses to implement the feature in its UI: XAPI. I don't know myself the exact end points that must be used for this back-up feature.
They removed it because of hard to fix security implications and plan to bring it back in a later update.
CCing @bleader too.
@sapcode said in openssl 1.1.1 update or manual build in XCP 8.2.1 possible ?:
Would it be safe to run yum remove openssl as the first step or would this break the XCP installation:
The second option. And actually it's not openssl you're looking for, it's openssl-libs, and removing it will not even work, as it attempts to remove yum and systemd which depend on it and are protected.
Note that we do offer openssl 1.1.1 through the xs-openssl-libs package, and that is what XAPI uses for communication instead of the system one. However you'd have to patch and rebuild curl or wget so that they use it, and this definitely voids your warranty.
You are going on a journey that is far more difficult than you initially expected, I fear. So I'd start questioning the initial needs again.
@Robert You can migrate VMs from a host not upgraded yet to a host which was upgraded. Some other operations are not possible. A partially upgraded pool is supposed to the a short transitioning state.
@jhansen Installing from RC1 then updating with yum update is not supported. The release notes state you must reinstall from prereleases of XCP-ng 8.3, unless you installed using XCP-ng 8.3 RC2 (and now that the final release is out, there's no reason to keep installing a pre-release).
@john-c As I mentioned in the release notes, @dinhngtu told me (and tested) that if Secure Boot is enforced, then Bitlocker doesn't fail on unexpected firmware changes.
Maybe worth giving it a try?
@jhansen said in XCP-ng 8.3 betas and RCs feedback 
:
My 8.2.1 servers were still running on BIOS boot. When updating to 8.3 RC I got the message that there was still a DOS table on the hard drive and the update from the USB stick was aborted.
A newly installed 8.3 server with UEFI cannot be integrated into the old 8.2 pool.Here is a small workaround:
2 USB sticks, one with 8.2.1 and one with 8.3 RC.
Take one server out of the pool, not the master.
Reinstall with UEFI on 8.2.1.
Integrate server into the old pool.
make server as new pool master.
The server can now be updated to 8.3 without any problems, the master is on UEFI and all pool information and VM are on 8.3.
Now just take all other servers out of the pool, do a clean 8.3 UEFI installation and put them back into the pool.
Let's add that there must be no VMs on local storage on the server you reinstall, of course. Other than that, I like this workaround!
CC @yann, do you think it's worth adding this to the release notes?
Given the diversity of issues reported above, and the fact that XCP-ng 8.3 is now released, I strongly suggest you all create new topics in the forum. You can reference them once in this thread to help them get attention, no problem with that.
@jhansen said in XCP-ng 8.3 betas and RCs feedback :
Something else, when updating from 8.2.1 to 8.3 RC.
Are you updating to 8.3 RC when the official 8.3.0 is now released?
Regarding xsconsole, I think it always had this issue where at some point it thinks (rightfully or not) that the screen is too small for it to run.