Quick update now that Vates has published their official advisory. First, kudos to the Vates security team for the thorough and timely response. VSA-2026-014 is well-documented and covers the full picture, including a third CVE I had not covered in my earlier posts. VSA-2026-014 confirms what I outlined above: XCP-ng is affected by CVE-2026-43284 (XFRM-ESP) and is NOT affected by CVE-2026-43500 (no RxRPC support). The CVE I had missed: CVE-2026-46300 ("Fragnesia") also affects XCP-ng via the XFRM ESP-in-TCP subsystem. The same esp4/esp6 blacklist mitigation applies, with the same caveat @semarie raised: it will break encrypted private networks on XCP-ng. Now that the VSA and official mitigation guidance are public, I'm releasing the diagnostic script I built. It's Python 3.6, no external dependencies, safe to run on production dom0. It tests whether an unprivileged process can engage the esp4 engine via the XFRM interface inside a user namespace — without touching any exploit code. Since both CVE-2026-43284 and CVE-2026-46300 (Fragnesia) require esp4 or esp6 to be reachable from an unprivileged namespace, and share the same mitigation, a positive result confirms exposure to both. Blacklist esp4/esp6, then run the script again — ACCESS DENIED means both CVEs are mitigated. One important note before running it: please read the code before executing it on any of your systems. This is good practice with any script from the internet, regardless of the source. The code is intentionally short and straightforward so you can review it quickly and satisfy yourself that it does exactly what it says. VSA-2026-014: https://docs.vates.tech/security/advisories/2026/vates-sa-2026-014/ Diagnostic tool: https://github.com/grabesec/XCP_ng_CVE-2026-43284_tester A kernel patch from Vates is in progress. Apply as soon as it lands.

@dthenot said: @ccooke Hello, You should be able to make the XOSTOR SR work again if you update sm and sm-fairlock on the other hosts. yum update sm sm-fairlock Then you should be able to re-plug the SR on the master and proceed with the RPU. Hello, Had the same problem, the command resolved the issue. It needs to be run on every host. Everything is working fine again. However, I had to complete the pool update manually.

@pkgw I tested it with a cluster size of 2 megabytes. I got similar results to those with the default size.

