Bug 2174906

Summary: Stop mutating VMI to set memory requests when only guest memory is being set
Product: Container Native Virtualization (CNV) Reporter: Itamar Holder <iholder>
Component: VirtualizationAssignee: Itamar Holder <iholder>
Status: CLOSED NOTABUG QA Contact: Kedar Bidarkar <kbidarka>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: futureCC: acardace
Target Milestone: ---   
Target Release: 4.14.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-31 12:20:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Itamar Holder 2023-03-02 15:33:23 UTC
Description of problem:
VMIs provide two ways of setting memory.

`vmi.spec.domain.memory.guest`: sets the guest memory, which is the amount of memory the guest can "see", or is aware of.
`vmi.spec.domain.resources.requests[memory]`: sets the amount of memory allocated to the virt-launcher pod. This amount generally consists of guest memory + virt infra overhead (I'm not mentioning over-commitment here for simplicity).

Either guest memory or memory request (or both) must be set. If both aren't set, the vmi creation / update would be rejected by the vmi validation webhooks.

Currently, `vmi.spec.domain.resources.requests[memory]` is always being populated by vmi-mutator, even if not being set by the user. If it's not being set by the user, that means that guest memory is set, then it's being copied to the guest memory field.

The current behavior is problematic. The VMI should reflect the declarative desires of the user. If the user asked some amount of guest memory, but didn't specify any memory requests, then it means that he doesn't care about it, therefore it shouldn't be reflected at the VMI level. This is beneficial in two main aspects:
1) The user is less confused - only what he specified is reflected as the desired state.
2) Kubevirt would have the opportunity to provide new optimizations in the future. For example, if we would improve the virt infra overhead calculation (which currently is not accurate), then after an upgrade the virt-launcher pod would be able to update the memory request amount that is not dictated by the VMI.

Version-Release number of selected component (if applicable):
4.12

How reproducible:
100%

Steps to Reproduce:
1. Define a VMI with only `vmi.spec.domain.memory.guest` set
2. See `vmi.spec.domain.resources.requests[memory]` being populated by the same value

Actual results:
`vmi.spec.domain.resources.requests[memory]`, if not explicitly set, is being populated by the same value as `vmi.spec.domain.memory.guest`.

Expected results:
When only `vmi.spec.domain.memory.guest` is being set, `vmi.spec.domain.resources.requests[memory]` should stay empty.

Comment 1 Antonio Cardace 2023-07-31 12:20:03 UTC
@iholder closing this as a result of https://github.com/kubevirt/kubevirt/pull/9333, feel free to reopen if necessary.