XCP-ng 8.3 betas and RCs feedback 🚀
-
@gb-123 said in XCP-ng 8.3 betas and RCs feedback
:Is that normal? Is it ok to run a cron job for root ?
I´d advise to rather use system crontabs in
/etc/cron.d/, one dedicated to each topic you have (but that's rather unrelated to XCP-ng itself, just standard Linux sysadmin practice). -
Thanks for the tip !
Anyway to delete the crontab created for root ? Or it is not required (since it is blank anyways) ?(I should have just usedcrontab -ir)I also noticed that I get an option to "Upgrade" to RC1 from beta 2. This should technically not happen since I installed beta 2 in Legacy BIOS mode and am now installing RC1 in UEFI mode since the former would be deprecated.
Is that an error in installer or upgrade is possible ?
-
@gb-123 said in XCP-ng 8.3 betas and RCs feedback
:I also noticed that I get an option to "Upgrade" to RC1 from beta 2. This should technically not happen since I installed beta 2 in Legacy BIOS mode and am now installing RC1 in UEFI mode since the former would be deprecated.
Is that an error in installer or upgrade is possible ?
It's not exactly an error, but it's not very good either. This would fail at some point so don't attempt it. We suggested to add the detection of such situations, upstream, but neither them nor us had the time to implement it: https://github.com/xenserver/host-installer/issues/11
-
This post is deleted! -
Here's a new batch of updates for XCP-ng 8.3 RC1. I hoped there would be less changes after a release candidate, but between our own fixes and the updates published by XenServer, the list is rather big.
The following names are build identifiers, which can differ from the actual RPM names.
- curl-8.6.0-2.2.xcpng8.3: CVE fixes
- edk2-20220801-1.7.7.1.xcpng8.3: CVE fixes applied from XenServer 8
- gpumon-24.1.0-8.1.xcpng8.3: rebuilt as a dependency of xapi
- guest-templates-json-2.0.10-1.3.xcpng8.3: removed XenServer's mention "preview" from well established templates (RHEL 9, Debian 12, ...), added new generic Linux templates to avoid the use of the less adequate "Other installation media" template.
- http-nbd-transfer-1.4.0-1.xcpng8.3: XOSTOR-related fixes
- intel-i40e-2.22.20-6.xcpng8.3: applied update from XenServer 8
- kernel-4.19.19-8.0.36.1.xcpng8.3: applied updates from XenServer 8
- mcelog-196-3.xcpng8.3: applied update from XenServer 8
- net-snmp-5.7.2-51.3.xcpng8.3: CVE fixes
- ocaml-4.14.2-1.xcpng8.3: applied update from XenServer 8
- ocaml-findlib-1.9.6-3.xcpng8.3: applied update from XenServer 8
- openssh-7.4p1-23.3.1.xcpng8.3: applied update from XenServer 8. Fixes a CVE and also removes libsystemd integration as a defence-in-depth measure.
- openvswitch-2.17.7-2.1.xcpng8.3: disabled weak ciphers
- qemu-4.2.1-5.2.10.xcpng8.3: applied update from XenServer 8
- qemu-dp-7.0.0-15.xcpng8.3: applied update from XenServer 8
- qlogic-qla2xxx-10.02.11.00_k-1.xcpng8.3: applied update from XenServer 8
- sm-3.2.3-1.1.xcpng8.3: reverted an upstream change which cause issues with iSCSI SRs, added a setting allowing to modify the LVM configuration of a SR, applied updates from XenServer 8
- sudo-1.9.15-4.1.xcpng8.3: applied update from XenServer 8. Nothing but a packaging change.
- xapi-24.19.2-1.2.xcpng8.3: fixed an upstream bug in openvswitch-config-update, applied updates from XenServer 8
- xcp-featured-1.1.7-3.xcpng8.3: rebuilt as dependency of xapi
- xcp-ng-deps-8.3-11: obsoleted unused package
oprofile - xcp-ng-release-8.3.0-27: dropped unneeded dependencies, updated post-installation scriptlets to avoid warnings in installation logs
- xcp-ng-xapi-plugins-1.10.1-1.xcpng8.3: better error reporting
- xen-4.17.4-6.xcpng8.3: applied update from XenServer 8
- xenserver-status-report-2.0.5-2.xcpng8.3: applied update from XenServer 8
- xo-lite-0.2.7-1.xcpng8.3: updated to version 0.2.7. The main feature this brings is now XO Lite can detect when a newer version exists online and load it instead of the version currently packaged as a RPM in XCP-ng.
- xsconsole-11.0.6-1.1.xcpng8.3: applied update from XenServer 8
- xs-opam-repo-6.80.0-1.1.xcpng8.3: applied update from XenServer 8
- zfs-2.1.15-2.xcpng8.3: fixed a systemd unit ordering cycle
-
Updated two home lab hosts yesterday without any issues.
-
@stormi said in XCP-ng 8.3 betas and RCs feedback
:http-nbd-transfer-1.4.0-1.xcpng8.3: XOSTOR-related fixes
Does this mean XOSTOR is ready to be tested in 8.3 ?
-
@stormi
I ran yum update a few minutes ago and got this:
warning: %triggerin(sm-3.2.3-1.1.xcpng8.3.x86_64) scriptlet failed, exit status 1 Non-fatal <unknown> scriptlet failure in rpm package sm-3.2.3-1.1.xcpng8.3.x86_64The server started and the VMs seems to be running.
I'm not running iSCSI so i hope its OK -
@gb-123 said in XCP-ng 8.3 betas and RCs feedback
:@stormi said in XCP-ng 8.3 betas and RCs feedback
:http-nbd-transfer-1.4.0-1.xcpng8.3: XOSTOR-related fixes
Does this mean XOSTOR is ready to be tested in 8.3 ?
Not yet.
-
@stormi Updated a single lab with no problems.
I'm not sure if "pure positive" updates are meant for this thread, so I'll just report that, anyways
. -
@stormi For us, the openvswitch-2.17.7-2.1.xcpng8.3 update has definitively solved the problem of overlay networks that weren't working (thanks David M. for all your help and hard work).
Unfortunately, the sm-3.2.3-1.1.xcpng8.3 update seems to have broken something in our iSCSI sessions. We now have 3 sessions instead of the usual 4 (2 interfaces on the host to two controllers on the storage array).
We have a less-than-ideal configuration with a large, flat network ( we have a project planned to put everything back the way it should be) with interfaces named c_eth4 and c_eth5, as recommended in the documentation in such cases.
It seems that the new version respects the use of interfaces for one of the two targets, but not for the other, which uses the default interface.
# iscsiadm -m session -P3 iSCSI Transport Class version 2.0-870 version 6.2.0.874-7 Target: iqn.2006-08.********************:21008041266ebf8e::20602:***.***.***.*** (non-flash) Current Portal: ***.***.***.***:3260,1539 Persistent Portal: ***.***.***.***:3260,1539 ********** Interface: ********** Iface Name: default Iface Transport: tcp Iface Initiatorname: iqn.2024-06.*********xcp-01.lan.mgmt:7203c069 Iface IPaddress: ***.***.20.155 Iface HWaddress: <empty> Iface Netdev: <empty> SID: 1 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE [...] Target: iqn.2006-08.********************:21008041266ebf8e::1020602:***.***.***.*** (non-flash) Current Portal: ***.***.***.***:3260,1549 Persistent Portal: ***.***.***.***:3260,1549 ********** Interface: ********** Iface Name: c_eth5 Iface Transport: tcp Iface Initiatorname: iqn.2024-06.*********xcp-01.lan.mgmt:7203c069 Iface IPaddress: ***.***.21.155 Iface HWaddress: <empty> Iface Netdev: xenbr5 SID: 2 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE [...] ********** Interface: ********** Iface Name: c_eth4 Iface Transport: tcp Iface Initiatorname: iqn.2024-06.*********xcp-01.lan.mgmt:7203c069 Iface IPaddress: ***.***.20.155 Iface HWaddress: <empty> Iface Netdev: xenbr4 SID: 3 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE [...] -
@ph7 said in XCP-ng 8.3 betas and RCs feedback
:@stormi
I ran yum update a few minutes ago and got this:
warning: %triggerin(sm-3.2.3-1.1.xcpng8.3.x86_64) scriptlet failed, exit status 1 Non-fatal <unknown> scriptlet failure in rpm package sm-3.2.3-1.1.xcpng8.3.x86_64The server started and the VMs seems to be running.
I'm not running iSCSI so i hope its OKIt comes from a trigger added by XenServer which updates the
/etc/cgrules.conffile but attempts to do so even when already patched, so it fails.No consequences but this warning.
I fixed it and reported it upstream: https://github.com/xapi-project/sm/issues/705
-
I did an update of a 8.2 host to 8.3 via ISO install. Everything is working as it should but I get the below error on the host advanced tab with PCI passthrough. I had a Nvidia GPU passed through to a RHEL 9 VM on the 8.2 host. This was done via the command line.
I will load 8.3 on a new host with the same hardware config later in the week to confirm that it must be something to do with the 8.2 --> 8.3 upgrade.
Let me know if you need more info.
-
That's an interesting one, maybe a bug in the way we parse all the device?
Can you copy/paste lspciin here? -
Info as requested.
[21:08 xcp-ng-01 ~]# lspci 00:00.0 Host bridge: Intel Corporation 10th Gen Core Processor Host Bridge/DRAM Registers (rev 05) 00:01.0 PCI bridge: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) (rev 05) 00:02.0 VGA compatible controller: Intel Corporation CometLake-S GT2 [UHD Graphics 630] (rev 05) 00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 05) 00:12.0 Signal processing controller: Intel Corporation Comet Lake PCH Thermal Controller 00:14.0 USB controller: Intel Corporation Comet Lake USB 3.1 xHCI Host Controller 00:14.2 RAM memory: Intel Corporation Comet Lake PCH Shared SRAM 00:16.0 Communication controller: Intel Corporation Comet Lake HECI Controller 00:16.3 Serial controller: Intel Corporation Comet Lake Keyboard and Text (KT) Redirection 00:17.0 SATA controller: Intel Corporation Comet Lake SATA AHCI Controller 00:1b.0 PCI bridge: Intel Corporation Comet Lake PCI Express Root Port #21 (rev f0) 00:1d.0 PCI bridge: Intel Corporation Comet Lake PCI Express Root Port #9 (rev f0) 00:1f.0 ISA bridge: Intel Corporation Q470 Chipset LPC/eSPI Controller 00:1f.3 Audio device: Intel Corporation Comet Lake PCH cAVS 00:1f.4 SMBus: Intel Corporation Comet Lake PCH SMBus Controller 00:1f.5 Serial bus controller: Intel Corporation Comet Lake PCH SPI Controller 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (11) I219-LM 01:00.0 VGA compatible controller: NVIDIA Corporation GP107GL [Quadro P600] (rev a1) 01:00.1 Audio device: NVIDIA Corporation GP107GL High Definition Audio Controller (rev a1) 02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 03:00.0 Ethernet controller: Intel Corporation Ethernet 10G 2P X520 Adapter (rev 01) 03:00.1 Ethernet controller: Intel Corporation Ethernet 10G 2P X520 Adapter (rev 01)There error is present in both:
- Current version: 5.97.0 - XOA build: 20240401
- Xen Orchestra from source code, commit 70014 / Master, commit e5c53
-
Seems to be running fine on our 12 hosts, iSCSI came up fine too with all our paths.
-
@brezlord I think it might be related to some recent XAPI code, I don't think it's XO related. Might worth a specific investigation, I'm not sure it's due to the upgrade itself.
-
@olivierlambert I'll report back at the end of the week when I deploy a new host with the exact same hardware config and a fresh install.
-
@pierre-c said in XCP-ng 8.3 betas and RCs feedback
:@stormi For us, the openvswitch-2.17.7-2.1.xcpng8.3 update has definitively solved the problem of overlay networks that weren't working (thanks David M. for all your help and hard work).
Unfortunately, the sm-3.2.3-1.1.xcpng8.3 update seems to have broken something in our iSCSI sessions. We now have 3 sessions instead of the usual 4 (2 interfaces on the host to two controllers on the storage array).
We have a less-than-ideal configuration with a large, flat network ( we have a project planned to put everything back the way it should be) with interfaces named c_eth4 and c_eth5, as recommended in the documentation in such cases.
It seems that the new version respects the use of interfaces for one of the two targets, but not for the other, which uses the default interface.
# iscsiadm -m session -P3 iSCSI Transport Class version 2.0-870 version 6.2.0.874-7 Target: iqn.2006-08.********************:21008041266ebf8e::20602:***.***.***.*** (non-flash) Current Portal: ***.***.***.***:3260,1539 Persistent Portal: ***.***.***.***:3260,1539 ********** Interface: ********** Iface Name: default Iface Transport: tcp Iface Initiatorname: iqn.2024-06.*********xcp-01.lan.mgmt:7203c069 Iface IPaddress: ***.***.20.155 Iface HWaddress: <empty> Iface Netdev: <empty> SID: 1 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE [...] Target: iqn.2006-08.********************:21008041266ebf8e::1020602:***.***.***.*** (non-flash) Current Portal: ***.***.***.***:3260,1549 Persistent Portal: ***.***.***.***:3260,1549 ********** Interface: ********** Iface Name: c_eth5 Iface Transport: tcp Iface Initiatorname: iqn.2024-06.*********xcp-01.lan.mgmt:7203c069 Iface IPaddress: ***.***.21.155 Iface HWaddress: <empty> Iface Netdev: xenbr5 SID: 2 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE [...] ********** Interface: ********** Iface Name: c_eth4 Iface Transport: tcp Iface Initiatorname: iqn.2024-06.*********xcp-01.lan.mgmt:7203c069 Iface IPaddress: ***.***.20.155 Iface HWaddress: <empty> Iface Netdev: xenbr4 SID: 3 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE [...]Concerning our problem with iSCSI sessions, I have just tried a downgrade of sm followed by a reboot :
yum downgrade sm sm-fairlockI can confirm that it works again on 4 paths via both interfaces after downgrade.
# iscsiadm -m session -o show tcp: [2] ***.***22.1:3260,1539 iqn.2006-08.********************:21008041266ebf8e::20602:***.***22.1 (non-flash) tcp: [3] ***.***22.1:3260,1539 iqn.2006-08.********************:21008041266ebf8e::20602:***.***22.1 (non-flash) tcp: [4] ***.***23.1:3260,1549 iqn.2006-08.********************:21008041266ebf8e::1020602:***.***23.1 (non-flash) tcp: [5] ***.***23.1:3260,1549 iqn.2006-08.********************:21008041266ebf8e::1020602:***.***23.1 (non-flash)# iscsiadm -m session -P3 iSCSI Transport Class version 2.0-870 version 6.2.0.874-7 Target: iqn.2006-08.********************:21008041266ebf8e::20602:***.***22.1 (non-flash) Current Portal: ***.***22.1:3260,1539 Persistent Portal: ***.***22.1:3260,1539 ********** Interface: ********** Iface Name: c_eth5 Iface Transport: tcp Iface Initiatorname: iqn.2024-06.*********xcp-01*********:7203c069 Iface IPaddress: ***.***21.155 Iface HWaddress: <empty> Iface Netdev: xenbr5 [...] ********** Interface: ********** Iface Name: c_eth4 Iface Transport: tcp Iface Initiatorname: iqn.2024-06.*********xcp-01*********:7203c069 Iface IPaddress: ***.***20.155 Iface HWaddress: <empty> Iface Netdev: xenbr4 [...] Target: iqn.2006-08.********************:21008041266ebf8e::1020602:***.***23.1 (non-flash) Current Portal: ***.***23.1:3260,1549 Persistent Portal: ***.***23.1:3260,1549 ********** Interface: ********** Iface Name: c_eth5 Iface Transport: tcp Iface Initiatorname: iqn.2024-06.*********xcp-01*********:7203c069 Iface IPaddress: ***.***21.155 Iface HWaddress: <empty> Iface Netdev: xenbr5 [...] ********** Interface: ********** Iface Name: c_eth4 Iface Transport: tcp Iface Initiatorname: iqn.2024-06.*********xcp-01*********:7203c069 Iface IPaddress: ***.***20.155 Iface HWaddress: <empty> Iface Netdev: xenbr4 SID: 5 [...]So we do have a problem with the new version of sm
-
@pierre-c I dont use iSCSI in my lab anymore, but yesterday when I did a "yum update" of 8.3 Beta, I got a script error when yum was running through all the updates. The script that failed was part of the sm update.
To be honest, I didnt bother doing anything with the error as everything seemed to work OK for me after, so I just ignored it. But.. Maybe I should have said something.. Sorry guys..
