XCP-ng 8.3 betas and RCs feedback 🚀

flakpyro

@manilx experienced the same thing while upgrading our test pool. Pool master did not ask, other hosts did ask for network config.

manilx

@flakpyro guess it should not differ from master to other hosts. It's a bit disconcerting.

rmaclachlan

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

ph7

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

nomad

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.

XCP-ng-JustGreat

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.

archw

@brezlord

A week or two ago a bunch of updates went out. Were these part of RC2? I updated via yum back then and since this announcement nothing new has come up.

Is there a command line command to run to verify what is installed now is RC2?

jivanpal

@archw Yes, if you installed any 8.3 beta or RC and have recently performed a yum update and reboot, then you are up to date with the packages that are included in the 8.3-rc2 release.

nomad

I decided to try upgrading my master to 8.3 in BIOS mode (see yesterday's post about UEFI failure). The upgrade seems to have gone well overall but when I try to access my NFS-mounted SRs I get

"SR_BACKEND_FAILURE_140(, Incorrect DNS name, unable to resolve., "

Evidently not everything was preserved in the upgrade.

stormi

@nomad A host is not supposed to lose its DNS configuration upon upgrade, but it looks like it did. Can you check from the CLI?

nomad

@stormi It was user error.

/etc/hosts wasn't preserved and the storage NAS isn't in DNS.

nomad

@nomad said in XCP-ng 8.3 betas and RCs feedback :

plug-late-sr

Looks like this RPM isn't available in 8.3 yet. Please remember to make it available as we need it.

It was created for Ticket#7714169

thanks!

stormi

@nomad @ronan-a is on it. It's built but not made available in the base repository yet.

ph7

@ph7 said in XCP-ng 8.3 betas and RCs feedback :

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

2 days ago I upgraded my fully patched Ryzen 5 RC1 to RC2 by ISO.
Unfortunately I also upgraded my XO to commit aa490.
All backup jobs since then has triggered CPU performance alerts on my backed up delta, offline VM, XCP-ng host and the VM running XO.
I will update the XO to latest commit today.
Are there any changes in RC2 that could cause this?
I have only received 1 alert on high memory earlier.

pierre.c

ISO update (as recommended) for my pool of three XCP-ng 8.3 RC1 hypervisors.
Everything went perfectly for each server.
I had to reinstall the additional packages (traceroute vim-enhanced mtr etc...), re-enable LLDP advertisements on the network interfaces (lldptool -L -i eth0 adminStatus=rxtx) and recreate the multipath configuration file (/etc/multipath/conf.d/huawei.conf).
In short, nothing seems abnormal.

Tristis Oris

can't install zabbix on 8.3.

yum install -y zabbix-agent2 zabbix-agent2-plugin-*

Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Resolving Dependencies
--> Running transaction check
---> Package zabbix-agent2.x86_64 0:7.0.3-release1.el7 will be installed
--> Processing Dependency: libpcre2-8.so.0()(64bit) for package: zabbix-agent2-7.0.3-release1.el7.x86_64
---> Package zabbix-agent2-plugin-ember-plus.x86_64 0:7.0.3-release1.el7 will be installed
---> Package zabbix-agent2-plugin-mongodb.x86_64 0:7.0.3-release1.el7 will be installed
---> Package zabbix-agent2-plugin-mssql.x86_64 0:7.0.3-release1.el7 will be installed
---> Package zabbix-agent2-plugin-postgresql.x86_64 0:7.0.3-release1.el7 will be installed
--> Finished Dependency Resolution
Error: Package: zabbix-agent2-7.0.3-release1.el7.x86_64 (zabbix)
           Requires: libpcre2-8.so.0()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

at 8.2 i only need to enable more repos, but 8.3 already use it own Vates mirror for Centos.

yum install pcre2 --enablerepo=epel,base,sources

Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * epel: ftp-stud.hs-esslingen.de
No package pcre2 available.
Error: Nothing to do

stormi

@ph7 I don't see much changes which may lead to this result at first sight.

stormi

@Tristis-Oris said in XCP-ng 8.3 betas and RCs feedback :

yum install pcre2 --enablerepo=epel,base,sources

It is indeed missing. I must have missed something when I replicated the repository from CentOS vault.

nomad

Ok, I'm feeling dumb. I just mounted the guest tools ISO (hosts -> hostname -> console -> "select disk(s)" pulldown, select "guest-tools.iso") and I'm seeing kinda old versions of xe-guest-utilities (-2 instead of -12).

: || lvd@vm42 ~ [1023] ; ls -l /media/Linux/xe-guest-utilities*rpm
-r--r--r--. 1 root root 985556 Dec 11 2023 /media/Linux/xe-guest-utilities-7.30.0-2.i386.rpm
-r--r--r--. 1 root root 985384 Dec 11 2023 /media/Linux/xe-guest-utilities-7.30.0-2.legacy.i386.rpm
-r--r--r--. 1 root root 1246820 Dec 11 2023 /media/Linux/xe-guest-utilities-7.30.0-2.legacy.x86_64.rpm
-r--r--r--. 1 root root 1247000 Dec 11 2023 /media/Linux/xe-guest-utilities-7.30.0-2.x86_64.rpm

When I do the same on my production 8.2.1 pool I see

: || lvd@chipmunkdev ~ [1000] ; ls -l /media/Linux/xe-guest-utilities*rpm
-r--r--r--. 1 root root 985488 Feb 7 2024 /media/Linux/xe-guest-utilities-7.30.0-12.i386.rpm
-r--r--r--. 1 root root 985308 Feb 7 2024 /media/Linux/xe-guest-utilities-7.30.0-12.legacy.i386.rpm
-r--r--r--. 1 root root 1246760 Feb 7 2024 /media/Linux/xe-guest-utilities-7.30.0-12.legacy.x86_64.rpm
-r--r--r--. 1 root root 1246948 Feb 7 2024 /media/Linux/xe-guest-utilities-7.30.0-12.x86_64.rpm

Should I be looking somewhere else for the most recent xe-guest-utilities?

ph7

@stormi said in XCP-ng 8.3 betas and RCs feedback :

@ph7 I don't see much changes which may lead to this result at first sight.

Same alert today with commit 63a88
Should I report this in Home / Xen Orchestra / Backup ?