@julienXOvates Correct, latest XO branch is the problem. It was fine before... { "data": { "mode": "delta", "reportWhen": "never" }, "id": "1780192695536", "jobId": "d6c0a656-62c5-4c39-a57a-f246b39f1cef", "jobName": "minio-test", "message": "backup", "scheduleId": "bd4ef436-fd85-4f16-bf9e-71d1d0c8586f", "start": 1780192695536, "status": "success", "tasks": [ { "id": "0mpt4ron3-juzrilzvn0s", "start": 1780192697727, "status": "success", "tasks": [ { "id": "0mpt4ron9-pxah6gpi19", "start": 1780192697733, "status": "success", "end": 1780192698044, "result": { "merge": false, "size": 0 }, "message": "clean-vm" }, { "id": "0mpt4rpwm-ujzdf5a8ad", "start": 1780192699366, "status": "success", "end": 1780192700817, "result": "0d3f6e5e-fd58-7368-7d54-c892809927b6", "message": "snapshot" }, { "id": "0mpt4rr0x-sfehspx3ey", "start": 1780192700817, "status": "success", "tasks": [ { "id": "0mpt4rsdg-t05980lobz", "start": 1780192702564, "status": "success", "end": 1780192702622, "result": { "size": 43008 }, "message": "transfer" }, { "id": "0mpt4rts7-5p0b0d1r94y", "start": 1780192704391, "status": "success", "tasks": [ { "id": "0mpt4rtvx-0rtl320os8g", "start": 1780192704525, "status": "success", "end": 1780192704782, "message": "merge" } ], "warnings": [ { "data": { "alias": "/xo-vm-backups/a081f208-4e40-2ca5-c68e-86106af5a8ef/vdis/d6c0a656-62c5-4c39-a57a-f246b39f1cef/cbb7809e-8296-4dc6-8200-ed1f42e50c68/20260531T015641Z.alias.vhd", "err": { "$fault": "client", "$metadata": { "httpStatusCode": 404, "requestId": "18B483D548936DAB", "extendedRequestId": "a18350611414fa9366e109699727e695e309120afc9803fcaff78a199f9bc4d6", "attempts": 1, "totalRetryDelay": 0 }, "name": "NotFound", "message": "UnknownError" } }, "message": "unhandled error while checking alias" } ], "end": 1780192704964, "result": { "merge": true, "size": 8235471872 }, "message": "clean-vm" } ], "end": 1780192704964, "message": "export", "data": { "id": "9890e0c4-ba3a-4810-8245-a49fdf16b16e", "isFull": false, "type": "remote" } } ], "infos": [ { "message": "Transfer data using NBD" }, { "message": "will delete snapshot data" }, { "data": { "vdiRef": "OpaqueRef:50cca589-9c8c-478c-dac8-56debab464bb" }, "message": "Snapshot data has been deleted" } ], "end": 1780192704964, "message": "backup VM", "data": { "id": "a081f208-4e40-2ca5-c68e-86106af5a8ef", "type": "VM", "name_label": "Utest" } } ], "end": 1780192704964, "infos": [ { "data": { "vms": [ "a081f208-4e40-2ca5-c68e-86106af5a8ef" ] }, "message": "vms" } ] } May 30 21:58:24 xo2 xo-server[1180]: 2026-05-31T01:58:24.525Z xo:backups:MixinBackupWriter INFO Disk chain needs merging { count: 1 } May 30 21:58:24 xo2 xo-server[1180]: 2026-05-31T01:58:24.526Z xo:backups:MixinBackupWriter INFO merging disk chain { May 30 21:58:24 xo2 xo-server[1180]: chain: [ May 30 21:58:24 xo2 xo-server[1180]: '/xo-vm-backups/a081f208-4e40-2ca5-c68e-86106af5a8ef/vdis/d6c0a656-62c5-4c39-a57a-f246b39f1cef/cbb7809e-8296-4dc6-8200-ed1f42e50c68/20260531T015641Z.alias.vhd', May 30 21:58:24 xo2 xo-server[1180]: '/xo-vm-backups/a081f208-4e40-2ca5-c68e-86106af5a8ef/vdis/d6c0a656-62c5-4c39-a57a-f246b39f1cef/cbb7809e-8296-4dc6-8200-ed1f42e50c68/20260531T015759Z.alias.vhd' May 30 21:58:24 xo2 xo-server[1180]: ] May 30 21:58:24 xo2 xo-server[1180]: } May 30 21:58:24 xo2 xo-server[1180]: 2026-05-31T01:58:24.788Z xo:backups:MixinBackupWriter WARN unhandled error while checking alias { May 30 21:58:24 xo2 xo-server[1180]: alias: '/xo-vm-backups/a081f208-4e40-2ca5-c68e-86106af5a8ef/vdis/d6c0a656-62c5-4c39-a57a-f246b39f1cef/cbb7809e-8296-4dc6-8200-ed1f42e50c68/20260531T015641Z.alias.vhd', May 30 21:58:24 xo2 xo-server[1180]: err: NotFound: UnknownError May 30 21:58:24 xo2 xo-server[1180]: at S3RestXmlProtocol.handleError (/opt/xo/xo-builds/xen-orchestra-202605291150/node_modules/@aws-sdk/core/dist-cjs/submodules/protocols/index.js:1850:27) May 30 21:58:24 xo2 xo-server[1180]: at process.processTicksAndRejections (node:internal/process/task_queues:104:5) May 30 21:58:24 xo2 xo-server[1180]: at async S3RestXmlProtocol.deserializeResponse (/opt/xo/xo-builds/xen-orchestra-202605291150/node_modules/@smithy/core/dist-cjs/submodules/protocols/index.js:424:13) May 30 21:58:24 xo2 xo-server[1180]: at async /opt/xo/xo-builds/xen-orchestra-202605291150/node_modules/@smithy/core/dist-cjs/submodules/schema/index.js:27:24 May 30 21:58:24 xo2 xo-server[1180]: at async /opt/xo/xo-builds/xen-orchestra-202605291150/node_modules/@aws-sdk/middleware-sdk-s3/dist-cjs/index.js:387:20 May 30 21:58:24 xo2 xo-server[1180]: at async /opt/xo/xo-builds/xen-orchestra-202605291150/node_modules/@smithy/core/dist-cjs/submodules/retry/index.js:172:50 May 30 21:58:24 xo2 xo-server[1180]: at async /opt/xo/xo-builds/xen-orchestra-202605291150/node_modules/@aws-sdk/middleware-sdk-s3/dist-cjs/index.js:64:28 May 30 21:58:24 xo2 xo-server[1180]: at async /opt/xo/xo-builds/xen-orchestra-202605291150/node_modules/@aws-sdk/middleware-sdk-s3/dist-cjs/index.js:91:20 May 30 21:58:24 xo2 xo-server[1180]: at async /opt/xo/xo-builds/xen-orchestra-202605291150/node_modules/@aws-sdk/middleware-logger/dist-cjs/index.js:5:26 May 30 21:58:24 xo2 xo-server[1180]: at async S3Handler._getSize (/opt/xo/xo-builds/xen-orchestra-202605291150/@xen-orchestra/fs/dist/s3.js:304:20) { May 30 21:58:24 xo2 xo-server[1180]: '$fault': 'client', May 30 21:58:24 xo2 xo-server[1180]: '$retryable': undefined, May 30 21:58:24 xo2 xo-server[1180]: '$metadata': { May 30 21:58:24 xo2 xo-server[1180]: httpStatusCode: 404, May 30 21:58:24 xo2 xo-server[1180]: requestId: '18B483D548936DAB', May 30 21:58:24 xo2 xo-server[1180]: extendedRequestId: 'a18350611414fa9366e109699727e695e309120afc9803fcaff78a199f9bc4d6', May 30 21:58:24 xo2 xo-server[1180]: cfId: undefined, May 30 21:58:24 xo2 xo-server[1180]: attempts: 1, May 30 21:58:24 xo2 xo-server[1180]: totalRetryDelay: 0 May 30 21:58:24 xo2 xo-server[1180]: } May 30 21:58:24 xo2 xo-server[1180]: } May 30 21:58:24 xo2 xo-server[1180]: } May 30 21:58:24 xo2 xo-server[1180]: 2026-05-31T01:58:24.964Z xo:backups:worker INFO backup has ended

