Also just double check you dont have this enabled - Manage Citrix PV drivers via Windows Update in the vm.

Thanks @cocoon, and I owe a correction: when I said in https://xcp-ng.org/forum/post/104865 that 6.4 would make these alerts disappear for good, I overstated it. If I'm reading the code right this time, the XO server sends a ping every 30 seconds stamped with its own clock (https://github.com/vatesfr/xen-orchestra/blob/master/@xen-orchestra/rest-api/src/events/event.class.mts), and the browser compares that stamp with its own clock and shows the banner once the gap passes 40 seconds (https://github.com/vatesfr/xen-orchestra/blob/master/@xen-orchestra/web-core/lib/packages/remote-resource/sse.store.ts). So https://github.com/vatesfr/xen-orchestra/pull/9681 widened the margin from 32 to 40 seconds, but a browser whose clock runs ahead of the XO server by more than about 10 seconds would still see it. That might be why @GregBinSD saw it on the Windows PC and not on the tablet, though that's only a guess on my part. Comparing two different clocks looks fragile to me, but @Team-XO-Frontend will know far better than I do whether there's a reason it's done that way.

@olivierlambert said: Hello @andrija.panic ! I'm aware and I followed your work and announcements It's great! On our side, we rely on our solution since the end of September: https://github.com/vatesfr/xen-orchestra/blob/master/CHANGELOG.md#690-2026-09-30 : "[V2V] Migrations no longer need the VDDK library". We couldn't wait much more and we had to act very fast to remove this dependency. Hi @olivierlambert, thanks for the insight on vectura! Completely understand the need to move fast and gain full vertical integration over the V2V pipeline—it’s a great move for standard migrations. My suggestion to consider a dual-path approach with an OpenVDDK fallback is less about day-to-day operations and more about strategic, ecosystem-level insurance. If we look at how the Xen Project / Xen Foundation handles governance, it provides a perfect architectural blueprint for this problem: Shared Governance vs. Vendor Control: For OpenVDDK to be a reliable fallback against Broadcom's moving goalposts, it ultimately needs a single, unified organizational structure (similar to a Linux Foundation sub-project). If Vates, Red Hat, and the CloudStack/Proxmox communities pool resources into a shared, neutrally governed utility, the burden of reverse-engineering VMware's disk-format shifts is distributed across the entire industry. Isolating the Core Stack: Just like XCP-ng handles alternative storage plugins or drivers, OpenVDDK wouldn't need to be baked into your core engine. It could live as a completely decoupled, optional legacy transport layer. If vectura hits an unforeseen edge case, a specific CBT lock, or an old ESXi topology (like the legacy versions dropped in 6.9.0), the system has an automated valve to fall back on. Focusing R&D Resources: By helping steer a shared industry standard for the low-level data extraction layer, Vates secures a massive legal and engineering buffer against VMware licensing and structural changes, allowing your internal teams to focus 100% of their energy on making Xen Orchestra the best frontend destination. It prevents Xen Orchestra from ever being caught by surprise, while still keeping your in-house binary as the primary choice.

Thanks @jr-m4, reporting the small ones is useful too. From what I can see in the code, the VM view of the restore page has that refresh button and the Metadata view only has a link back, so I think your screenshots show a real gap and not a glitch on your side. I honestly don't know whether XO 5 still takes this kind of small UI fix now that most of the work goes into XO 6, so I'll leave that to @Team-XO-Frontend to decide.

@zorro I tried to reproduce this on a small lab host with plain xe commands on XCP-ng 8.3, not with XO and Veeam themselves. I think your read is right: both tools end up on the same CBT chain. When a newer snapshot sitting between Veeam's reference and the live disk has had its data purged and is then deleted, the changed-block query from the older snapshot fails with exactly your SR_BACKEND_FAILURE_460 ... Source and target VDI are unrelated, and if I read XO's code right, that purge-then-delete is what the "Purge snapshot data" option does on each run. When that middle snapshot is a normal one, deleting it doesn't break anything in my test. So turning purge off might well avoid it (I think XO then keeps a full snapshot on the host instead), but please treat that as a lead rather than an answer. @Team-Storage will know whether that's expected; until then @acebmxer's one-tool-per-VM advice is the safe one.