XCP-ng 8.3 updates announcements and testing

manilx

@gduperrey Updated 2 pools/2 hosts @home (via cli). 3 pools/5 hosts @office (via RPU).
No issue.

acebmxer

Updated work servers 3 pools 6 host with Rolling Pool Update.

Mitchel-APD

Just updated 1 pool with 3 hosts.
SNMP did not work anymore, config file was not changed.
Got the following error: Authorization Error (SNMP error # 16)
Did a yum downgrade net-snmp*

From:

net-snmp.x86_64 1:5.9.3-8.1.xcpng8.3
net-snmp-agent-libs.x86_64 1:5.9.3-8.1.xcpng8.3
net-snmp-libs.x86_64 1:5.9.3-8.1.xcpng8.3

To:

net-snmp.x86_64 1:5.7.2-52.1.xcpng8.3
net-snmp-agent-libs.x86_64 1:5.7.2-52.1.xcpng8.3
net-snmp-libs.x86_64 1:5.7.2-52.1.xcpng8.3

After a service restart, SNMP worked immediately.

rzr

@Mitchel-APD said:

Just updated 1 pool with 3 hosts.
SNMP did not work anymore, config file was not changed.
Got the following error: Authorization Error (SNMP error # 16)

Thank you for your feedback, we're going to investigate, I see that there are many changes between both versions:

https://github.com/net-snmp/net-snmp/compare/v5.7.2...v5.9.3

semarie

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

Mitchel-APD

@semarie Hi,

We are using SNMPv3 with SHA AES

semarie

@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

semarie

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

semarie

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 ?

Mitchel-APD

@semarie Hi,

Thanks for your help, I just created the user with the net-snmp-create-v3-user command, and definded SHA-256.

SNMP now works like before.

net-snmp-create-v3-user -ro -A verrysecureauthenticationpassword-a SHA-256 -X verrysecureprivacypassword--x AES snmpusername

abudef

Hi, it seems that shutting down the host is taking an extremely long time now. I tried it in two different environments; the shutdown process starts but gets stuck on the splash screen for several minutes before finally completing. There were no active virtual machines on the hosts being shut down.

Does anyone have the possibility to test this in a lab? Thanks!

gduperrey

@abudef I've updated and rebooted numerous hosts with these updates and haven't noticed any significant slowdowns.

Do you have any additional information in the logs?

MajorP93

Can also confirm that I was able to apply this round of patches using rolling update method without any issues or slowdowns on a pool of 5 hosts.

abudef

@gduperrey Restart happens normally, without any noticeable delay, but shutdown takes a long time. Which logs should I specifically check?

(It's not a real issue, but I just needed to move servers in the lab and had to shut them down, so I noticed it.)

robertblissitt

@abudef After the excitement from the last update cycle (see my post above from ~January 29), I kicked off a Rolling Pool Reboot this time before considering a Rolling Pool Update. During this RPR, the first host is currently hanging on its shut down right now after about 10 - 15 minutes as shown in the screenshot. I am running the previous most recent version of XCP-ng, again from January 29, 2026. I'll revisit installing these most recent updates once I get clean reboots.

manilx

@robertblissitt Press ESC and you'll see what's happening

Greg_E

@robertblissitt

Normal for the pool master to take a bit longer but never seen 15 minutes before.

gduperrey

As explained, I haven't observed such a delay on our end during our testing.

As Maniix suggests, you can see what's happening by pressing "Esc" to see which step is taking longer.

From what I've heard internally, a common reason for this lengthy step is when a shared server was running on a VM and that VM was shut down. The host then takes a very long time to shut down or restart.

ph7

@gduperrey
In my homelab I've had the same problem for at least 18 month's
when shutting down the XO-VM it hangs for 2-3 minutes when it tries to umount the remotes

umount /run/xo-server/mounts/xxxxx (SMB and NFS)
umount /run/xo-server/mounts/yyyyy (SMB)

I did report this in an earlier thread

manilx

@ph7 This I can confirm, with XO VM.
But discussion was about the host....