Another confirmed data point, with package delta and the specific malformed field. Host: XCP-ng 8.3.0, xapi 26.1 (build 26.1.4), Xen 4.17.6-9. Setup: XO from sources (community). All VDIs vanished from the per-VM Disks tab (XO 5 and XO 6); xe and the SR Disks tab show them fine; VMs run normally. Trigger was the 8.3 host update + reboot this morning — XO build unchanged since May 28, disks visible yesterday. Host update delta (today): all 26.1.3-1.10 → 26.1.4-3.1 (xapi-core, xenopsd, sm-cli, sm-fairlock, xapi-storage-script, vhd-tool, message-switch, etc.), plus sm 3.2.12-17.8 → 17.9 as an independent bump. The malformed field. An affected live OS disk (VM running): is-a-snapshot: false snapshot-of: <populated, points to another VDI> snapshot-time: <populated> A normal base VDI should have an empty snapshot-of. After the update, snapshot-of/snapshot-time are populated on real, non-snapshot base VDIs, and XO filters anything with a non-empty snapshot-of out of the per-VM Disks view — which is the disappearance. The VDI that snapshot-of points to is a legitimate base image in my environment (a heavily-reused Win2022 build template with a large genuine snapshot/clone lineage), so I can't tell from the host side whether the parentage links themselves changed or only the snapshot-of on live VDI labeling did. Either way, the consumer-visible effect is the same. REST confirms: /rest/v0/vms/<uuid>/vdis → []; /rest/v0/vdis/<uuid> → "no such VDI" for the VBD's referenced UUID, while xe vdi-list shows it. Caution for others: since live disks now carry snapshot-like metadata, be careful with Health-dashboard "orphan" cleanup and snapshot deletion on affected VMs until this is understood. Workaround that restored the per-VM Disks view: snapshot → revert → delete-snapshot (tested on a powered-off VM, immediate). Happy to provide more diagnostics.

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