@MajorP93: Thanks for expressing yourself regarding that, and I'll be transparent about the thinking behind it.

Filing those on GitHub isn't me asking anyone to stop using the forum, quite the opposite in fact.
The forum is where real conversations happen, and that's valuable in a way a GitHub issue never quite is. But forum threads scroll, get buried, and developers can't easily maintain a stable backlog out of them. GitHub gives the team a place where things don't disappear or get buried.

Think of it as belt and suspenders (which I need now that I'm getting old ). The discussion lives here, the tracking lives there. My goal as community manager is to be the relay between the two, so you don't have to worry about it.
File things here, talk about them here, and I'll make sure what matters makes it into the right repo.
Or at least, that's the plan. Mine.

From what I understand, when XCP-ng reverts to a snapshot it restores the full VM state from that point (metadata included, not just the disk contents) so the creation date field would get rolled back along with everything else; that might be why it now matches the snapshot timestamp rather than
the original. I might be wrong about the internals though.

It's a bit confusing if you were relying on that field to track VM history, and I don't think https://docs.xen-orchestra.com/xo5/manage_infrastructure#snapshot-management covers this explicitly.
Might be worth a mention to @Team-Documentation-Knowledge-Management; it's the kind of thing that catches people off guard because nothing warns you upfront that metadata rolls back too.
My $0.02.

Reviving this one because it never really got a clean ending. The fix for the Body Timeout Error on full backups went into xapi-project/xen-api#6786 and shipped with the March 2026 8.3 maintenance updates.

@nikade, back in March, you mentioned still hitting it on both Linux and Windows VMs even after updating. Is that still the case for you on current versions? And anyone else who landed here: are you still seeing it, or did the update sort it out?

Mostly trying to work out whether there's still something to chase or whether we can call this resolved. I'm not deep enough in the backup internals to say for sure, so your real-world results would tell us far more than anything I could guess. Thanks!

last-genius opened this pull request in xapi-project/xen-api

closed stream_vdi: Only process allocated clusters for VHD and QCOW on XVA export #6786

Thanks for following up and opening the issue; that's exactly the kind of report the team needs. I've subscribed to it, so I'll see when it moves. The second-run failure pattern is a useful clue; hopefully they can reproduce it from there.

Following up since the situation changed: QCOW2 went GA in XO 6.5 (released 2026-05-28), so the old ~2TB VHD ceiling is gone.
A disk at exactly 2TB, and well beyond it, is fine now without shrinking to 1.99TB first. When acebmxer and john.c replied, it was still a release candidate; it's the stable story now. I haven't migrated a disk quite that size myself, so I won't promise it's totally painless, but the format limit that was blocking you isn't there anymore.
The release blog has the details if you want to read up before the migration: https://xen-orchestra.com/blog/xen-orchestra-6-5/

This is great to see, thank you for taking the time to rescue this; and thanks to @john.c for the recovery work and to @tjkreidl for writing it in the first place.
I went looking, and there is a small XCP-ng-specific piece on this in the official docs under NUMA affinity (https://docs.xcp-ng.org/compute#numa-affinity), but it's nothing like the depth of the Tale of Two Servers series, so having the originals archived is genuinely useful.
I won't pretend to judge how much of the 2019 BIOS and GPU-scheduler guidance still maps cleanly onto current hardware and XCP-ng versions; others here will know where it's aged and where it hasn't.
I'll make sure this is on our radar on the docs side, because it keeps coming up. Really appreciate you keeping this from disappearing.

The Kubernetes CSI driver for Xen Orchestra just hit v0.4.0, and we want it on more real clusters before it reaches a stable release candidate. If you run Kubernetes on XCP-ng VMs, this is a good time to give it a proper workout.

What's new in v0.4.0:

• Local-storage support
• Automatic pool-discovery fallback
• Kubernetes metadata now lives in Xen Orchestra VDI tags instead of the deprecated other_config. That change also drops the old requirement for Xen Orchestra 6.4 or newer, so the driver runs on more deployments now.

️ Read this before you upgrade. v0.4.0 is a breaking change. The Kubernetes metadata moved from other_config to VDI tags, so you must migrate before upgrading from v0.3.0. Do not upgrade in place: follow the v0.3.0 to v0.4.0 migration guide in the release notes, then move to v0.4.0.

What helps us most is hearing how it behaves on your own setup: what works, what breaks, which storage backend you use, and which flavour of Kubernetes you run (k3s, full k8s, or something else). Edge cases on real clusters are the ones we don't see in our own testing.

Where to report: start right here in this thread. It keeps everything visible to the community and lets others on the same setup jump in. If something turns out to be a reproducible bug, we'll move it to a GitHub issue on the repo so the team can track it to a fix.

Release notes and migration guide: https://github.com/vatesfr/xenorchestra-csi-driver/releases/tag/v0.4.0

Good news, this already shipped in XO 6.5.0 (released 2026-05-28), PR #9835.
If your XOA is on the latest channel, you've got PATCH /vms/{id} now; on the stable channel, it should land when 6.5.0 gets promoted (stable is on 6.4.1 at the moment). name_description looks like the field you'd write that "what's running here" summary to for your n8n flow, though I haven't tried the new endpoint myself yet. Let us know how it goes.

Good news, I think this one's finally sorted: the cleanVm: incorrect backup size in metadata warning was fixed in XO 6.4.0 (released end of April) via PR #9637, which makes incremental remote backups record the actual VHD size instead of the slightly-off metadata value.
If you're on 6.4.0 or later, it should be gone, so worth confirming your version and upgrading if you're behind. @manilx, you were waiting on this one.

Take it with a grain of salt, but I think bonds are usually managed as a whole rather than edited port by port in the UI. As far as I can tell, the supported route is from the network section in Xen Orchestra (the bonding part of the infrastructure docs is here: https://docs.xen-orchestra.com/xo5/manage_infrastructure#network-bonding), and on the CLI side, the bond commands are documented at https://docs.xcp-ng.org/appendix/cli_reference#bond-create (there's a matching bond-destroy command alongside it).
My honest guess is you may end up destroying and recreating the bond with the four ports you want to keep, since I'm not sure removing a single member in place is exposed anywhere, but I could easily be wrong.
If there's a cleaner way that avoids the recreate, someone will let us know.

From what I can tell, the Netbox plugin in XO syncs VMs, interfaces and IPs, but it doesn't populate Netbox's separate Virtual Disks model yet, which is why you get the total disk space but an empty Virtual Disks tab.
I don't think it's a permissions thing on your side, it looks more like a gap in what the plugin syncs today.
There's already an open issue for disk-size sync (https://github.com/vatesfr/xen-orchestra/issues/7643), plus a few other Netbox requests in the tracker. If you want the per-disk sync added, the place it actually gets weighed is https://feedback.vates.tech, where the Netbox asks get prioritised together.
It might also be worth a mention to @Team-XO-Backend, since they own the plugin and can say whether the newer Netbox virtual-disk model is on their radar.

ecoutinho created this issue in vatesfr/xen-orchestra

open Netbox plugin: Sync disk size error #7643

@niko thanks, that would help a ton!

The Kubernetes CSI driver for Xen Orchestra just hit v0.4.0, and we want it on more real clusters before it reaches a stable release candidate. If you run Kubernetes on XCP-ng VMs, this is a good time to give it a proper workout.

What's new in v0.4.0:

• Local-storage support
• Automatic pool-discovery fallback
• Kubernetes metadata now lives in Xen Orchestra VDI tags instead of the deprecated other_config. That change also drops the old requirement for Xen Orchestra 6.4 or newer, so the driver runs on more deployments now.

️ Read this before you upgrade. v0.4.0 is a breaking change. The Kubernetes metadata moved from other_config to VDI tags, so you must migrate before upgrading from v0.3.0. Do not upgrade in place: follow the v0.3.0 to v0.4.0 migration guide in the release notes, then move to v0.4.0.

What helps us most is hearing how it behaves on your own setup: what works, what breaks, which storage backend you use, and which flavour of Kubernetes you run (k3s, full k8s, or something else). Edge cases on real clusters are the ones we don't see in our own testing.

Where to report: start right here in this thread. It keeps everything visible to the community and lets others on the same setup jump in. If something turns out to be a reproducible bug, we'll move it to a GitHub issue on the repo so the team can track it to a fix.

Release notes and migration guide: https://github.com/vatesfr/xenorchestra-csi-driver/releases/tag/v0.4.0

Good to hear, thanks a lot for your feedback.

Your setup is different enough that folks here might not have hit this exact thing.
The Failed to parse ACPI DMAR. Disabling VT-d line usually points at the laptop firmware's ACPI tables rather than anything Xen is doing wrong, which would explain why the grub iommu=1 tweaks aren't moving the needle.
You've already cross-posted to the QubesOS forum, which is probably where the people who've wrestled with E15 firmware quirks hang out.
If it helps, the XCP-ng docs have a short note on reading the DMAR/IVRS ACPI tables to debug IOMMU issues at https://docs.xcp-ng.org/troubleshooting/log-files#dmarivrs-acpi-tables.
It's XCP-ng-specific, but the Xen-level idea of dumping and inspecting those tables carries over.

Thanks for coming back to close it out. That's useful to know.
So I was plenty wrong, as it was the XOSTOR licensing backend rather than the repo side I guessed at; those -32000 errors really don't give much away.
For anyone landing here later: sounds like -32000 on XOSTOR creation can come from either end, a licensing/entitlement issue that support sorts, or a host not reaching the package repo, so both are worth checking. @alcoralcor, did support get yours sorted too, or is yours still the repodata / repo-reachability one?
Glad you're unblocked either way.

That leftover NIC is probably a stale PIF that XAPI is still holding, even though the card is physically gone, and the Refresh button re-scans rather than removing it.
The docs have proper "remove a physical NIC" steps that end in forgetting the old PIF with xe pif-forget: https://docs.xcp-ng.org/networking/#remove-a-physical-nic.
For the GPU side, the PCI passthrough flow (hiding the device from dom0, then assigning it) is here: https://docs.xcp-ng.org/compute#detaching-a-pci-device.
If the GPU still won't show up as assignable once the stale PIF is gone, it might be worth a mention to @Team-Hypervisor-Kernel.

Pilow's right that moving a VM to another SR forces one full pass while the CBT bitmap is rebuilt; that part is expected.
But your screenshot actually shows the likely culprit for the all-VMs-fall-back-to-full pattern: you have Purge snapshot data when using CBT enabled, and XO's incremental backup docs flag exactly that combination as a known issue where you can occasionally get unexpected fulls: https://docs.xen-orchestra.com/xo5/incremental_backups#known-issues.
It might be worth running a few jobs with that toggle off to see if the deltas hold. It is a known rough edge on the CBT side, so following the central CBT feedback thread and maybe a nudge to @Team-XO-Backend wouldn't hurt.

AtaxyaNetwork's instinct feels right to me, so I'd start there: XOSTOR has to install its LINSTOR/DRBD packages on each host from the XCP-ng repo, and alcoralcor's repodata failure in audit.log suggests that step is failing.
As far as I know, -32000 back in XO is often just the generic wrapper around a host-side install problem like that.
On a trial, it's worth double-checking each host in the pool can actually reach updates.xcp-ng.org (no proxy or firewall in the way) and that the XOSTOR prerequisites in the docs are met before creating the volume: https://docs.xcp-ng.org/xostor/.
If the hosts can reach the repo but it still fails, this is likely a @Team-Storage issue.
I'm out of my depth on XOSTOR internals, though, so take this as a starting point rather than a diagnosis.

Thanks for the detailed report and the NBD=2 vs NBD=1 correlation, Andrew, that's a genuinely useful clue.
From what I understand, a VDI staying attached to dom0 like this tends to point at the storage side on the XCP-ng host rather than XO's replication logic itself, so it's probably worth a look from @Team-Storage.
To give them something concrete to chase, would you be able to share your SR type/storage backend, plus the SMlog (and kern.log) from around the time a VDI gets left stuck?
With those details, the storage folks would have a much better starting point.
Thanks again for staying on top of it.