mem.overprovisioning not working as expected.

[yashi4engg]

Mem.overprovisiing value set to 5 .

mem.overprovisioning.factor -- set to 5
vm.min.memory.equals.memory.divided.by.mem.overprovisioning.factor - set to true

But still unable to create VMs more then actual Memory on hypervisor.
Even if can create more then that it not reflecting on VM and ..vm dumpxml shows assign memory devided by total assigned/over provisioning ratio.

We want over provisioning to work in a way where if we login to guest should show actual assigned value and we should be able to create VMs with value more than actual available memory similar like VMWare.

Please guide through global setting tuning if any to make it work ...

For example ..My hyp have actual mem ory 126GB ...So when i create a VM with 96GB where overprovisioing set to 10 ...VM shows memory in free-g output only 9GB.

[yashi4engg]

Backend env -
Hypervisor - OEL9
Guests - OEL7
cloudstack version 4.18

[rajujith]

@yashi4engg This looks like a bug to me, CloudStack shouldn't set a lower value for the memory configs in the KVM instead it should use auto ballooning. CC @harikrishna-patnala

[rohityadavcloud]

Need review/testing, was KVM ballooning feature on? cc @DaanHoogland @rajujith

[rajujith]

@rohityadavcloud @DaanHoogland please refer to the same issue #7430

[yashi4engg]

KVM balloning feature on at Host side but concern here is if we use mem.overprovisioing its not showing assigned memory at VM side and its shows only assigned mem/overprovisioing-ratio .

[rajujith]

@yashi4engg the 'memory unit' in the domain definition should not be changed based on the over provisioning ratio but cloudstack does that currently.

[GutoVeronezi]

Hello @yashi4engg,

In the previous conjuncture, when ACS was deploying a VM, it would define a minimum memory|CPU to the VM based on a calculation through the overprovisioning (defined mem|cpu speed / overprovisioning factor); Therefore, it would define a range of memory/CPU, even if it did not use scalable (dynamic) service offerings.

To workaround this situation, configurations vm.min.memory.equals.memory.divided.by.mem.overprovisioning.factor and vm.min.cpu.speed.equals.cpu.speed.divided.by.cpu.overprovisioning.factor were introduced (with PR #4722), to allow operators decide if they want the minimum memory|CPU to be different from the allocated value when the overprovisioning's configurations are different than 1. By default these configurations are true, to keep the initial behavior; however, in your case, you should mark those configurations as false, so the memory|speed allocated to the VM is the actual defined in the offering.

Could you apply the suggestion and make some tests?

Best regards

[yashi4engg]

Yes, But our use case is what ever memory we allocate should be shown in VM using free command but it should allow overprovisioning as well so we can get benefited with Memory balooning. Where user want more memory to be allocated for VM but actual use is very less or most of time VM stay ideal.