XCP-ng 8.3 betas and RCs feedback 🚀
-
I just pushed a few updates. Nothing worth mentioning, just a few minor fixes before the RC. The update might look big because XAPI was rebuilt, so many packages generated by this build are updated.
The interface-rename fix is to follow next, when it's ready.
-
@stormi updated 2 hosts (2 pools) and rebooted. No issues.
-
@NoHeadroom said in XCP-ng 8.3 beta
:I've notice the same python3 glitch.
You could manually amend /etc/sysconfig/network-scripts/interface-rename-data/static-rules.conf if that's an option for you.Better avoid this kind of change to a file that was generated by the installer and is not meant to be touched.
Anyway, I've pushed the fixed
interface-renameto thexcp-ng-baserepository. Just update, and this will be fixed. -
@stormi Update of my XCP-ng 8.3 test server through CLI (
yum update) and rebooted. All VMs work as expected. -
@stormi
I ran the updates and now my graphs in XO-lite are back.
weird -
@stormi said in XCP-ng 8.3 beta
:Better avoid this kind of change to a file that was generated by the installer and is not meant to be touched.
Anyway, I've pushed the fixed
interface-renameto thexcp-ng-baserepository. Just update, and this will be fixed.Thanks for the quick fix and the hard work getting 8.3 to production.
Anyway, it's better to have an option b) if option a) fails
-
@NoHeadroom said in XCP-ng 8.3 betas and RCs feedback
:Anyway, it's better to have an option b) if option a) fails
As you wish, but I won't support option b) in any case, so I prefer to mention it
-
I'm excited about the 8.3 production release. With that said, I joined XCP-ng with the 8.3 release, and it has been rock solid. I mean, there has been a few bugs, but nothing impacting the stability.
I also faced problems with controlling power-state of my VMs (reboot) yesterday, but after installing the latest patches to my host (through XO), and rebooted the host, things worked again, as expected.
@stormi said in XCP-ng 8.3 betas and RCs feedback
:Reboot after update
...
Question : What's the "upgrade path" for us starting on 8.3 alpha. Is it just a question about updating the system, and nothing else?
Or, should I plan some kind of operation, so I can "switch" to a stable 8.3 release at some time? Like switching from unstable to a stable branch in Manjaro. Maybe it should make sense to include something about that, in a upcoming final release for 8.3. I bet other people with ar8125NIC also jumped directly on 8.3 alpha, due to the build-in support for that NIC.Just a notice for the "newbies" like myself
:
Remember to update your Xen Orchestra from time to time. I can't really explain why, but I've not thought about that at all. So yesterday I updated from a march 2023 commit, to the most recent one. Not much was changed, but I guess some kind of incompatibilities could be expected, after more than one year without a single update of Xen Orchestra
. -
@exetico said in XCP-ng 8.3 betas and RCs feedback
:Remember to update your Xen Orchestra from time to time. I can't really explain why, but I've not thought about that at all. So yesterday I updated from a march 2023 commit, to the most recent one. Not much was changed, but I guess some kind of incompatibilities could be expected, after more than one year without a single update of Xen Orchestra
.Actually there have been HUGE changes in 1 year! You should check them out (only the last weeks big changes to how backups/snapshots work).
Keep it updated and follow Vates' blog to have the news and changes. -
March 2023 means almost 16 releases since, and you can see the amount of change done each release, multiply it by 16…
Here is all the blog posts with the tag release: https://xen-orchestra.com/blog/tag/release/
You missed a LOT
-
@olivierlambert I clearly didn't spend much time in the updated interface, yesterday evening
! It was not meant as a "Well, no changes, boring and lazy devs", or anything like that. I really enjoy XO.I normally update all other things quite often. But I simply didn't think of the fact, that XO was isolated in it's own VM, and living it's own dreams.
@manilx said in XCP-ng 8.3 betas and RCs feedback
:Keep it updated and follow Vates' blog to have the news and changes
Thank you. I'll start following that for news. My limited use of XO does mean that I'm not really digging into the deeper levels. This is a great shortcut for that
. -
Updated 2 hosts to 8.3 RC1 without any issues and all VM's are functioning correctly. I've been running 8.3 since I moved my personal stuff away from ESXi. Only ran into a few issues in the past with graphs not appearing in XO/XOA but the team was already working on fixes and came thru as always. Keep up the good work XCP-NG/XO teams!
-
Needing some assistance on where to start with the upgrade. I want to upgrade my 3-node cluster. As of right now all 3 nodes are on 8.2.1 but are BIOS boot, and it appears you need UEFI for 8.3 RC1. What is the best way to go about upgrading to where I wont lose data/vm’s? Understand I will most likely need to do a fresh install on each host.. What’s recommended? Should I start with the node that holds the master first on doing the fresh install?
-
@exetico said in XCP-ng 8.3 betas and RCs feedback
: Question : What's the "upgrade path" for us starting on 8.3 alpha. Is it just a question about updating the system, and nothing else?
Or, should I plan some kind of operation, so I can "switch" to a stable 8.3 release at some time? Like switching from unstable to a stable branch in Manjaro.There are instructions in the blog post of the release candidate: https://xcp-ng.org/blog/2024/07/12/xcp-ng-8-3-release-candidate-1/
Currently, updating normally is enough. However, the blog post describes manual changes you have to do (deleting lines in SSH configuration files).
In the end, when the final release is published, then I advise that everyone upgrades using the installation ISO, to clean the system of leftovers of the intermediary test packages. Avoid doing it now, though, because we found a last minute issue specifically on upgrades from 8.3 pre-releases: TLS certificates of the pool are not retained, and this may cut the communications between members of a pool.
-
- For any upgrade (and in any case), make sure you have good backups, just in case.
- The upgrade process doesn't touch your storage repositories nor VM metadata, so your VMs will still be there (but still apply 1.)
- You can upgrade even if your boot mode is Legacy BIOS, but the installer will warn you that sooner or later, this won't work anymore. It's easier when you have enough resources to move your VMs around while reinstalling. I'm leaving the details on how to achieve this to others because I'm on vacation :). There's also our technical support to help on this kind of migration.
-
@stormi reading https://xcp-ng.org/blog/2024/07/12/xcp-ng-8-3-release-candidate-1/
I found this:"Current XCP-ng 8.3 users will need to review these configuration files. Make sure to remove any lines starting with Ciphers, MACs, KexAlgorithms, and HostKeyAlgorithms if they are present. This ensures that future changes to the defaults made by our security team will be applied."
Checking /etc/ssh/ssh_config I find these lines at the end:
Ciphers aes128-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1 KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1 HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsaChecking /etc/ssh/sshd_config I find the following in the middle of the file:
# Ciphers, MACs, KEX Algorithms & HostKeyAlgorithms Ciphers aes128-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1 KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1 HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsaSo just to confirm/double check:
I'm supposed to delete those lines as per RC1 info, right?
I don't like to edit system files without having to do so
Thx in advance! -
I'm having issues updating via ISO on supermicro motherboard. I have a netinstall iso mounted (though I've also tried a full ISO via usb), and can get to the initial "install" bootup prompt from 8.3 RC1 image.
Issue is that once "install" option is chosen, "Bootinginstall" shows for about a minute, screen blanks and normal bootup occurs instead. No sign that booting the install has ever occurred.
Do I need to wipe the SSD with the 8.2 and just do a clean 8.3 install? Is there anything I can do to get a more detailed view of logs / or what else could have gone wrong?
If this has been covered, I apologize, I tried reading through 500+ messages in this tread, but nothing stood out to me describing a similar issue.
Supermicro X10SRM-TF motherboard with E5-2699 V4 processor, latest bios, UEFI boot.If I choose install, or let it run automatically, same results.
This is shown for about a minute
Than ready to boot prompt flashes for a sec.
And it goes to a normal xcp-ng bootup...
-
@manilx said in XCP-ng 8.3 betas and RCs feedback
:I'm supposed to delete those lines as per RC1 info, right?
Yes
-
@stormi thx! reboot afterwards needed?
-
@stormi Follow up on the steps I took to possibly help others that may have similar scenarios.
- Migrated all VM's off of my Master (Node1) and rebooted, upgraded to 8.3 from ISO still on BIOS mode.
- Once Node1 was back online, I went ahead and upgraded Node2, and Node3 one at a time. I would just move my current VM's around to the host I wasn't upgrading. Finally had all 3 hosts on 8.3.
- Started the UEFI transition. I started with Node1 which was the master, but I changed the master to be on Node3. I went ahead and migrated all the VM's off the Node1, shutdown, pull the HDD (So I would have a backup) and put a new HDD in. Changed my boot mode to UEFI and did a fresh install. I removed Node1 from the cluster in XO. Once back online, I went ahead and just added Node1 back into my cluster and let XO do its magic of bringing everything back online.
Only issue I ran into was a
POOL_JOINING_HOST_TLS_VERIFICATION_MISMATCHwhen I attempted to add the Node1 to the cluster. I followed the steps listed here: https://xcp-ng.org/forum/post/63470Running
xe pool-enable-tls-verificationandxe host-emergency-reenable-tls-verificationon Node3 which was still the master and was then able to get the new server added to the pool.- Moved the master back to Node1 and started the process over again on Node2 and 3.
