XCP-ng 8.3 betas and RCs feedback π
-
This will be fun. The console keeps losing connectivity with the VMs so I wasn't able to suspend them before rebooting the server.
Oh, that's not good. No change after rebooting. It's still borked. What's the best way to reach out to you, @stormi ?
-
@CJ You can send me a PM here.
-
@stormi Uh, how do I do that?
Also, I think the problem may be due to when I was attempting to set up a private network. I had deleted all of that but it seems to be stuck in a loop trying to find sdn-controller-ca.pem. Therefore the update never completes and it just tries again.
-
@CJ Then this would not be directly related to the update, but maybe just to the reboot that was performed by XOA after it?
-
Problem solved on chat. Our last update doesn't like it at all when a certificate was manually removed from the system without letting XAPI know.
So we had to:
- revert the update and restart the toolstack - XAPI works again
touch /etc/stunnel/certs/sdn-controller-ca.pem
to create back a dummy file for the missing cert, so thatxe
will accept to remove it from database (it fails if it can't find the file for which you're trying to remove the database entry )xe pool-certificate-uninstall name=sdn-controller-ca.pem
- update again
- perform the update of the rest of the pool hosts
I added a comment in the issue related to the patches we included in this update to fix certificate fingerprints: https://github.com/xapi-project/xen-api/issues/5955
-
@brezlord So I managed to reproduce the issue: basically what's happening is
lspci
shows a shortened version of the PCI ID and the XAPI expects to parse a complete version of the ID so it fails while parsing. Removing manually the passthrough in the xen command line and re-adding it via XAPI should solve the issue.
Now that the API is available this shouldn't happen anymore as the only supported way of passing through a device is via XAPI.Regards
-
@BenjiReis Thanks for reproducing it. I suspected it was because of the manual pass-through.
-
We just published XCP-ng 8.3.0 Release Candidate 2. This should be the last one.
https://xcp-ng.org/blog/2024/09/17/xcp-ng-8-3-release-candidate-2/
I want to bring your attention to this:
I already installed XCP-ng 8.3 RC1 (or another pre-release). How do I upgrade to RC2?
You can upgrade as usual through Xen Orchestra or by using yum update. A reboot is required. However, we recommend upgrading via the installation ISO image before putting XCP-ng 8.3 into production. If you upgrade now for RC2, you wonβt need to do it again for the final production release, and upgrading early helps us with testing.
-
@stormi For the last sentence, do you mean that if we use the ISO to upgrade to RC2 we won't need to use the ISO for final?
-
@CJ Yes
-
Reworded to:
You can upgrade as usual through Xen Orchestra or by using yum update. A reboot is required. However, we recommend upgrading via the installation ISO image before putting XCP-ng 8.3 into production. If you upgrade now using the RC2 installation image, you wonβt need to upgrade again to the final production release (a simple update will then be enough). Upgrading early helps us with testing.
Does it seem clearer?
-
@stormi Upgraded my homelab pool (2 Protectlis VP6670) via ISO.
Master first and then 2nd host.Only thing was that the master did not ask for network config and the 2nd host did ask for network configuration to use the repository BUT I did choose local repository...
After that all went fine.
What's the cli command to check the version?
-
If yum update says no update or no updates visible in XO, you are good
-
@olivierlambert No updates shown.
One thing I miss, my cli history on the hosts....
Should have expected this and save it. -
@manilx experienced the same thing while upgrading our test pool. Pool master did not ask, other hosts did ask for network config.
-
@flakpyro guess it should not differ from master to other hosts. It's a bit disconcerting.
-
Our main pool upgraded with no issues with the ISO. Same as the above posters though, master doesn't ask for network config but other hosts in the pool do...thankfully all the bonds and networking came up without issue on them.
Will attempt updating our other locations after hours but I don't foresee any problems
-
Upgrade to RC2 worked fine so far with netinstall ISO in ventoy on a 8 gen i5 HP laptop. And a "full" ISO on its own USB on a Lenovo Thinkcentre Ryzen 5 2400GE
-
I tried to upgrade my test cluster from 8.2.1 but encountered a few problems. I was basically trying to follow the instructions at https://docs.xcp-ng.org/installation/upgrade/ by doing a install from media (USB Key).
- screen resolution. Perhaps an option for a lower resolution console would be reasonable?
(I tried linking a screenshot but the forum software objected. It can be found at https://photos.app.goo.gl/Zkby9aHUEBYUzkfe8 )
My KVM display was upset by the resolution selected and put a splash screen in the middle of the display saying "Input sync out of range. Please select 1024x768 60Hz for best performance."
note: this only happens with a UEFI boot. It does not appear with a BIOS boot.
- lack of information about what non-standard things are in the way so they can be found and removed.
Another photo: https://photos.app.goo.gl/ZuTNKiXctUCBkSmf7
"Only product installations that cannot be upgraded have been detected. Continuing will result in a clean installation, all existing configuration will be lost. ..."
This box started as a default 8.2 host and was upgraded to 8.2.1 via yum. The only truly non-default thing is the package that enables waiting for NFS RSs to become available before starting any dependent VMs (plug-late-sr-1.1-1.xcpng8.2.noarch).
I removed that one RPM but still had the same error.
Hmm. I just remembered the first time I tried this I did get a warning about changing from BIOS to IPMI so I went in and changed boot mode. I guess I should go try booting from BIOS and see if that changes/removes the error....
Yep, sure does. No error at all when booting in BIOS mode. So, the message about installing with UEFI instead of BIOS might want to be re-worded to make it clear this is not an upgrade option. (and to perhaps suggest the best method for making said change?)
I've held off on applying the upgrade incase you wanted me to test something.
-
Upgraded 3-node pool (home lab: Dell OptiPlex 7040 SFF x 3) from 8.3 RC1 to 8.3 RC2 using bootable ISO. It worked perfectly for me. As others have noted, it does ask you to select the management interface when upgrading the slave nodes. Once you do that, it automatically populates all of the previously configured network parameters for that host so you are really only confirming the existing values. The OptiPlex 7040's (i7-6700) all have Intel VPro AMT so they are running headless. The MeshCommander program is used to access the VPro console on each host. A DisplayPort display emulator dongle is needed to keep the integrated-GPU active in order to be able to see the console and firmware setup screens with this configuration. It's effectively a poor man's iDRAC. So far, everything is working well on 8.3 RC2.