@flakpyro yes. thanks for your test and to reporting the problem anyway. it is helping us to see what kind of problems users could have.

@flakpyro it seems to me the proper upgrade path is:

• put the master in maintenance mode (xe host-disable host=$MASTER)
• evacuate the master (xe host-evacuate host=$MASTER)
• yum update the master
• reboot the master (xe host-reboot host=$MASTER)
• once done, do the same of the others hosts

the VM would have been updated with the new trunks attribute when migrating to some updated host (in your case, when migrating to the master).

@Andrew said:

"xenopsd internal error: Hotplug.Hotplug_error(\"Failed to read /xapi/450015b0-e878-5067-e8b6-000000000001/private/vif/1/trunks\")"

This is related to new code in the upgrade. the trunks attribute is used for VLAN filtering (new feature).

it seems that the running code is the new one (it is knowning about trunks) but the VM doesn't have the trunks attribute.

I would be interested to have a clean picture of the situation:

• on which host this VM is resident on
• version of the master
• version of the host where the VM is resident

@andersonalipio I would be interested to get some elements from your installation.

• your /var/log/sdn-controller-plugin.log file (on the host) in order to check the parameter passed by XO.
• output of xe network-param-list uuid=$UUID (for the network concerned) or xe network-list params=all (if uuid is unknown)
• output of xe pool-list params=other-config (for xo:sdn-controller:* elements)
• output of xe vif-list params=uuid,network-uuid,other-config (for xo:sdn-controller:* elements)

Feel free to share it privately via PM if you prefer, possibly using https://paste.vates.tech/ .

Cc @Team-XO-Backend too (as it could be from XO side)

Sorry, but it is outside my competence zone. I prefer to not tell you to try something that I don't know the exact consequences of.

Does someone else could reply ?

Yes, if the file is empty, it is expected to the openssl x509 command to fail.
Does is it the same on the master ?

Just my 2 cents, but with SSL involved time is important: could you check the date is accurate on the two hosts ?

having the output of the following commands might help too:

• stat /etc/stunnel/xapi-stunnel-ca-bundle.pem
• openssl x509 -in /etc/stunnel/xapi-stunnel-ca-bundle.pem -noout -text

please note that blacklisting ESP modules will break IPsec, and encrypted private tunnels rely on it.

Bonjour,

Apparemment, la valeur vient de la xapi :

$ xe host-list params=uuid,software-version
uuid ( RO)                : 9940971b-45f6-4225-aaef-ddb0668e3734
    software-version (MRO): product_version: 8.3.0; product_version_text: 8.3; product_version_text_short: 8.3; platform_name: XCP; platform_version: 3.4.0; product_brand: XCP-ng; xapi: 26.1; build_number: 8.3.0; git_id: 3; hostname: localhost; date: 20260430T09:28:41Z; dbv: 0.0.1; xapi_build: 26.1.3; xen: 4.17.6-6; linux: 4.19.0+1; xencenter_min: 2.21; xencenter_max: 2.21; network_backend: openvswitch; db_schema: 5.793


uuid ( RO)                : 5f16a481-103e-4ca8-a0e2-b708d2c26437
    software-version (MRO): product_version: 8.3.0; product_version_text: 8.3; product_version_text_short: 8.3; platform_name: XCP; platform_version: 3.4.0; product_brand: XCP-ng; xapi: 26.1; build_number: 8.3.0; git_id: 3; hostname: localhost; date: 20260430T09:28:41Z; dbv: 0.0.1; xapi_build: 26.1.3; xen: 4.17.6-6; linux: 4.19.0+1; xencenter_min: 2.21; xencenter_max: 2.21; network_backend: openvswitch; db_schema: 5.793

qui prend l'information depuis le fichier /etc/xensource-inventory (sur le host):

# grep BUILD_NUMBER /etc/xensource-inventory
BUILD_NUMBER='8.3.0'

Ce fichier est mis à jour par le script de post-config du package rpm xcp-ng-release (voir le script utilisé ici)

La valeur a été mise à jour la dernière fois en 2023 (voir le changelog pour 8.3.0-13).
La valeur acutelle est définie dans la variable BUILD_NUMBER rpm variable du package.

Cela veut dire que le host avec Build number = cloud ne semble pas à jour ? Pouvez-vous vérifier la version installée du package xcp-ng-release, en utilisant la commande rpm -q xcp-ng-release ?

after testing (with net-snmp-utils 5.9.3), I have no problem with snmpv3 and SHA/AES.

On my testing host, snmpd server (OpenBSD):

• User: user1
• auth: AES with password123
• priv: AES with 321drowssap

From XCP-ng 8.3, with net-snmp-utils 5.9.3:
$ snmpbulkwalk -v3 -a SHA -A password123 -l authPriv -x AES -X 321drowssap -u user1 192.168.1.80

so the net-snmp client itself seems fine with SHA/AES.

could you share more elements ?

SHA`is SHA1. so I assume it is that.
And it seems to be still accepted in authProtocol parameter.

@Mitchel-APD SHA1 ? I am looking if it is still supported/activated-by-default. I saw that 5.8 added SHA-2 family for RFC-7860 compliance

@Mitchel-APD how do you auth on SNMP ? v1, v2, v3 ? and if v3, which authProtocol/privProtocol do you use ?

Having help from OpenBSD side could be the way to go.
Please forward your report to bugs@openbsd.org (with a link to this post too)

For the record, I am able to reproduce it too (on XCP-ng 8.3 too, using OpenBSD -current).

when a new host join an existing pool, it starts by configuring the management interface. so the first bound created is the management one (as bond0) even if the master of the pool has it as bond1.

while doing some tests with 8.3 I got problems too, but not systematically (as you, it seems).

I will send to you a PM regarding xensource.log

@afmart_dei could you share the /var/log/xensource.log of the joining host ? ideally the whole part after the host started (you could look at the file before rebooting and strip all lines before the last line you saw)