XCP-ng 8.3 updates announcements and testing
-
@ovicz Hello,
From what I saw in your logs, you have a non QCOW2
smversion, it made the QCOW2 VDIs not available to the storage stack and the XAPI lost them.
If you update again while enabling the QCOW2 repo:yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates,xcp-ng-qcow2A SR scan will make the VDI available to the XAPI. Though you will have to identify them and connect them to the VM manually, since this information was lost.
-
I added a warning to my initial announcement.
-
They appear now. I will try to identify them manually. Thanks for the tip.
-
Thanks for your feedback

-
Did the three hosts in my lab pool, nothing blew up so I guess that's good. Just nfs storage with a few windows VMs and a Debian 13 for XO from sources.
I think everything is now an efi boot, but no secure boot machines.
-
Working on my production system today and I noticed something new.
Three hosts in a pool, doing a Rolling Pool Update.
I'm seeing VMs migrate to both available hosts to speed things up, this is not the actions I've seen in the past. Just an interesting thing to see all three host go yellow while it is migrating.
OK, only happened to evac the third host, evac second host was back to the normal move everything to the same host (#3).
And not sure why, but the process start to finish on host 1 was faster than the other two, host 1 is coordinator.
Also of note, there seems to be no place to do a RPU from within XO6.
-
Thank you everyone for your tests and your feedback!
The updates are live now: https://xcp-ng.org/blog/2025/12/18/december-2025-security-and-maintenance-updates-for-xcp-ng-8-3-lts/
-
updates done on my two main servers and one dev box i happen to power on today. so far so good.
PS: Any way to get the following included on the next update for networking? I need it to run a scenario with opnsense vm. right now i have a script i run manually after rebooting the server.
ovs-ofctl add-flow xenbr3 "table=0, dl_dst=01:80:c2:00:00:03, actions=flood"
thanks
-
In regards to UEFI Secure boot in recent update.
from pool master host.
[19:09 xcp-ng-qhfpcnmb ~]# rpm -q varstored varstored-1.2.0-3.4.xcpng8.3.x86_648.3 with varstored >= 1.2.0-3.4 Secure Boot is ready to use on new VMs without extra configuration. Simply activate Secure Boot on your VMs, and they will be provided with an appropriate set of default Secure Boot variables. We will keep updating the default Secure Boot variables with future updates from Microsoft. If you don't want this behavior, you can lock in these variables by using the Manually Install the Default UEFI Certificates procedure.So new vms nothing is needed to be done. But what about existing vms windows or linux? It it was stated I apologize if i missed it.
-
@acebmxer The Recommended actions section of the guest Secure Boot docs has been updated with our latest recommendations. In short, VMs existing prior to the varstored update will need to have their Secure Boot certificates updated with the Propagate certificates button.
-
@dinhngtu thank must have read that part with my eyes closed or something.

