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

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.

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.

Good news, or at least, that's my understanding.
This was a known bug and it's fixed in XO 6.4 (released April 29, PR #9681). Upgrading should make those alerts disappear for good. Thanks for the video, it made the report unambiguous.

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.

That GitHub HTML-bundle pain is real, especially when whatever exported the pages dragged in half the surrounding site CSS and sidebar widgets along with the article. You spent the time writing the originals; the file-wrangling shouldn't be what costs you another evening.

If it's useful, I'm up for taking the cleanup off your hands. Concretely:

• pull the HTML you saved from the repo (or a zip / branch you point me at)
• strip out the noise: scripts, sidebars, navigation, anything that isn't the article body and its images
• convert to markdown, one file per article, images kept alongside
• open a PR against tobiaskreidl/Citrix-Tobias-Kreidl-Collection (https://github.com/tobiaskreidl/Citrix-Tobias-Kreidl-Collection) so you stay the owner and only have to review and merge

If the saved bundles are too far gone, I'd fall back to the Citrix URLs @john.c surfaced and pull clean copies via the Wayback Machine. Same end result on your repo.

Separately, and only if that lands cleanly, I'd love to talk to Thomas Moraine and the docs team at Vates about whether parts of this could find a home on docs.xcp-ng.org, linked back to your repo with full credit. The NUMA-affinity page I pointed at earlier is shallow next to what you wrote, and the BIOS / GPU-scheduler material has no current equivalent at all. Whether the 2019 specifics still map cleanly onto current XCP-ng versions and hardware is a separate conversation; even as an archived reference, it's more than what's there today.

No pressure, no obligation. If you'd rather keep iterating on the repo yourself, that's fine too. But if a clean-the-HTML-and-PR-it pass would save you a week of GitHub-tool frustration, I'm genuinely up for it. Just point me at the bundle.

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.

Thanks for taking the time to write this up with before/after numbers. That kind of post is genuinely useful for the next person hitting slow backups.
Pilow's catch looks like the important one to me: I think raising the VM's RAM on its own doesn't help much unless xo-server is also told it can use it, which is the heap-limit tip here: https://docs.xen-orchestra.com/xo5/troubleshooting#memory.
I could be wrong, but the recommended XOA sizing also lives at https://docs.xen-orchestra.com/xo5/xoa#xoa-vm-specifications if you want to sanity-check vCPU/RAM against what's suggested for your backup load.

Good to hear acebmxer confirmed a fresh 6 GB deploy sizes the heap correctly by itself; that matches my (limited) understanding that the manual step mostly matters when you grow the VM later.
Let's wait for the experts to chime in; they will know far more about squeezing the last bit of backup throughput out of XOA.

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.

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.