XCP-ng 8.3 updates announcements and testing

marcoi

@stormi said:

We pushed the updates to the xcp-ng-updates repository: https://xcp-ng.org/blog/2026/05/21/may-2026-updates-3-for-xcp-ng-8-3-lts/

Changed since the initial announcement, xen was updated with the proper vulnerability fix and an update to sm was added to fix an issue on LVM-based SRs with CBT enabled.

Thanks everyone for your feedback!

update main pool. so far so good. updates went well and vms are running.

Greg_E

Did my production this morning... Not a smooth upgrade this time.

The master took so long that the process timed out, I can't tell too much more because I was doing other work and was doing this remotely.

I handled the next host manually, and that took so much time I gathered my hearing protection and went over to the rack. It was stuck in a reboot phase but hadn't shut down for about 20 minutes. Held my finger on the power button. booted back up with a couple reboots in the process and it finally was ready.

Moved the VMs off the third host, manually triggered the update, and sat and watched looking at the VGA output to see what was happening. The reboot phase saw the XCP-ng animation progress all the way to an empty bar, but sat there another 5-10 minutes until I again held my finger on the power button to shut it off. Power up and after a bit of time it was ready again. All in all, updating three hosts took me around 2 hours today.

Here's the one condition that I think could contribute to this issue:

I have two NAS normally connected, an ISO and NFS connection on each. One of the servers is powered down for construction, but I did not disconnect it from the hosts. Could this severed connection be the reason why my updates took so long, something around not being able to purge or drain the state before the reboot?

I've disconnected those SR from the hosts, and I'll probably do a rolling pool reboot later today or next week and see if things go better.

And all that said, my XO sources is not happy with this update. XO6 isn't grabbing the data so dashboards are blank or take a long time with spinning wheels gathering the data. XO5 is immediate. One of my XO sources updated this morning, the other was yesterday so they should be pretty close to current.

olivierlambert

@Greg_E said:

I have two NAS normally connected, an ISO and NFS connection on each. One of the servers is powered down for construction, but I did not disconnect it from the hosts. Could this severed connection be the reason why my updates took so long, something around not being able to purge or drain the state before the reboot?

Don't look further, that's exactly the issue. Reboot would have occur in the end after 30 minutes (timeout) and all other operations will be extremely slow.

You must disconnect a SR for maintenance, otherwise you enter in a world of pain.

acebmxer

I have issue with rolling pool update with 1 of my 3 pools at work. It was the last pool to be updated. Host 1 updated no issues. vms stopped migrated off host 2 to complete updates.

Support ticket opened - Ticket#7758427. Found 1 vm with cpu stuck at 100% and unresponsive. Force rebooted vm and proceed updates on host2.

probain

Now receiving UUID_INVALIDwhen trying to disable CBT on a VDI.
Perhaps a result of fixing the "List index out of range"-bug?

XO Source: 5811d
Node 24

