Description of problem: Currently when choosing memory amount in the GUI console, the memory is applied to `vmi.spec.domain.resources.requests[memory]`. This field is NOT meant to reflect the amount of memory allocated to the guest, but instead the amount of memory allocated to the virt-launcher pod (which includes virtualization infrastructure overhead in addition to the guest memory). When users set a memory amount for VMs/VMIs, they mean to set `vmi.spec.domain.memory.guest`, which specifies the amount of memory the guest could use. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Define a VM with certain amount of memory 2. See that for this vmi `vmi.spec.domain.resources.requests[memory]` is being set with the specified amount. 3. Actual results: When defining a VMI with a memory amount, `vmi.spec.domain.resources.requests[memory]` field is being set. Expected results: When defining a VMI with a memory amount, `vmi.spec.domain.memory.guest` should be set. `vmi.spec.domain.resources.requests[memory]` should stay empty unless the user had explicitly asked to populate it.
Hey @iholder Currently, our common templates still contain request.memory , I can adjust our editors and wizard to add the user adjustments of memory to memory.guest, but in the final VM/VMI object, the memory will appear in both request.memory and memory.guest - is this the desired result? imho I think our common templates should be updated to the memory.guest?
Hey @mschatzm, Thanks for bringing it into attention. Eventually, VMs/VMIs should *only* have the guest memory field populated, unless the user explicitly populates requests[memory] field on rare cases. So yes, our templates need to be updated so the memory request is not populated by default.
Move the bug to SSP for updating the common templates.
It would be helpful to verify this bug on a cluster with quotas enabled.