Description of problem: When the ballooning is disabled we have no memory data on the guest. Ovirt GA isn't part of RHCOS/EL8 (and future) OSes. In the VDSM code when we have no ballooning available we fallback to OGA which doesn't exist in those. Version-Release number of selected component (if applicable): Any VDSM with OS that doesn't support OGA. How reproducible: 100% Steps to Reproduce: 1. Create a VM without OGA (el8). 2. Disable ballooning on the VM. 3. Run the VM. 4. Check the VM memory. Actual results: Memory is always on 0%, no stats on memory. Expected results: Having Memory provided from GA to VDSM and reported back to the engine. Additional info: https://github.com/oVirt/vdsm/blob/master/lib/vdsm/virt/vmstats.py#L436-L440
Ballooning device is used for memory stats gathering of the guest when qemu-guest-agent is in use. There is no planning to change it. We should enable the ballooning device on high performance profile, currently we disable it. Users who want only the memory stats gathering without further ballooning functions should disable it on cluster level, like the way it's recommended to do so for KSM with high performance VMs.
(In reply to Liran Rotenberg from comment #1) > We should enable the ballooning device on high performance profile, > currently we disable it. This can happen regardless of the VM profile, right? Let's say I disable ballooning for a server VM - it would lead to the same issue. > Users who want only the memory stats gathering without further ballooning > functions should disable it on cluster level, like the way it's recommended > to do so for KSM with high performance VMs. Yes, that can be used as a workaround when ballooning/ksm can be disabled for all VMs in the cluster. Would you agree that it becomes more of an RFE to change what happens when disabling (or not-enabling) ballooning on a VM so it would define the balloon device but won't trigger balloon inflation/deflation?
(In reply to Arik from comment #2) > (In reply to Liran Rotenberg from comment #1) > > We should enable the ballooning device on high performance profile, > > currently we disable it. > > This can happen regardless of the VM profile, right? > Let's say I disable ballooning for a server VM - it would lead to the same > issue. Yes. > > > Users who want only the memory stats gathering without further ballooning > > functions should disable it on cluster level, like the way it's recommended > > to do so for KSM with high performance VMs. > > Yes, that can be used as a workaround when ballooning/ksm can be disabled > for all VMs in the cluster. > > Would you agree that it becomes more of an RFE to change what happens when > disabling (or not-enabling) ballooning on a VM so it would define the > balloon device but won't trigger balloon inflation/deflation? I will need to look into it further. But we should check it and for high performance VMs (or even have another checkbox on the VM for it). This direction in general is an RFE from my point of view.
I think it would be fine to always include ballooning device and use different means to communicate to mom that ballooning should be skipped for this VM. Any extra property would work I guess, probably even just setting guaranteed mem to current. In that case it really just means to enable balloon unconditionally...
*** This bug has been marked as a duplicate of bug 1917718 ***