vdi.set
{
  "id": "57e0db3e-3131-40df-a620-c1118047b9d4",
  "cbt": false
}
{
  "code": "UUID_INVALID",
  "params": [
    "VDI",
    "7b179964-dec6-4e24-a13b-8c5c56efcd95"
  ],
  "call": {
    "duration": 2,
    "method": "VDI.get_by_uuid",
    "params": [
      "* session id *",
      "7b179964-dec6-4e24-a13b-8c5c56efcd95"
    ]
  },
  "message": "UUID_INVALID(VDI, 7b179964-dec6-4e24-a13b-8c5c56efcd95)",
  "name": "XapiError",
  "stack": "XapiError: UUID_INVALID(VDI, 7b179964-dec6-4e24-a13b-8c5c56efcd95)
    at XapiError.wrap (file:///opt/xen-orchestra/packages/xen-api/_XapiError.mjs:16:12)
    at file:///opt/xen-orchestra/packages/xen-api/transports/json-rpc.mjs:38:21
    at runNextTicks (node:internal/process/task_queues:65:5)
    at processImmediate (node:internal/timers:472:9)"
}

Greg_E

@olivierlambert

That's what I thought, I have it disconnected now and I'll try a rolling reboot when I'm back at work.

acebmxer

acebmxer said:

I have issue with rolling pool update with 1 of my 3 pools at work. It was the last pool to be updated. Host 1 updated no issues. vms stopped migrated off host 2 to complete updates.

Support ticket opened - Ticket#7758427. Found 1 vm with cpu stuck at 100% and unresponsive. Force rebooted vm and proceed updates on host2.

Well I think i found the source of my problems. After having continues other odd issues with this remote pool. I decided i was going to reboot everything. That's when every vm started to fail. Logged into Synology rs1221+ and it was just very sluggish and not responsive. No new error alerts or anything to explain the odd behavior. Rebooted it and even after boot still odd behavior until finally disk error. Then the system started to respond.

Luckily I have a spare drive onsite but cant gain access until Monday possibly Tuesday. Fingers crossed. Lucky for backups. Looks like the important vms had a successful backup as of yesterday so thats good.

stormi

@probain said:

Now receiving UUID_INVALIDwhen trying to disable CBT on a VDI.
Perhaps a result of fixing the "List index out of range"-bug?

Let me call @Team-Storage about this.

dthenot

@probain Hello,

It's likely linked to the List index out of range bug.
That bug was linked to the SR scan failing to introduce CBT_metatadata VDI in the XAPI database, could you try to launch a xe sr-scan uuid=<SR UUID> and try again to disable CBT?
If it does not work, could you share the /var/log/SMlog of around the time you are trying to disable CBT?

acebmxer

acebmxer said:

acebmxer said:

I have issue with rolling pool update with 1 of my 3 pools at work. It was the last pool to be updated. Host 1 updated no issues. vms stopped migrated off host 2 to complete updates.

Support ticket opened - Ticket#7758427. Found 1 vm with cpu stuck at 100% and unresponsive. Force rebooted vm and proceed updates on host2.

Well I think i found the source of my problems. After having continues other odd issues with this remote pool. I decided i was going to reboot everything. That's when every vm started to fail. Logged into Synology rs1221+ and it was just very sluggish and not responsive. No new error alerts or anything to explain the odd behavior. Rebooted it and even after boot still odd behavior until finally disk error. Then the system started to respond.

Luckily I have a spare drive onsite but cant gain access until Monday possibly Tuesday. Fingers crossed. Lucky for backups. Looks like the important vms had a successful backup as of yesterday so thats good.

Still having issues with this remote pool. Synology is still rebuilding the storage pool, but the time seems unreal to complete 80+ days. It keeps dropping and increasing... Yet I tried to migrate vm from NFS SR to local storage and vm having issues boot. Try to determining but i think i have multiple issue just not sure which ones.

probain

@dthenot said:

@probain Hello,

It's likely linked to the List index out of range bug.
That bug was linked to the SR scan failing to introduce CBT_metatadata VDI in the XAPI database, could you try to launch a xe sr-scan uuid=<SR UUID> and try again to disable CBT?
If it does not work, could you share the /var/log/SMlog of around the time you are trying to disable CBT?

I've sent you a DM for sharing the logs.. Unfortunately I "solved" the issue by deleting all snapshots related to each VM. Including CBT ones. That did make it so I could toggle CBT on the VDIs again.

But I've collected the logs for you.

This also seems like a good time to raise my suggestion to have somewhere at vates where we could upload details in a similar way to how TrueNAS does it. Suggested here: https://feedback.vates.tech/posts/69/suggesting-to-add-a-debug-file-option

rzr

New security and maintenance update candidates for XCP-ng 8.3 LTS (kernel)

This release batch contains security fixes on the Linux kernel in dom0, version updates, some bug fixes and a few improvements.

What changed

Virtualization & System

kernel: Update to 4.19.19-8.0.46.5
- Fixes multiple vulnerabilities:
  - CVE-2026-46300: A logic error in the network stack could allow an unprivileged local user to escalate its privileges to root by modifying page caches for file-backed files that were not supposed to be writable. The modifications are not persistent to a reboot (i.e. no disk corruption). This vulnerability is used by the public exploit Fragnesia.
  - CVE-2026-46333: Incorrect tracking of users privilege level when a task is exiting in the ptrace sub-system could allow an unprivileged local user to escalate its privileges to root by writing to file descriptors they are not supposed to have access to. The changes made to potentially root-owned files are persisted across reboots. This vulnerability is used by the public exploits ssh-keysign-pwn as well as ptrace_may_dream.
  - CVE-2026-43494: A double-free of pinned pages in the RDS kernel module in the transmit error path could allow an unprivileged local user to escalate its privileges to root by modifying page caches for file-backed files, allowing them to for example overwrite a SUID binary in page cache with a shellcode. Changes are not persistent across reboots. This vulnerability is used by the public exploit pintheft.
qemu: Fix a potential issue in guest memory mapping lookup.
edk2:
- Fix issues while booting from physical CD/DVD drive.
- Bump UEFI guest vCPU limit to 128 vCPU (was 96 vCPUs)
dmidecode: Update to 3.6-3
- Version able to read type 42 tables (redfish)
varstored: Update to 1.3.2-2.1
- Sync with upstream.
ipxe: PXE boot support of BIOS VMs on a VLAN with 802.1Q priority tags

Control plane

xapi: Enable USB passthrough of smartcards

Storage

blktap: No functional change. Only sync with upstream.

Network

openssh: Drop support of insecure clients
- Old OpenSSH clients (version less than 7.2) can no longer connect with ssh-rsa (due to SHA-1 being no longer accepted by the server).
- The solution is either to update OpenSSH-clients (to a version >= 7.2), or to generate and use ED25519 keys.

Others

libtasn1: Update to 4.21.0 (hardening)
fuse: Rebuild
slang: Rebuild
systemtap: Rebuild

Optional packages

libreswan: Rebuild
netdata: Rebuild

Versions:

blktap: 3.55.5-6.7.xcpng8.3 -> 3.55.5-9.1.xcpng8.3
dmidecode: 1:3.0-5.el7 -> 1:3.6-3.xcpng8.3
edk2: 20220801-1.7.10.1.xcpng8.3 -> 20220801-1.7.11.1.xcpng8.3
fuse: 2.9.2-10.xcpng8.3 -> 2.9.2-10.1.xcpng8.3
ipxe: 20121005-1.0.7.xcpng8.3 -> 20121005-1.0.8.xcpng8.3
kernel: 4.19.19-8.0.46.3.xcpng8.3 -> 4.19.19-8.0.46.5.xcpng8.3
libreswam: 4.12-2.3.1.xcpng8.3 -> 4.12-2.3.2.xcpng8.3
libtasn1: 4.10-1.el7 -> 4.21.0-1.xcpng8.3
openssh: 9.8p1-1.2.3.xcpng8.3 -> 9.8p1-1.2.4.xcpng8.3
netdata: 1.47.5-4.2.xcpng8.3 -> 1.47.5-4.3.xcpng8.3
qemu: 2:4.2.1-5.2.17.1.xcpng8.3 -> 2:4.2.1-5.2.18.1.xcpng8.3
slang: 2.3.2-11.xcpng8.3 -> 2.3.2-11.1.xcpng8.3
systemtap: 4.0-5.2.xcpng8.3 -> 4.0-5.3.xcpng8.3
varstored: 1.3.1-2.1.xcpng8.3 -> 1.3.2-2.1.xcpng8.3
xapi: 26.1.4-3.1.xcpng8.3 -> 26.1.4-3.2.xcpng8.3

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.

What to test

As usual, normal use and anything else you want to test.

Test window before official release of the updates

~1 day

We would like to thank users who reported feedback since our last call for testing:

@Andrew, @acebmxer, @flakpyro, @greg_e, @jeffberntsen, @marcoi, @ovicz, @ph7, @probain.

Andrew

@rzr nslookup is broken, but it was before this update too.

nslookup vates.com 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   vates.com
Address: 104.21.52.238
Name:   vates.com
Address: 172.67.205.118

openssl_link.c:132: INSIST(dst__memory_pool != ((void *)0)) failed, back trace
#0 0x7fb705ab80e7 in ??
#1 0x7fb705ab803a in ??
#2 0x7fb7066c5780 in ??
#3 0x7fb704ed0df6 in ??
#4 0x7fb704f17464 in ??
#5 0x7fb704f17732 in ??
#6 0x7fb704f16b8d in ??
#7 0x7fb703681bd9 in ??
#8 0x7fb703681c27 in ??
#9 0x7fb70366a44c in ??
#10 0x405818 in ??
Aborted (core dumped)

acebmxer

@rzr

Updated both hosts at home with no issues. Will continue to test.

Dependency Installed:
  libtasn1-tools.x86_64 0:4.21.0-1.xcpng8.3                                                                                              

Updated:
  blktap.x86_64 0:3.55.5-9.1.xcpng8.3                                  dmidecode.x86_64 1:3.6-3.xcpng8.3                                
  edk2.x86_64 0:20220801-1.7.11.1.xcpng8.3                             forkexecd.x86_64 0:26.1.4-3.2.xcpng8.3                           
  fuse-libs.x86_64 0:2.9.2-10.1.xcpng8.3                               ipxe.noarch 0:20121005-1.0.8.xcpng8.3                            
  kernel.x86_64 0:4.19.19-8.0.46.5.xcpng8.3                            libtasn1.x86_64 0:4.21.0-1.xcpng8.3                              
  libtasn1-devel.x86_64 0:4.21.0-1.xcpng8.3                            message-switch.x86_64 0:26.1.4-3.2.xcpng8.3                      
  openssh.x86_64 0:9.8p1-1.2.4.xcpng8.3                                openssh-clients.x86_64 0:9.8p1-1.2.4.xcpng8.3                    
  openssh-server.x86_64 0:9.8p1-1.2.4.xcpng8.3                         qcow-stream-tool.x86_64 0:26.1.4-3.2.xcpng8.3                    
  qemu.x86_64 2:4.2.1-5.2.18.1.xcpng8.3                                rrdd-plugins.x86_64 0:26.1.4-3.2.xcpng8.3                        
  slang.x86_64 0:2.3.2-11.1.xcpng8.3                                   sm-cli.x86_64 0:26.1.4-3.2.xcpng8.3                              
  squeezed.x86_64 0:26.1.4-3.2.xcpng8.3                                systemtap-runtime.x86_64 0:4.0-5.3.xcpng8.3                      
  varstored.x86_64 0:1.3.2-2.1.xcpng8.3                                varstored-guard.x86_64 0:26.1.4-3.2.xcpng8.3                     
  varstored-tools.x86_64 0:1.3.2-2.1.xcpng8.3                          vhd-tool.x86_64 0:26.1.4-3.2.xcpng8.3                            
  wsproxy.x86_64 0:26.1.4-3.2.xcpng8.3                                 xapi-core.x86_64 0:26.1.4-3.2.xcpng8.3                           
  xapi-nbd.x86_64 0:26.1.4-3.2.xcpng8.3                                xapi-rrd2csv.x86_64 0:26.1.4-3.2.xcpng8.3                        
  xapi-storage-script.x86_64 0:26.1.4-3.2.xcpng8.3                     xapi-tests.x86_64 0:26.1.4-3.2.xcpng8.3                          
  xapi-xe.x86_64 0:26.1.4-3.2.xcpng8.3                                 xcp-networkd.x86_64 0:26.1.4-3.2.xcpng8.3                        
  xcp-rrdd.x86_64 0:26.1.4-3.2.xcpng8.3                                xenopsd.x86_64 0:26.1.4-3.2.xcpng8.3                             
  xenopsd-cli.x86_64 0:26.1.4-3.2.xcpng8.3                             xenopsd-xc.x86_64 0:26.1.4-3.2.xcpng8.3

JeffBerntsen

@rzr

Installed on my test systems and all seems to be working well so far.

rzr

@Andrew said:

Thank you for this report, I fear this issue appeared when we rebuilt bind with openssl-3

nslookup vates.com 8.8.8.8

I confirm this issue, note that bind-utils is not installed by default, let me investigate.

acebmxer

@rzr

[09:43 xcp-ng-haznrrtw ~]# nslookup vates.com 8.8.8.8
-bash: nslookup: command not found

[10:21 xcp-ng-haznrrtw ~]# yum install bind-utils -y
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Excluding mirror: updates.xcp-ng.org
 * xcp-ng-base: mirrors.xcp-ng.org
Excluding mirror: updates.xcp-ng.org
 * xcp-ng-updates: mirrors.xcp-ng.org
Resolving Dependencies
--> Running transaction check
---> Package bind-utils.x86_64 32:9.9.4-63.1.xcpng8.3 will be installed
--> Processing Dependency: bind-libs = 32:9.9.4-63.1.xcpng8.3 for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64
--> Processing Dependency: libbind9.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64
--> Processing Dependency: libdns.so.100()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64
--> Processing Dependency: libisc.so.95()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64
--> Processing Dependency: libisccc.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64
--> Processing Dependency: libisccfg.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64
--> Processing Dependency: liblwres.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64
--> Running transaction check
---> Package bind-libs.x86_64 32:9.9.4-63.1.xcpng8.3 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================================================================
 Package                      Arch                     Version                                    Repository                        Size
=========================================================================================================================================
Installing:
 bind-utils                   x86_64                   32:9.9.4-63.1.xcpng8.3                     xcp-ng-updates                   126 k
Installing for dependencies:
 bind-libs                    x86_64                   32:9.9.4-63.1.xcpng8.3                     xcp-ng-updates                   948 k

Transaction Summary
=========================================================================================================================================
Install  1 Package (+1 Dependent package)

Total download size: 1.0 M
Installed size: 3.0 M
Downloading packages:
(1/2): bind-libs-9.9.4-63.1.xcpng8.3.x86_64.rpm                                                                   | 948 kB  00:00:00     
(2/2): bind-utils-9.9.4-63.1.xcpng8.3.x86_64.rpm                                                                  | 126 kB  00:00:01     
-----------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                    855 kB/s | 1.0 MB  00:00:01     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : 32:bind-libs-9.9.4-63.1.xcpng8.3.x86_64                                                                               1/2 
  Installing : 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64                                                                              2/2 
  Verifying  : 32:bind-libs-9.9.4-63.1.xcpng8.3.x86_64                                                                               1/2 
  Verifying  : 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64                                                                              2/2 

Installed:
  bind-utils.x86_64 32:9.9.4-63.1.xcpng8.3                                                                                               

Dependency Installed:
  bind-libs.x86_64 32:9.9.4-63.1.xcpng8.3                                                                                                

Complete!
[10:22 xcp-ng-haznrrtw ~]# nslookup vates.com 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   vates.com
Address: 172.67.205.118
Name:   vates.com
Address: 104.21.52.238

openssl_link.c:132: INSIST(dst__memory_pool != ((void *)0)) failed, back trace
#0 0x7f419d8790e7 in ??
#1 0x7f419d87903a in ??
#2 0x7f419e486780 in ??
#3 0x7f419cc91df6 in ??
#4 0x7f419ccd8464 in ??
#5 0x7f419ccd8732 in ??
#6 0x7f419ccd7b8d in ??
#7 0x7f419b442bd9 in ??
#8 0x7f419b442c27 in ??
#9 0x7f419b42b44c in ??
#10 0x405818 in ??
Aborted (core dumped

Edit -No further issues to report at this time.

flakpyro

Installed on my usual batch of test hosts, no issues so far.

MajorP93

Hi,

I installed the update candidates within my test environment.

Updates installed fine, after reboot all looks good so far.

No apparent issues can be seen.

ph7

Maybe this schould be under XO/Backup
Anyhow.

ph7 said:

Ran the 2 updates released today and...
Back to only showing one VM in Backup/Restore as it did a month or 2 ago.
Ran the replication job and all VMs showed up in Backup/Restore again. (XO5)

It occurred again today, only showing 1 VM in restore
XO daefc
Host updated 2 weeks ago.
After 1 scheduled CR job ran all VMs showed up again