XCP-ng 8.3 updates announcements and testing

Mitchel-APD

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

gduperrey

For XO, I suggest you start a separate thread.

Regarding the host issue, without more details or information, it's difficult to say anything at the moment, especially since I haven't been able to reproduce it myself.

robertblissitt

@gduperrey Absolutely understand. I didn't now about the Escape key as Manilx mentioned. Next time, I will press Esc to see if there is any useful information and report it here. This was just new behavior and wanted to report it informally.

abudef

In my case, I gave the command to shut down all hosts, and the master "made it" first. The other hosts then got "stuck" at this point for a very long time:

EDIT: Apparently waiting for umount:

gduperrey

@abudef In case of a shutdown, I turn off the secondary servers first. Once they are off, I shut down the primary server. This ensures that if the secondary servers have information to send to the primary, they can do so, whereas otherwise, they can wait to shut down.

In case of a pool reboot, I reboot the primary server first, and once it is accessible, I reboot the secondary servers.

abudef

@gduperrey Of course, the order matters. Now everything seems to be clear.

gduperrey

New security and maintenance update candidate for you to test!

A new security vulnerability, XSA-480, has been detected and fixed for xen.

Security updates

xen: A vulnerability has been discovered on x86 Intel systems with EPT support, where unintended host or guest memory regions can be accessed from a VM's memory cache under any workload. This can lead to privilege escalation, denial of service (DoS) attacks affecting the entire host, or information leaks.
On XCP-ng 8.3, x86 HVM/PVH VMs can leverage this vulnerability.
There are no mitigations.

A VSA was also published by our security team: https://docs.vates.tech/security/advisories/2026/vates-sa-2026-005/

Maintenance updates

We are taking this opportunity to release an update for ipmitool following some feedback from our users regarding the display of an error message in Xen-Orchestra, with certain models of DELL servers, in relation to the command ipmitool lan print.

Test on XCP-ng 8.3

yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates
yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates
reboot

The usual update rules apply: pool coordinator first, etc.

Versions:

ipmitool: 1.8.19-11.2.xcpng8.3
xen: 4.17.6-5.1.xcpng8.3

What to test

Normal use and anything else you want to test.

Test window before official release of the updates

~2 days

flakpyro

@gduperrey No issues to report on my test systems.

gduperrey

Thank you everyone for your tests and your feedback!

The updates are live now: https://xcp-ng.org/blog/2026/03/19/march-2026-security-updates-for-xcp-ng-8-3-lts/

manilx

@gduperrey reboot necessary?