Honestly, the confusion makes total sense; GitHub does a great job of hiding this stuff. Here's what's going on: those markdown files only exist right now as a proposed change sitting on a branch. That's the whole reason you can only get to them through the pull link, and nowhere else. They become a real, permanent part of the repo the moment you merge them in. And since it's your repo, that merge is yours to do, no special GitHub-fu required. Open the PR page (https://github.com/tobiaskreidl/Citrix-Tobias-Kreidl-Collection/pull/1), scroll down a bit, and click the green Merge pull request button. That's the "commit" step you were asking about. There's one wrinkle worth knowing about, and it's the real reason none of this shows up on your main repo page. Your repository has a couple of branches. Your existing PDFs and the Word doc live on a branch called XenServer-Articles, so I pointed my PR at that same branch to drop the markdown right next to them. But the page GitHub shows when someone visits your repo is a different branch called main, which at the moment only holds a README. So even after you merge, the articles will sit on XenServer-Articles, not on that front page. That's actually been true of your PDFs all along; it's nothing my PR changed. If you'd like the articles to show up on the landing page too, there are two easy ways, and I'm happy to do either one for you. We can change the repo's default branch to XenServer-Articles in Settings > Branches, so that one becomes the front page. Or I open a second small PR copying everything over to main. Just tell me which you'd rather have. So the short version: merge the PR to make the markdown real, then we can decide whether you also want the front page pointing at the articles. No rush at all on that second part. gounthar opened this pull request in tobiaskreidl/Citrix-Tobias-Kreidl-Collection open Add Markdown versions of the three articles (render inline on GitHub) #1

@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

@acebmxer had a combo error on some VMs "fell back to full" and "not referenced by any backup" but no tranfer size either. can't screenshot it anymore, I did a rollback to XOA 6.3 for the time being, snapshoted just before the upgrade

@mdm Similar to the name-description parameter, the CLI ignores this parameter. The expected way to use would be to set the field value after the SR has been created. I'll make a work item to change the CLI and warn of ignored parameters so confusion like this doesn't happen

@pdonias confirmed... [image: 1780065202934-screenshot-2026-05-29-103255.png]

@semarie I'll try to investigate to help you. Is it possible to run: stat /etc/xensource/xapi-pool-tls.pem openssl x509 -in /etc/xensource/xapi-pool-tls.pem -noout -text stat /etc/xensource/xapi-ssl.pem openssl x509 -in /etc/xensource/xapi-ssl.pem -noout -text (This file must exist; if not, I'd like the output of cat /etc/stunnel/xapi.conf.) And I'd like the same output for /etc/xensource/xapi-ssl.pem. If the certificate for /etc/xensource/xapi-pool.tls.pem has expired or it's empty, you can run: xe host-refresh-server-certificate host=$(hostname) If the certificate for /etc/xensource/xapi-ssl.pem has expired or it's empty, you can run: xe host-emergency-reset-server-certificate After running one of the two commands above, I recommend to do: xe-toolstack-restart (This should indeed restart the stunnel@xapi.service) I hope this helps.

Hi @halvor, FYI, ACL V2 / RBAC is now available in the REST API. You can create a privilege that only give you read privilege on your host. You can see the RBAC doc. A dedicated thread is available on the forum thread, please feel free to share your feedback. Thank you.

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.

It hurts (4y ) but I'm glad we finally managed to get what you needed!! Thanks for posting a comment in here after all this time [image: 1779991585587-21cd8648-f61e-46d9-a52f-4ec55a7b7c8b-image.jpeg]

@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

@pierrebrunet I inadvertently found more information yesterday. I installed an old e492b commit on a new machine, configured identically to the original, and got a different error but the same effect. The new error is: xcp xo backup Error: read ETIMEDOUT That lead me to this page: https://xcp-ng.org/forum/topic/10799/backup-timeout-error I moved the XO machine onto the same subnet as XCP, leaving the storage behind in a different network. This fixed the issue, at least on commit e492b ... I have not yet tried it on the new release... however I am pretty confident it will be successful. If I'm honest, I think this is a tuning issue between XO and XCP. XO is now mounting an NFS share across this subnet boundary and that mount is not having any sort of performance issue, but for some reason XO times out transferring the same data from dom0? That seems off to me. It's not a probem moving XO to the other subnet, so I've done that, but maybe this deserves a look in the future.

Hi @jedimarcus, FYI, VIF creation is possible via the REST API POST /rest/v0/vifs

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.

@simonp said: @acebmxer Hi, Thanks to your help we were able to identify an issue with Redis that we think is the source of the v6 dashboard loading issue. Could you try and checkout the fix_redis_encryption_issue branch, rebuild xo and restart ? This should solve the 401 issues. Switched back to Master branch and made some changes to my install script. add diagnostics for missing XO 6 web UI build artifacts Plain bash [[ -f ]] fails silently on unreadable paths owned by SERVICE_USER, causing false-positive missing-artifact warnings. Switch all file/dir tests and grep calls to use sudo. SUCCESS] Xen Orchestra built successfully [INFO] Build verification passed: dist — all JS chunks present. [INFO] Build verification passed: dist — all JS chunks present. [INFO] Creating systemd service... [SUCCESS] Systemd service created and enabled [INFO] Configuring sudo for xo-service (mount/umount/findmnt)... [SUCCESS] Sudo configured for xo-service (mount, umount, findmnt) [INFO] Applying security hardening... [INFO] Starting xo-server service... [INFO] Waiting for Xen Orchestra to become ready (up to 60s)... [INFO] Not ready yet (attempt 1/10), retrying in 6s... [SUCCESS] Xen Orchestra is ready (HTTPS on port 443) [SUCCESS] Update completed successfully! [INFO] New commit: 0f29421627c7 v6 Dashboard still loading correctly. Thank you for the fix.

@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.

@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

Hi, @14wkinnersley We merged the PATCH /vms/:id endpoint onto the master branch

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

@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]