XCP-ng 8.3 updates announcements and testing

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.