@poddingue Thanks — that's a useful correction and two useful references.
On the narrower claim: you're right, and I'll take the correction. What I tested is Windows Server 2022, Citrix tools 9.4.0, under PoD pressure, with no migration involved. "Citrix tools do not reclaim" overstates it. The supported statement is: under PoD pressure on a Windows guest, the Citrix 9.4.0 balloon driver did not return pages fast enough to prevent domain destruction, where
the XCP-ng 9.1.200.0 driver did. One OS, one workload shape, one version of each toolset.
I've read topic/11955 properly and I think it points away from a shared cause rather than towards one, though it's a fair thing to have raised:
topic/11955
Mine
Guest
Linux (Debian 12/13)
Windows Server 2022
Agent
Rust xen-guest-agent
Citrix XenServer VM Tools 9.4.0
Trigger
live migration / resume
none — idle, and under allocation
Balloon at idle
correct before migration
correct throughout, memory-actual tracks memory-target
Failure
stuck at dynamic-min, undersized
domain destroyed by domain_crash
Fixed by
reverting to Citrix utilities
replacing Citrix with XCP-ng tools
The squeezed log in that thread is explicit — "domid 53 just started a guest agent (but has no balloon driver)" — so the driver was absent after resume. In my case the driver is present and ballooning correctly at idle on both arms; the divergence only appears when the guest touches a page beyond what's backed. Different mechanism, and the direction of the fix is opposite.
Worth saying that thread also makes the general point better than my post did: whether ballooning works is guest-agent-specific and version-specific in both directions, and neither toolset is categorically the safe one. That's a stronger reason to warn on the memory configuration than anything about a particular driver, since the configuration is what makes any reclaim failure fatal rather than merely untidy.
On the PoD half being known — thanks for topic/10179 and the Xen Project ballooning article. I should have led with "PoD exhaustion under a wide static/dynamic gap is documented; what I think is new is the guest tools variable and the reporting gap." Closing the gap is the right advice and it is what I've done: the template now ships all four values coherent, and the range is only used
where the XCP-ng tools are installed.
On the XO asks — filing both, and I'll link the issues back here:
Warn (or surface all four values) when a clone's memory configuration leaves static-max materially above dynamic-max. Note that the creation form writes dynamic-max only — dynamic-min, static-max and static-min all come from the template, so an operator setting one number gets three they never saw.
Surface domain_crash in XO. With on_crash=Start the domain is back before anyone notices, and the only trace is xl dmesg on the host.
Agreed they stand on their own regardless of where the tools question lands — arguably more so given how differently these two threads' guest agents behaved.
On XO 6 — appreciated, and I'd rather have "I don't know" than a guess. I'll test it myself when I next rebuild and report back either way.
Happy to run further tests if useful. Two that would sharpen this and that I have the rig for:
Same Windows test with Citrix 8.4 rather than 9.4.0, since 8.4 is the version that behaved correctly for Linux in topic/11955. If 8.4 holds on Windows under PoD too, the finding narrows to a specific version rather than the toolset.
Whether XCP-ng Windows tools survive live migration with DMC, which is the trigger from that thread and the one thing my test never exercised.
Full watcher log, xl dmesg extracts and the allocation script are still available if anyone wants to reproduce.
