XCP-ng 8.3 betas and RCs feedback 🚀

altikardes

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

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

Anyway, it's better to have an option b) if option a) fails

As you wish, but I won't support option b) in any case, so I prefer to mention it

Yesterday I upgraded my 8.2 server by downloading the 8.3 rc1 iso file onto a USB stick. In general, virtual machines, iscsi storage, etc. everything worked without problems, but there is an interesting situation. Before the upgrade, the server was connecting to the internet without problems. For example, when I ping Google, I get a response, but now when I ping, it finds the IP address from DNS, but there is no response. I checked the gateway and DNS settings many times and did not see any problem. In this case, I could not install XOA either. Has anyone experienced such a problem?

NoHeadroom

@altikardes
I assume there isn't a VLAN configured, isn't it?

Anyway, sometimes it's better to do the "Emergengy Network Reset" (under "Network and Management Interface") and start to reconfig your network interfaces from bottom up.

altikardes

@NoHeadroom

Yes, there is no vlan configuration. There was no problem with internet connection before the upgrade. I set the ip configuration as dhcp but the result is the same. I reset the network settings with "Emergency Network Reset" from the xsconsole section and made the necessary settings after the system was restarted but the result still did not change. (I tried both static and dynamic ip.)

NoHeadroom

@altikardes
what's the contens of /etc/resolv.conf ?

altikardes

@NoHeadroom

Hello again, the problem was related to a rule change on the firewall. I didn't feel the need to check it because it coincided with the time I upgraded. So everything is working now. Sorry for the false alarm.

olivierlambert

Good news then

gb.123

@stormi @olivierlambert

I have also successfully run a test install of RC1 on my lab. Everything seems to be working fine. The TLS issue also seems to go away (will also put a separate post on the topic concerned).

Good Job guys !

One thing I noticed :

I seem to get an error message

no crontab for root

while running crontab -e the first time.

Is that normal? Is it ok to run a cron job for root ?

bufanda

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

@stormi @olivierlambert

I have also successfully run a test install of RC1 on my lab. Everything seems to be working fine. The TLS issue also seems to go away (will also put a separate post on the topic concerned).

Good Job guys !

One thing I noticed :

I seem to get an error message
no crontab for root
while running crontab -e the first time.

Is that normal? Is it ok to run a cron job for root ?

Could be very well happen if you have a fresh install and no cronjobs in the crontab. Most distributions would put corn jobs in /etc/cron.d anyways and so does xcp-ng too. And the users crontab then will be created on the first edit.

yann

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

gb.123

@bufanda @yann

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 used crontab -ir)

@stormi

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 ?

stormi

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

@stormi

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

ydirson created this issue in xenserver/host-installer

open Adding a safeguard for UEFI/legacy config switch #11

steff22

This post is deleted!

stormi

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

vectr0n

Updated two home lab hosts yesterday without any issues.

gb.123

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

ph7

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

The server started and the VMs seems to be running.
I'm not running iSCSI so i hope its OK

stormi

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

exetico

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

pierre.c

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

stormi

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

The server started and the VMs seems to be running.
I'm not running iSCSI so i hope its OK

It comes from a trigger added by XenServer which updates the /etc/cgrules.conf file 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

stormi created this issue in xapi-project/sm

XCP-ng 8.3 betas and RCs feedback 🚀

open Adding a safeguard for UEFI/legacy config switch #11

open [packaging] Failing patch application upon update in sm's RPM triggerin on XenServer 8 #705