XO 5 VM creation form sets memory-dynamic-max only; the other three memory values come from the template, unseen

[kismetgerald]

Summary

When creating a VM from a template, XO's RAM field writes memory-dynamic-max and nothing else. memory-dynamic-min, memory-static-max and memory-static-min are inherited from the template. The operator enters one number and the VM is created with three values they never saw.

Where the template's static-max is significantly higher than the RAM entered, this produces a wide populate-on-demand gap. If the guest's balloon driver does not reclaim quickly enough, Xen destroys the domain — and with on_crash=Start it restarts immediately, so the guest records only an unclean shutdown.

The crash behaviour is Xen's and I am not reporting it as a bug. The report is that XO creates the configuration without surfacing it.

Reproduction

XO 5, Community Edition from sources. XCP-ng 8.3.0, xapi 26.1.11.

1. Take a template whose memory-static-max is 16 GiB and memory-dynamic-max is 4 GiB.
2. Create a VM from it. Set the RAM field to 8 GiB. Leave the three Advanced memory fields
   empty, which is their default state.
3. On the host, inspect the result:

xe vm-param-list uuid=<new vm> | grep -iE 'memory-(static|dynamic)'

Observed:

memory-static-max   17179869184  (16 GiB)   <- from the template
memory-dynamic-max   8589934592  ( 8 GiB)   <- from the form
memory-dynamic-min   4294967296  ( 4 GiB)   <- from the template
memory-static-min    1073741824  ( 1 GiB)   <- from the template

One of four values came from the operator. The Advanced section that would reveal the other three is collapsed by default, and nothing in the summary panel indicates them.

Why this matters in practice

A VM created this way boots and runs normally at idle — memory-actual tracks memory-target correctly, so nothing looks wrong. The failure only appears when the guest touches memory beyond what is backed, at which point Xen kills the domain:

(XEN) p2m_pod_demand_populate: Dom124 out of PoD memory! (tot=1049115 ents=3145696 dom0)
(XEN) domain_crash called from p2m_pod_demand_populate+0x4e2/0x8c0

In my case six VMs did this on a 12–15 minute cycle for an entire evening. Diagnosis was misattributed to four separate subsystems before the memory configuration was found, because nothing in XO, and nothing in the guest, pointed at memory.

Full write-up, including a controlled two-arm test isolating the guest driver as the other variable: https://xcp-ng.org/forum/topic/12399

Suggested change

Either would have prevented this. The first is the smaller change.

1. Surface all four values where RAM is set. Show the effective dynamic-min, dynamic-max, static-max and static-min the VM will be created with, including the ones inherited from the template. Read-only display would be enough — the problem is that they are invisible, not that they are unset.

2. Warn when static-max materially exceeds dynamic-max. A note at creation time saying the VM will run with populate-on-demand and what that implies, with a link to the relevant documentation.

A related smaller thing: the Advanced memory fields being empty currently means "inherit from the template", which is indistinguishable from "unset" in the UI. A placeholder showing the inherited value would make the distinction visible without changing any behaviour.

Environment

Xen Orchestra: XO 5, Community Edition, from sources
XCP-ng 8.3.0, platform 3.4.0, xapi 26.1.11, build 20260707
Xen 4.17.6-9
Guests: Windows Server 2022 Standard 10.0.20348, UEFI, Secure Boot

I have not tested whether XO 6's creation form behaves differently. If it already surfaces these values, this issue applies to XO 5 only.