Hello Florent, The new code is still failing... [image: 1783007150129-a7b27068-0bbb-4ea6-b0e7-74f8058775f3-image.jpeg] ``` { "id": "0mr3li2kt-c10ifxuuw68", "start": 1783002246797, "status": "failure", "tasks": [ { "id": "0mr3li2ud-r1vgn4rnv5d", "start": 1783002247141, "status": "failure", "tasks": [ { "id": "0mr3li30l-6n1cr5a6o7v", "start": 1783002247365, "status": "failure", "end": 1783004124397, "result": { "message": "read 52428800012 bytes, maximum size allowed is 52428800000 ", "name": "Error", "stack": "Error: read 52428800012 bytes, maximum size allowed is 52428800000 \n at Transform.transform [as _transform] (/opt/xo/xo-builds/xen-orchestra-202607021439/@xen-orchestra/fs/dist/s3.js:214:20)\n at Transform._write (node:internal/streams/transform:171:8)\n at writeOrBuffer (node:internal/streams/writable:570:12)\n at _write (node:internal/streams/writable:499:10)\n at Writable.write (node:internal/streams/writable:508:10)\n at PassThrough.ondata (node:internal/streams/readable:1012:24)\n at PassThrough.emit (node:events:509:28)\n at PassThrough.patchedEmit [as emit] (/opt/xo/xo-builds/xen-orchestra-202607021439/@xen-orchestra/log/configure.js:52:17)\n at addChunk (node:internal/streams/readable:563:12)\n at readableAddChunkPushObjectMode (node:internal/streams/readable:540:3)" }, "message": "transfer", "data": { "progress": 0 } } ], "end": 1783004124397, "result": { "message": "read 52428800012 bytes, maximum size allowed is 52428800000 ", "name": "Error", "stack": "Error: read 52428800012 bytes, maximum size allowed is 52428800000 \n at Transform.transform [as _transform] (/opt/xo/xo-builds/xen-orchestra-202607021439/@xen-orchestra/fs/dist/s3.js:214:20)\n at Transform._write (node:internal/streams/transform:171:8)\n at writeOrBuffer (node:internal/streams/writable:570:12)\n at _write (node:internal/streams/writable:499:10)\n at Writable.write (node:internal/streams/writable:508:10)\n at PassThrough.ondata (node:internal/streams/readable:1012:24)\n at PassThrough.emit (node:events:509:28)\n at PassThrough.patchedEmit [as emit] (/opt/xo/xo-builds/xen-orchestra-202607021439/@xen-orchestra/log/configure.js:52:17)\n at addChunk (node:internal/streams/readable:563:12)\n at readableAddChunkPushObjectMode (node:internal/streams/readable:540:3)" }, "message": "export", "data": { "id": "14b59f44-4517-411e-9e39-4eb7136928d0", "type": "remote", "isFull": true } }, { "id": "0mr3mmbcf-yc4lpd0z5p", "start": 1783004124399, "status": "success", "warnings": [ { "data": { "path": "xo-vm-backups/1c842f34-f7f8-d3cd-ba24-ffe51d6ae075/cache.json.gz", "actual": 0, "expected": 1 }, "message": "unexpected number of entries in backup cache" }, { "data": { "error": { "generatedMessage": false, "code": "ERR_ASSERTION", "actual": true, "expected": false, "operator": "strictEqual", "diff": "simple" } }, "message": "Issue while checking XVA" }, { "data": { "error": { "generatedMessage": false, "code": "ERR_ASSERTION", "actual": true, "expected": false, "operator": "strictEqual", "diff": "simple" } }, "message": "Checksum file not valid, not blocking" }, { "data": { "path": "/xo-vm-backups/1c842f34-f7f8-d3cd-ba24-ffe51d6ae075/20260624T231818Z.xva" }, "message": "XVA might be broken" }, { "data": { "files": [ "20260624T231818Z.json", "20260624T231818Z.xva", "20260624T231818Z.xva.checksum" ] }, "message": "This files may be corrupted but not yet to be removed" } ], "end": 1783004124983, "result": { "merge": false, "size": 0 }, "message": "clean-vm" } ], "end": 1783004124983, "result": { "message": "read 52428800012 bytes, maximum size allowed is 52428800000 ", "name": "Error", "stack": "Error: read 52428800012 bytes, maximum size allowed is 52428800000 \n at Transform.transform [as _transform] (/opt/xo/xo-builds/xen-orchestra-202607021439/@xen-orchestra/fs/dist/s3.js:214:20)\n at Transform._write (node:internal/streams/transform:171:8)\n at writeOrBuffer (node:internal/streams/writable:570:12)\n at _write (node:internal/streams/writable:499:10)\n at Writable.write (node:internal/streams/writable:508:10)\n at PassThrough.ondata (node:internal/streams/readable:1012:24)\n at PassThrough.emit (node:events:509:28)\n at PassThrough.patchedEmit [as emit] (/opt/xo/xo-builds/xen-orchestra-202607021439/@xen-orchestra/log/configure.js:52:17)\n at addChunk (node:internal/streams/readable:563:12)\n at readableAddChunkPushObjectMode (node:internal/streams/readable:540:3)" }, "message": "backup VM", "data": { "id": "1c842f34-f7f8-d3cd-ba24-ffe51d6ae075", "type": "VM", "progress": 0 } }, Best regards, Pedro

@olivierlambert Thanks for the response, much appreciated. I'm getting ready to file a bug report, as I noticed this morning that this issue is now causing a VDI-IN-USE error; preventing me from starting a VM. Fortunately, that VM isn't critical, so I want to report it and help with the troubleshooting that will lead to a fix before it spreads.

@dvdwx said: Hi Anyone already tried to review why Users with User permission cannot have the topology menu to edit on their Self-Service resource page? the have admin permission on their self service resource set but cannot edit this setting: [image: 1783021889506-620b892c-4c04-47ca-8425-064dbceee3e8-image.jpeg] [image: 1783021936003-28d03549-b715-44b6-966f-5d4a5a905825-image.jpeg] If i log with and full admin account on Xen Orchestra it can be edited: [image: 1783022030501-b4af0d96-e6c9-4aec-bd23-5b0869b9b31a-image.jpeg] We are using an HA Pool with 2 hosts to LAB for our NOC/SOC team. I already tried to create an ACL with user/tag/group with advanced permission but it release a full permission on the pool and it cannot be delivered to the team. if anyone know a workaround to fix it.. I appreciate that. As RBAC ACL is implemented for Xen Orchestra 6 you’ll likely find this more possible than currently on Xen Orchestra 5.

Actually after latest XO update I also started to see "body timeout error". Interestingly on my metadata backup job.

Is there anything mentioned in the motherboard or service manuals, about where if one PCIe slot is occupied another is running at reduced speed when occupied? Something like this is in the manual for a Gigabyte B450 Aorus Elite (Rev 1.0) motherboard, for example. Can be in yours, somewhere written on one of its pages.

That's excellent news, thanks a lot for the feedback!

Hello @mgr42 I can confirm that indeed today AMD iGPU passthrough is not working on XCP-ng. I am currently (slowly) working on it. There are other references about this topic in the Forum and on GitHub FYI: https://xcp-ng.org/forum/topic/11918/amd-barcelo-passthrough-issues-any-success-stories https://xcp-ng.org/forum/topic/8909/issue-to-load-gpu-passthrough-invalid-pci-rom-header-signature-expecting-0xaa55-got-0x4556 https://github.com/xcp-ng/xcp/issues/806 https://github.com/xapi-project/xen-api/commit/930ffb34e42d674b8234c3d8399fdba97efa6b38 On the setup I am working on, the Expansion ROM is provided indeed by firmware via the VFCT ACPI table. I dumped it to a file and provided it to qemu-dm xen-pci-passthrough device via the romfile= argument (via a modified XAPI build). I can now indeed see a ROM bar in the guest but unfortunately its content is not the content of the file therefore nothing works (amdgpu driver is unable to get its ROM and fails). So now I'm debugging qemu to try to understand the issue with the emulated/passed-through ROM BAR. Regards, Yann Kernel & Hypervisor team timemaster5 created this issue in xcp-ng/xcp open Unable to set romfile for xen-pci-passthrough devices #806 0 freddy77 committed to xapi-project/xen-api CA-418993: Enable PCI ROM BAR before attempting to give permissions to the VM Currently the VM is not able to access the ROM as the host ROM BAR is disabled and not set. Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>

Ping @julienXOVates

Ping @julienXOVates

PRs upstream are in review