@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.

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.

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.

This is a nice bit of community tooling, and thanks for keeping it updated and being upfront about the "use at your own risk" part.
On the naming point a few people raised, I think the distinction folks are drawing is fair: XOA is the Vates-built appliance, and anything you compile yourself is XO from sources.
The official docs cover that path at https://docs.xen-orchestra.com/xo5/installation#from-the-sources, including the note that there is no pro support for that method.
Hope the project keeps going well!

Thanks for the ping and for narrowing it down; that live-migration repro is a really useful signal.
I don't know enough about how the guest tools report IPs back through XAPI to say where the canonicalisation should happen, but it sounds like something @Team-Hypervisor-Kernel might want to look at since the trigger is on the agent side after migration.
If it turns out to be reproducible on another Windows guest version (2022, 2019), that might help narrow it further; no pressure though, you've already done the hard part.

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/