XCP-ng 8.3 betas and RCs feedback 🚀

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

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 ?

stormi

@ph7 If you can test with an older version of XO and see if the issue is still present, this might help understanding whether it's an XO issue or not. But I think you can also already create a dedicated topic where XO devs can tell if they see what this could be.

stormi

@nomad Good point!

So, they are the same tools (8.2 got the update later, based on that of 8.3), but the version is defined in a peculiar way (based on the release of the RPM, which I mistakingly re-initialized to 1 on XCP-ng 8.3). I'll fix this, but you can already use them if you need them.

nomad

@stormi If it's the exact same thing just with a different version number I can wait for a future update. I already have the -12 RPM in my yum repo for automatic install on all VMs.

I was looking to see if there was any notable changes from what we already had as well to see if an icon for AlmaLinux would show up in the home -> VMs list (everything else has an icon showing the OS running on the VM, just poor Alma is left all alone at the display ball.)

stormi

@nomad There are two key players in this icon thing: the guest tools who report the OS name (this already works), and then Xen Orchestra matching this to an icon. In Xen Orchestra 5, the icon set is not easy to expand, so the developers said this would be done in XO 6.

nomad

@stormi I'm glad to know I was slightly right about some of the way it works anyway.

imaginapix

Just to give some short feedback about upgrade from 8.3 beta to 8.3rc2 via ISO:

Pool master upgraded fine after selecting "Upgrade existing installation"
2nd host in pool asked for management network configuration after selecting "Upgrade existing installation", but after that everything upgraded fine
Both host show "cloud" instead a build number after the upgrade
Guest tools version number of/reseted to .2, but this is already discussed earlier

All in all very smooth upgrade and everything is running as before - great work from the Vates team !

stormi

@imaginapix The build number doesn't have any real signification for XCP-ng, in fact. We wanted to change it to a timestamps or something, but it was already late in the release process and even if we haven't found any reason to think changing the build number could break anything now, I decided to keep it as is just in case.