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.

I think that blocked start is actually on purpose rather than something gone wrong: XO guards a continuous-replication target, so you can't accidentally boot the replica and have it drift from the source while the job keeps running.
The documented way to bring one up is the failover process (https://docs.xen-orchestra.com/xo5/incremental_replication#failover-process), and for a real cutover, that's just starting the replica on the destination side; there's also a tip there about making a copy first if you want to start it without breaking the CR job on the source.
So, for your pool-to-pool move, I don't think you'd need to recreate the VMs and reattach disks; the failover flow is meant for pretty much exactly this.

I'd test the whole cycle on your one VM before committing the other 30.

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/

Bit of a necropost on your necropost, but this got easier in XO 6.5.
The REST API now accepts a txChecksumming parameter when you create a VIF (PR #9793, https://github.com/vatesfr/xen-orchestra/pull/9793), and it maps straight onto the ethtool-tx / other_config value you were setting by hand.
So, for new interfaces, you can do it through /rest/v0 now instead of the XAPI script. I think it's on the create path rather than existing VIFs, though, so for the firewalls already running your script or the gear icon is probably still the way, and I haven't tested it against a live VIF myself. Either way, it's nice to have it native in the API now.

All-Ki opened this pull request in vatesfr/xen-orchestra

closed feat(rest-api): add support for txChecksumming and rateLimitting on V… #9793

This is a tricky one, and I'm a bit out of my depth on the XOSTOR internals, but the pattern you describe (XO losing the pool for 30 to 60 seconds while SSH and ping to the hosts stay perfectly fine) reads more like XAPI stalling on a storage call during the LINSTOR coordination than a real network drop.
One detail caught my eye: you mention XOSTOR is on the 10Gb storage network only. The XOSTOR docs actually recommend the satellites stay on the XAPI management interface and call a dedicated network for them "not recommended" for pool robustness (https://docs.xcp-ng.org/xostor/), which feels counterintuitive with a fast 10Gb link sitting right there, so I may well be misreading your setup.
If you're able to grab /var/log/SMlog and /var/log/xensource.log on the master host during one of the disconnect windows, that should show whether XAPI is timing out waiting on a storage operation. Nobody's chimed in yet, and this is pretty XOSTOR-specific, so it might be worth a mention to @Team-Storage; they'll know far more than I do about whether the satellite-network config is what's triggering it.

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.

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

@tjkreidl My pleasure.

I saw you'd started converting Part 1 to Word for editing. You can skip the other two if you want. I went ahead and did all three.

I pulled the originals from the Wayback Machine captures of the old mycugc.org posts (the archive still had your screenshots and the data tables intact), converted them to Markdown, and opened a PR on your repo:

https://github.com/tobiaskreidl/Citrix-Tobias-Kreidl-Collection/pull/1

It adds one .md per article alongside your existing PDFs, with the images pulled out into a folder and the GPU scheduler and cache-latency tables kept as real tables. The point is they render inline on GitHub now, so no more downloading a file just to read it. Nothing of yours is touched, and you stay the owner: review and merge, or tell me what to move around. I made a few calls on file names and layout that are easy to change if you'd rather have them another way.

If it lands cleanly and you're up for it, I'd be glad to talk to the docs team about whether any of it could also live on docs.xcp-ng.org, linked back to you with full credit. No rush on that, and entirely your call.

gounthar opened this pull request in tobiaskreidl/Citrix-Tobias-Kreidl-Collection

open Add Markdown versions of the three articles (render inline on GitHub) #1

Thanks for the clarification, @dsmteam !

Hi Aleksander,
I noticed you were on tid 11869 back in February, where @fatek shared his working setup on a Tesla P4 with the NVIDIA-GRID-XenServer-8 driver, and @tjkreidl ran through the cards that have been reported to work (Tesla M6/M10/M60, P4/P6/P40/P100, V100, T4, A2/A10/A16/A40, RTX A5000/A6000/6000/8000). You closed that thread with "I will try to virtualize GPU to Windows VMs." I'm curious what happened: did you give it a try and hit something specific, or is this a fresh use case where the constraints are different?

The reason I'm asking rather than starting from scratch: fatek was pretty clear that the path is YMMV (XenServer is the supported hypervisor for those drivers, XCP-ng isn't officially), and the XCP-ng vGPU docs confirm it. So if you tried and hit a wall, that's the conversation worth having here. If you tried and it worked but you're now scaling to more Windows VMs and want to know if the same setup holds at 4+, that's a different conversation. On the supported-on-paper side, the same docs page says AMD MxGPU is "trivial using industry standard" if AMD hardware is on the table.

I don't have hands-on with any of this myself, but it'd help to know which problem you're trying to solve now versus February.

Thanks!

If the lower retention value gets things stable, that probably confirms Pilow's hypothesis. If it doesn't help, that's the signal that something heavier is going on, and a @Team-XO-Backend ping would make sense. Would you mind dropping the result back here either way? Helps the next person hitting the same wall.

The sr.scan-driven SMlog growth angle that gumbo2k surfaced is a real lead; there's some context in the storage-related log files reference, but the docs don't go as far as "here's how to throttle it safely on a pool where the underlying disks should spin down."

Soft ping to @Team-Storage and @Team-Hypervisor-Kernel: could one of you weigh in on whether other-config:auto-scan=false on the SR is the supported way to reduce scan pressure, or if there's a better lever? I don't want to send anyone down a path that breaks an SR. Apologies if this has already been answered somewhere I haven't seen.