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.

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

Glad you got it back up and running.
I'm not certain, but a missing /usr/local/bin/xo-server right after an XOA update usually looks like an update that got interrupted or only half-applied, so the service ends up pointing at a binary that never got laid down.
I think the gentler recovery before rebuilding would have been re-running the updater from the CLI; there's a writeup here: https://docs.xen-orchestra.com/xo5/updater#from-the-cli, which often repairs a broken update in place.
The vm-destroy refusal is expected by the way: XOA sets blocked_operations as a safety net so you can't accidentally destroy your own orchestrator, so that flag has to be cleared first. I could easily be wrong on the exact trigger, though, and if it ever happens again on a fresh update, @Team-XO-Backend would be the ones who could tell whether a specific update is implicated.

Thanks a lot. I voted for it.

This is a really nice bit of work, thanks for building it and writing it up.
I'm not deep enough in xo-server plugin internals to give you useful feedback on the implementation, but the tag-driven approach to CPU weight and IO priority is clever; XO exposes those knobs manually in the VM advanced view, so automating them off tags is a neat layer on top.
The one-ACL-per-VM limitation you mention is interesting; I think that's a genuine gap rather than something you're missing, though I could be wrong.
If multiple ACL assignments per VM would help others too, it might be worth a short entry on https://feedback.vates.tech so the XO folks can see the demand, and @Team-XO-Backend might find the plugin itself interesting.

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.

I'm not familiar with the Rocky 10 kernel internals, but a spinlock storm on a vCPU during boot often comes from how the guest kernel handles its paravirtual clock/timer with the host, rather than anything Rocky-specific.
Could you share your XCP-ng version, and whether an older RL10 kernel (or an RL9 one) boots normally on the same VM? That would tell us if it's genuinely the latest kernel that regressed.
If it only happens on that kernel and it's hard to test elsewhere, a mention to @Team-Hypervisor-Kernel might help, since they can check whether it reproduces on their side.

From what I can tell, the image-format key showed up alongside the QCOW2 work in 8.3, and vdi_type is the older one.
The QCOW2 FAQ at https://docs.xcp-ng.org/storage/qcow2_faq#how-to-create-a-qcow2-vdi is the only place I've found that even mentions image-format, though it's about creating a VDI rather than detecting the format of one that already exists. I honestly don't know whether the two keys are guaranteed to stay in sync or just happen to agree, so your idea of reading vdi_type first and falling back to image-format sounds like the safest bet to me, but I wouldn't trust my own guess here.
The point about ISO VDIs having no format indicator is a good one, too. It might be worth a mention to @Team-Storage, since they'd know whether image-format is the canonical key going forward and whether vdi_type is kept only for compatibility.

Nice detective work with iperf.
I think that single-stream-versus-parallel result points at the link rather than XOA, and it matches what @Pilow saw (same CR speed on a much fatter 10 Gb path).
On your multi-stream question: as far as I understand it, the transfer is a single stream per disk, which is exactly why a per-stream cap on your circuit hurts so much, though I'm honestly not certain of the internals.
The one lever I'd try is NBD with multiple connections per VDI, which you can switch on under Advanced settings (https://docs.xen-orchestra.com/xo5/incremental_backups#nbd-enabled-backups); in principle, that opens several connections for the same disk, so it might get you past a single-stream limit, though I can't promise it beats your ISP's per-stream shaping.
For a definitive answer on whether the data mover can parallelise per disk, it's probably one for @Team-XO-Backend. Either way, glad it's narrowed down to the link.

I think the Guest Tools status in XO is only ever about the XCP-ng/Xen guest tools, not VMware's, so right after a VMware import, it should read "not installed" until you install the XCP-ng ones (the docs describe the field here: https://docs.xen-orchestra.com/xo5/manage_infrastructure#guest-tools-status ).
So you're right that showing "the tools are installed" on a freshly-imported VM with nothing installed sounds wrong, not just confusing.
I'm not sure what XO keys off to decide that, so I could be missing something. If you see it on every imported VM, or can say whether the source VMware VMs had VMware tools or open-vm-tools on them, that would help pin it down, and it might be worth a mention to @Team-XO-Backend to check whether it reproduces on their side.

Pilow's probably right that you're hitting the tapdisk / SMAPIv1 path rather than the network, since you're both landing at roughly the same speed despite very different link capacity.
One thing worth trying before assuming it's a hard ceiling: turning on NBD for the transfer, which uses the NBD protocol instead of the VHD handler XAPI generates and generally shows better throughput with less load on the Dom0 (https://docs.xen-orchestra.com/xo5/incremental_backups#nbd-enabled-backups).
I haven't benchmarked NBD against CR specifically, so I can't promise how much it'll move the needle, but it's a low-risk toggle and seems like the obvious first lever. If it's still capped after that, it might be worth a mention to @Team-Storage, since the tapdisk/SMAPIv1 transfer path is really their side and they'll have a far better read than me on where the current limits sit.