@MajorP93 said: What you are describing must be a storage live migration then (XenMotion). That should work across pools, yes. I stand corrected because I did not factor in this variant in my initial answer. Yes, that's it - sorry - I should have been more explicit, even if 'lumbers along' wasn't a hint //EDIT: also there is no such thing as non-pool hosts. Even a single host setup has it's own pool. Pedantic, but true I technically meant 'not hosts in the source pool' I guess.

@TrapoSAMA said: @john.c I have this iso but how to know what is de package? Thx It’s going to be an msi installer package or on the guest tools iso, which is on the XCP-ng or Xen Server your running likely in Local Storage SR or Shared Storage SR (if moved). Named the same as the file linked to above, likely. Anyway did you know that the UEFI SecureBoot certificates (at least one of them from 2011) issued by Microsoft are expiring fully during October 2026. Around that time likely at sometime after then those certificates will be placed into dbx. This means the Windows Server 2012 R2 if operating as a UEFI SecureBoot VM, will if restarted (or reboot following a crash), fail to boot. So your client will go from having a working app that they can use, but not upgrade at the moment to one which won’t work and can’t be used! They really need to upgrade or migrate from Windows to Linux (released during 2025 or 2026) along with the app if needed. Alternatively upgrade to Windows Server 2022 or 2025 and the app!

So if i set VMs to Best-effort or disabled for HA i get not enough memory. @pkgw Do you have Twinstore configured and/or HA enabled? If no I will continue my issues at the twinstore post. If i set to restart i get this.... host.setMaintenanceMode { "id": "35233210-4e37-4703-9bf6-9e8a9c24df9f", "maintenance": true } { "code": "HA_OPERATION_WOULD_BREAK_FAILOVER_PLAN", "params": [], "call": { "duration": 5, "method": "host.disable", "params": [ "* session id *", "OpaqueRef:d9bd976f-445c-8244-1b56-879f446efc12" ] }, "message": "HA_OPERATION_WOULD_BREAK_FAILOVER_PLAN()", "name": "XapiError", "stack": "XapiError: HA_OPERATION_WOULD_BREAK_FAILOVER_PLAN() 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)" }