I'm waiting for veeam 13.1 release as well. Will move a few things over and test out the native backup in the meantime.

@Rod-G These have 9.4.2-xxxx and I need to go through and update everything now that I see how far behind I am. the second VM completed fine after its reboot, something was just stuck in a dirty state and got in the way of the import or health check.

@maximsachs Thanks for getting back to me on this. I think (and hope) that in the mean time we will have released an official new ISO that fixes the issue you are having. So, you will be better off testing the new official ISO rather than this unofficial one I'll try to ping here when the new official ISO is out. Thanks! Regards, Yann

Thank you all (@olivierlambert , @teddyastie ) for your valuable responses

@dthenot said: you will also likely need to give the host-uuid of the host the disk is on Thanks, and I'm assuming this UUID or Machine ID from: [14:45 xcp-kbbn NAS]# dmidecode --type SYSTEM # dmidecode 3.0 Getting SMBIOS data from sysfs. SMBIOS 3.3.0 present. # SMBIOS implementations newer than version 3.0 are not # fully supported by this version of dmidecode. Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: ASUS Product Name: System Product Name Version: System Version Serial Number: System Serial Number UUID: E7AE9723-CB08-A278-5C45-7C10C9473BD0 Wake-up Type: Power Switch SKU Number: SKU Family: To be filled by O.E.M. OR [12:46 xcp-kbbn NAS]# hostnamectl Static hostname: xcp-kbbn Icon name: computer-desktop Chassis: desktop Machine ID: c668f529e66c42b9815fe12f3401df82 Boot ID: dd70b200b25341c688aee9fbc58d20a2 Virtualization: xen Operating System: XCP-ng 8.3 Kernel: Linux 4.19.0+1 Architecture: x86-64 the command would look like this correct: xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" host-uuid=E7AE9723-CB08-A278-5C45-7C10C9473BD0 or c668f529e66c42b9815fe12f3401df82 UPDATE: I tried the new command but I got these error messages: [14:45 xcp-kbbn NAS]# xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" host-uuid=E7AE9723-CB08-A278-5C45-7C10C9473BD0 The uuid you supplied was invalid. type: host uuid: E7AE9723-CB08-A278-5C45-7C10C9473BD0 [15:14 xcp-kbbn NAS]# ls [15:19 xcp-kbbn NAS]# xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" host-uuid=c668f529e66c42b9815fe12f3401df82 The uuid you supplied was invalid. type: host uuid: c668f529e66c42b9815fe12f3401df82 then I was successful (I believe with you confirmation) when I left our the host-uuid param: [15:19 xcp-kbbn NAS]# xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" b802722e-67ac-5aba-8d6c-e565d2d7fa0d and then it was listed as a SR: [image: 1779139583485-screenshot-from-2026-05-18-15-24-03.png] now to the next task command: xe sr-scan uuid=b802722e-67ac-5aba-8d6c-e565d2d7fa0d was successful, but I have another Question, the size of the device is not showing, is this normal being that it was done this way? UPDATE 2.0: I just discovered the xe command: [15:27 xcp-kbbn NAS]# xe host-list uuid ( RO) : 9a5e5bb3-bdb9-41ea-9505-6f6fe630f369 name-label ( RW): xcp-kbbn the uuid does not match the ones provided above, do I need to remove the SR and do it over again using this uuid? I will give it a try using another folder.... UPDATE 2.1: I executed the command using the above uuid: [15:35 xcp-kbbn srv]# xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" host-uuid=9a5e5bb3-bdb9-41ea-9505-6f6fe630f369 6fc531a0-19a0-b9c1-c78e-c687fce5ff84 and was successful, but now my question for the device size, is it normal or not due to creating it this way? UPDATE 2.2: I forgot to do: ln -s /dev/sda /srv/NAS/sda #although it might be better to use a stable identifier if you have multiple disks xe sr-scan uuid=<UUID of the udev SR> be right back..... UPDATE 3.0: Success, I have all HDs attached to my VM, access all files and the sizes are reported! : [image: 1779147782991-screenshot-from-2026-05-18-17-25-38.png] List of attached disks: [image: 1779147797114-screenshot-from-2026-05-18-17-18-07.png] The VM: [image: 1779148373193-screenshot-from-2026-05-18-17-51-19.png] Thanks for your help!...

