XCP-ng 8.3 betas and RCs feedback 🚀

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.

AlexanderK

will xcp-ng 8.3 work with cloudstack?

stormi

@AlexanderK We don't test it, but they use XAPI and the API doesn't change that much, so it should. We contacted them last april and they said any necessary changes on CloudStack side should be done after the release.

https://github.com/apache/cloudstack/discussions/8964

AlexanderK

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

@AlexanderK We don't test it, but they use XAPI and the API doesn't change that much, so it should. We contacted them last april and they said any necessary changes on CloudStack side should be done after the release.

https://github.com/apache/cloudstack/discussions/8964

when there was the update of 8.2.1 there have been many issues...
anyway...i think 8.3 is not an lts... so i will wait and check at a lab enviroments
Thanks for the reply!

stormi

@AlexanderK Then maybe you can remind them of the past issues so that they look at XCP-ng 8.3 ahead of time (especially knowing that we are going to release very soon)

stormi

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

@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.

Aaaaand... It's fixed now.

stormi

Here are new updates for XCP-ng 8.3.0. In theory, the last ones before the final release:

sm-3.2.3-1.7.xcpng8.3: beta support for XOSTOR (which will become available for production a bit after the release of XCP-ng 8.3.0)
xapi-24.19.2-1.4.xcpng8.3 (and the numerous RPM packages that come from that build): a small IPv6-related fix, but I won't detail it here because another fix is needed so that the first fix is really useful . There will be more fixes related to IPv6 shortly after the release of XCP-ng 8.3.0.
xcp-ng-pv-tools-8.3-12.xcpng8.3: fixed the package versions (no changes but the displayed version).
xsconsole-11.0.6-1.2.xcpng8.3: add the ability to join a pool from XSConsole when the primary address type is IPv6.

We also made one change to the installer since the RC2 release: the installer will now refuse to upgrade if the host's certificate size is too small (which would prevent XAPI from being able to communicate with clients or other hosts!). The release notes will document how to change the key before doing an upgrade. Most users who initially installed XCP-ng with a version lower than 8.0 were likely to fall into this trap, so we made these two last minute changes to prevent it:

On XCP-ng side: the installer check described above.
On Xen Orchestra side: a warning on pools which have "small" host keys.

flakpyro

@stormi Updated without issues however noticed it dumped some errors to the console on reboot.

Checking into it i see the following in xensource.log

/var/log/xensource.log-Sep 25 12:12:29 xcpng-prd-02 xcp-networkd: [ info||131 |server_init D:2740ee30f2da|network_utils] /usr/bin/ovs-vsctl --timeout=20 --bare -f table -- --columns=name find port fake_bridge=true tag=199
/var/log/xensource.log:Sep 25 12:12:29 xcpng-prd-02 xcp-networkd: [error||131 |server_init D:2740ee30f2da|network_utils] Error in read one line of file: /sys/class/net/eth3/features, exception Unix.Unix_error(Unix.ENOENT, "open", "/sys/class/net/eth3/features")\x0ARaised by primitive operation at Xapi_stdext_unix__Unixext.with_file in file "ocaml/libs/xapi-stdext/lib/xapi-stdext-unix/unixext.ml", line 92, characters 11-40\x0ACalled from Xapi_stdext_unix__Unixext.buffer_of_file in file "ocaml/libs/xapi-stdext/lib/xapi-stdext-unix/unixext.ml" (inlined), line 177, characters 2-52\x0ACalled from Xapi_stdext_unix__Unixext.string_of_file in file "ocaml/libs/xapi-stdext/lib/xapi-stdext-unix/unixext.ml", line 179, characters 47-73\x0ACalled from Network_utils.Sysfs.read_one_line in file "ocaml/networkd/lib/network_utils.ml", line 160, characters 6-33\x0A
**/var/log/xensource.log-Sep 25 12:12:29 xcpng-prd-02 xcp-networkd: [error||131 |server_init D:2740ee30f2da|network_utils] Caught unix error: No such file or directory [access, /usr/sbin/ovs-vlan-bug-workaround]**
/var/log/xensource.log-Sep 25 12:12:29 xcpng-prd-02 xcp-networkd: [error||131 |server_init D:2740ee30f2da|network_utils] Assuming script /usr/sbin/ovs-vlan-bug-workaround doesn't exist

Looking on hosts i haven't let patched i see this exists on them as well. It doesn't seem to affect anything. All hosts were ISO upgraded to RC2 last week.

letizido 0

Hello,

This is a somewhat strange request, but I figured I would post it anyway in case someone else has my use case.

I installed XCP-ng 8.3 RC2 on two hosts. On my newer host, I have 96G ram, a 1T and a 4T drive. I have already deployed a few VMs (Windows 11 and various flavors of Linux. Everything is running well. No complaints. I also am running Xen Orchestra from source on a separate machine as a container. All good so far.

Now for my use case: The newer host has a CPU/GPU chip combo powerful enough to run medium-complexity games on, but I don't believe the Windows VM has enough access to the GPU to run the games at their full rendition. So, since this is a lab/play installation anyway, I wanted to explore the potential of installing Windows 11 on the 4T drive to dual boot between XCP-ng and Windows 11. I have already installed Windows no problem on the 4T drive and it is bootable from the EFI boot menu. What I really want to accomplish is to get the Windows boot menu item into the XCP-ng grub menu so that I don't have to use a keyboard interrupt to bring up the EFI boot menu. I have tried several times to modify grub to add the Windows menu item, but every time I try it I get a corrupt grub menu. Any ideas?

I have modified the /etc/grub.d/40_custom file, adding the following to the end of the file:
menuentry "Windows 11" {
set root=(hd0,2)
chainloader +1
}

I then ran the following to modify the grub.cfg in /boot/efi/EFI/xenserver/
grub-mkconfig -o /boot/efi/EFI/xenserver/grub.cfg

When I reboot, the menu appears as all special characters, and does boot up xcp-ng. I can then log in as root and revert to the original grub.cfg and all is well. It's just that the menu is corrupt.

Has anyone tried this and succeeded? I would appreciate it if you could reply to this post.

letizido 0

@letizido-0 I solved my own problem. It turns out grub-mkconfig reads every file in the /etc/grub.d/ directory and builds the grub.cfg trying to include everything. Much easier to just directly edit the grub.cfg and add the menu item with proper settings. Working fine now. Perhaps you may want to look at all those scripts in /etc/grub.d/ and remove what XCP-ng doesn't use/need.

stormi

Regarding the fact that the upgrade asks for the network configuration for hosts which are not the pool master: we checked, it's been the case in this installer code since more than ten years. At some point, the installer needs to contact the pool master during the upgrade.

manilx

@stormi Good to know, thx.