@pierrebrunet said: Another thing to check is the exact time between your XO and your host. I installed the host with NTP from "static" DHCP (OK according to https://docs.xcp-ng.org/installation/requirements/) not made any manual changes/configs After I did a RTC adjustment in BIOS 3 days ago, the time now is ~1s ahead This is the output from timedatectl [22:04 x2 ~]# timedatectl status Local time: tor 2026-07-16 22:06:45 CEST Universal time: tor 2026-07-16 20:06:45 UTC RTC time: tor 2026-07-16 20:06:42 Time zone: Europe/Stockholm (CEST, +0200) NTP enabled: yes NTP synchronized: no RTC in local TZ: no DST active: yes Last DST change: DST began at sön 2026-03-29 01:59:59 CET sön 2026-03-29 03:00:00 CEST Next DST change: DST ends (the clock jumps one hour backwards) at sön 2026-10-25 02:59:59 CEST sön 2026-10-25 02:00:00 CET NTP synchronized: no I thought that the time would be adjusted automatically at reboot The first NTP sync should allow a bigger step than when it's already synced. @pierrebrunet said: do you make these backup regularly? They run once a day @ 03:04 before the normal backup that starts @ 03:10 and they have all run OK since July 8, the failed one reported 8 days ago ( post ~85 ) Maybe you should resync your clock NTP is enabled but not synced, I don't know the correct way to sync it In xsconsole/ I tried Use DHCP NTP Servers It changed the RTC clock to the same as UTC time but time was still 1s ahead and NTP not synced. I rebooted the host and I got this: [23:36 x2 ~]# timedatectl status Local time: tor 2026-07-16 23:37:17 CEST Universal time: tor 2026-07-16 21:37:17 UTC RTC time: tor 2026-07-16 21:37:16 Time zone: Europe/Stockholm (CEST, +0200) NTP enabled: yes NTP synchronized: no RTC in local TZ: no DST active: yes Last DST change: DST began at sön 2026-03-29 01:59:59 CET sön 2026-03-29 03:00:00 CEST Next DST change: DST ends (the clock jumps one hour backwards) at sön 2026-10-25 02:59:59 CEST sön 2026-10-25 02:00:00 CET NTP still not synced, Local time 2s ahead, RTC 1s ahead, I don't know, If not someone can show me the proper way to manually resync, maybe I should try to reinstall the host

@acebmxer I can confirm that, we'll fix it, thanks

Hi @Danp , I've updated XO to the latest commit and the error is still happening.

@pierrebrunet Hello! I've checked B2 logs and found some errors like you had foreseen. I had a look and this kind of 500 INTERNAL ERROR several times on other jobs that seem ok. How many retries does XO attempt to send the part when this happens? I'll do another run that includes only a few large VMs. BTW, is there a way to interrupt the job withou restarting XO ? REST.PUT.PART Weekly/xo-vm-backups/60b4d2a7-3f91-f0f9-b0a0-f834df3ff9ee/20260705T070618Z.xva "PUT /zzzzzkly/xo-vm-backups/60b4d2a7-3f91-f0f9-b0a0-f834df3ff9ee/20260705T070618Z.xva?partNumber=3954&uploadId=4_ze092693d1b65962e9fe6051b_f25969add7e42e384_d20260713_m140016_c003_v0312040_t0013_u01783951216751&x-id=UploadPart HTTP/1.1" 500 INTERNAL_ERROR 145 - 3762 3762 "-" "aws-sdk-js/3.1065.0 ua/2.1 os/linux#5.15.0-185-generic lang/js md/nodejs#24.18.0 api/s3#3.1065.0 m/N,a,c,E,e xen-orchestra-fs-4.9.2" - - - TLS_AES_256_GCM_SHA384 AuthHeader s3.eu-central-003.backblazeb2.com TLSv1.3 - -

@kagbasi-wgsdac said: @poddingue Bug report filed as requested — https://github.com/xcp-ng/xcp/issues/825 — and tagging @Team-Storage per your suggestion. Full evidence bundle is attached to the issue (versions, sweep output, vhd-util vs xe comparison, SMlog). Summary of what I found: One correction to the mechanism, and I think it matters. The recap describes is-a-snapshot being flipped to true. On my system that isn't what's happening — is-a-snapshot is false on every affected VDI. The field being wrongly written is snapshot-of, which is getting populated on base disks that aren't snapshots at all. XO's disappearing-disks symptom is consistent with either (it filters on a non-empty snapshot-of), but if the storage team is hunting for a bad is-a-snapshot write, that may be the wrong field. Every affected VDI here looks like: is-a-snapshot: false <-- correct snapshot-of: <populated with an unrelated VDI's UUID> <-- wrong A VDI that is a snapshot of itself. The clearest single artifact: uuid: 806f7f42-083f-4a40-b3f1-0700d00bab5a name-label: WinSrv2022SHB_Disk1_Data is-a-snapshot: false snapshot-of: 806f7f42-083f-4a40-b3f1-0700d00bab5a <-- itself snapshot-time: 20260709T11:19:15Z sm-config: vhd-parent: c86e3247-... <-- bears no relation to the snapshot-of value No valid code path produces snapshot-of = self. Whatever writes this field isn't validating the target. It's still actively corrupting new VDIs — this is not just legacy damage. That self-referential VDI was created 2026-07-09, a week after my patch + reboot. Sweeps 9 days apart went from ~180 → 191 affected VDIs on one SR, and a fourth anchor UUID appeared that didn't exist in the first sweep. Newly created VHDs keep landing in the affected set. So "stop it happening again" is the urgent half of the two-part fix, at least in my case. The bogus targets cluster onto a tiny anchor set, and the anchors point at each other: Count Anchor 97 937c3945 (→ a893fdb4) 50 a893fdb4 (→ ea150883) 37 ea150883 7 806f7f42 (→ itself, new since Jul 9) That looks less like corrupted lineage and more like the field being filled from an incorrect/uninitialised source. On-disk VHDs are completely healthy. vhd-util check says valid, parent locators are consistent, GC reports no work. The two VDIs the DB calls parent/child are, on disk, siblings under a common parent. The corruption is purely in the XAPI database — which is good news for recoverability. The VDI_IN_USE is not a real lock. current-operations is empty, xe task-list is empty, no tapdisk holds it. VM.start fails because it's walking a snapshot relationship that doesn't exist on disk. Reproduces from xe on the pool master with XO entirely out of the path — which is why I filed against xcp-ng/xcp rather than the XO tracker. Versions: XCP-ng 8.3.0, xapi 26.1.11 (xapi-core-26.1.11-1.2), sm-3.2.12-17.9, sm-fairlock-3.2.12-17.9, blktap 3.55.5-9.1, build 20260618. I have not attempted to bulk-clear the fields — on-disk data is intact and I'd rather not do a mass write against the XAPI DB on a live SR without guidance. Backing store snapshotted as a safety net. Happy to run whatever diagnostics would help. And +1 to the hand-grenade feeling — the affected set growing on its own is the part that worries me. Has this issue been validated on a storage server built around Debian 13, LVM and ext4 or just TrueNAS when connected to XCP-ng version 8.3.0. As part of the XAPI DB corruption. Can anyone answer this please or give a clue?

I converted the topic to a question, then marked it solved. Thanks!

@simonp , thank you very much and all of your team ! ! ! Keep up the outstanding work. Regards, Marc

Just FYI, we had some issues with some Debian VMs for instance, with old kernel where the VM would suddenly take 100% CPU and would we completely frozen and unresponsive. It was in fact Debian enabling the suspend, the guest would suspend and trigger a bug in xen PV driver in the guest kernel which would never be able to wake up anymore. Newer kernel don't have this issue and are able to wake up. I'm quoting Debian here but it might very well happen on other distro

Hi @dvdwx, RBAC is available only at the REST API level, not through the XO6 UI. UI compatibility with RBAC is currently under development. For the topology, this is something that has been here for a long time, so I may be wrong since I don't have the full history. However, if I look at the code, creating the topology selector requires knowing how many CPUs are available in the pool. Since a self-service user doesn't have visibility into the pool, they can't access this kind of information.

Also a question for @Team-XAPI-Network

That it's stayed quiet since you throttled Velero is a good sign, and it lines up with the concurrency theory rather than anything about the specific volumes. Bumping dom0 RAM makes sense too, since linstor-satellite spiking to roughly 8,700 log lines around the panic suggests dom0 was under real pressure right then. If it does come back, a xen-bugtool --yestoall bundle from the host that panicked, plus the Loki window you already have, would give @Team-Storage something concrete to line up against the DRBD side. I'm not sure whether the real fix sits in Velero's pacing or in how LINSTOR handles concurrent create/delete, but the reproduction you've narrowed down is genuinely useful. Fingers crossed it stays boring from here.

@christopher-petzel Thanks!

Hi @acebmxer, thanks for reporting, we identified this bug internally already, we're going to fix it once root cause is found.

Hi Everyone, If I may advertise what I did you have a dedicated thread about my project, this is an easy to setup XCP-ng and XO from the source solution. Sorry sharing the link to the topic as is couldn't find better way to do that : XCP-ng HL — an ISO for home labs, deploy any XOA image from XO Lite directly Essentially you deploy XCP-ng ISO and then in XO Lite deploy XOA section you can deploy your prebuilt or XOA VM directly. Hope that helps Home labers to get in to XCP-ng easily. Same here this is still work in progress, also I'm personally already using this version in my lab. Any feedback is welcome ! With regards.

Ping @Team-Storage

@rvreugde I believe this is already being reviewed internally.