@JL457 Hi, For now it looks like Wasabi is not sending us the correct date format, which is strange because we support this provider and don't usually have issues. In order to allow us to investigate further, could you send us the full backup job logs ? You can find them by clicking on the failed backup status and then on the download logs button: [image: 1779106635704-export-logs.png] Relevant XO logs would also help. If you are a client, also don't hesitate to open a ticket with an open support tunnel. Thanks.

@bvivi57 xo do check license if you have xostor installed, since it need some magic to work at a lot of steps ( like the rolling pool updates) this is the expected behavior with a manually installed xostor ( cc @julienxovates for information )

@yllar I'm not sure honestly (I will have to ask the rest of the team), but anyway, even if it were fixed by latest xen package, we still didn't publish a new installer ISO with the fix. Target is still around June for the new ISO. Regards, Yann

@florent said: @acebmxer back to work thank you for yor patience and help on this. I feel that it's not the same issue , with abrupt increase W will try our best to also fix this one Yes i replied to ticket also.... Yes you can do what is needed to XOA. Just looked at memory and it dropped.... [image: 1779875710969-screenshot_20260527_055458.png]

@tjkreidl I found that some Intel PRO GPU card have SRV-IO without any additional license, but this functionality is supported in Linux kernel 6.12 and up. I hope in new XCP-NG will have 6.12+ and support GPU sharing.

@tsukraw I am taking the ticket and will keep you informed as soon as possible

@Mathieu-L linstor n l was included in my original post. All nodes were updated to May 2026 Security and Maintenance Updates for XCP-ng 8.3 LTS, all nodes were restarted. May 2026 Updates #2 for XCP-ng 8.3 LTS was released, and a couple days later I installed on all hosts. No host restarted. When xen04 was restarted, that is when this issue happened. I had used systemctl restart linstor-controller here (https://xcp-ng.org/forum/post/105309) to restart the controller.

@gcpeters4 said: @john.c This is a good idea as well. If the previous suggestion of trying to do a DNS round robin approach doesn't work, this may be my best option. Thanks for taking the time to provide your suggestion! By the way my suggestion is recommended best practice from Microsoft for their Active Directory software and/or technology. My suggestion will be more likely to work if your DNS servers and requests have issues with Round Robin configuration. Plus with my solution you can easily add more servers as domain controllers to the cluster, as required and use replication to keep them consistent and up to date.

Because it works already better than the GO tool from Citrix… There's no urgent fix to do, I personally use it in my production since it's available. It's just less a priority for extra features because it's already ultra stable. Right now, we choose to work in priority on XCP-ng 9.0 than the Rust tools, we can't do everything at once yet.

@abudef An overhaul of the guest agent is coming. We're considering adding some kind of update notifications as part of that overhaul, but it'll take some time to suss out the details. Autoupdating the Xen drivers is potentially disruptive and I'd prefer avoiding outages arising from an update coming at a bad time.

I'm not positive, but this may be available RSN in xo-lite.