cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <>
Subject Re: KVM memory overprovision breaking me
Date Tue, 28 Jan 2014 06:21:07 GMT
I should add that I wouldn't expect scaling to work as a combination
of a cluster setting and a service offering, I'd expect it to be
handled entirely by service offerings. The former just becomes
confusing... I define my service offerings with a certain level of
resources, and then that's divided by my overprovisioning factor,
whatever that was... and suddenly my customers don't know what they're
actually getting because it's all misrepresented in the offerings.

<memory unit='KiB’>4GB</memory>
<currentMemory unit='KiB’>2GB</currentMemory>

What this actually does is simply sets the amount of memory that the
VM can use to 2GB (unless they 'rmmod virtio-balloon' within the
guest, then they can use it all). I don't see any place that
dynamically adjusts the currentMemory value to account for memory
pressure inside the guest, and I seem to be able to run myself out of
memory and invoke the OOM killer within the guest without it
auto-increasing my currentMemory. So at least for KVM this effectively
is just a 2GB service offering, with no overprovision/overcommit, or
even scaling occurring.

I'd prefer we got rid of the currentMemory setting as it stands in
relation to overprovisioning on KVM. If I set overprovisioning to
1.5x, let me allocate/run vms up to 1.5x the host memory and kernel
samepage merging can do its thing, don't scale the numbers down to
fit. There is no overprovision that way. A 'currentMemory' setting
only makes sense if you want to change/increase service offering
without reboot. In the given example you'd have a 2GB service offering
and be able to upgrade to a 4GB offering without reboot (always
getting exactly what the service offering states). Again, though, it's
not that great because it can be easily bypassed by the guest.

On Mon, Jan 27, 2014 at 10:53 PM, Marcus Sorensen <> wrote:
> Yeah, that's not overprovisioning, though. That's scaling. The way
> it's implemented now is just ... provisioning. It allocates exactly
> what's available at the host.
> Also, the vm in your example can't go to 4GB. There is nothing that
> changes it's 'currentMemory' setting. Without a scaling feature it's
> simply always stuck at 2GB.
> On Mon, Jan 27, 2014 at 10:32 PM, Harikrishna Patnala
> <> wrote:
>> Hi,
>> I think the way it was done is to guarantee minimum memory to that VM and upon demand
it can get upto the memory defined in service offering.
>> Say a vm with service offering 4Gb is deployed with overprovisioing factor 2, we
guarantee that vm should get minimum of 2GB (4GB/2) and if that VM is overloaded then it can
get memory unto max 4GB.
>> This is what it is showing vm definition
>>>>> <memory unit='KiB’>4GB</memory>
>>>>>  <currentMemory unit='KiB’>2GB</currentMemory>
>> "memory unit” is what it can get maximum.
>> -Harikrishna
>> On 28-Jan-2014, at 7:46 am, Marcus Sorensen <> wrote:
>>> Its an easy fix on the KVM side, just waiting to hear any objections.
>>> On Jan 27, 2014 6:11 PM, "Nux!" <> wrote:
>>>> On 28.01.2014 00:49, Marcus Sorensen wrote:
>>>>> So... I tried to use memory overcommit on KVM this week, and it blew
>>>>> up in my face. Apparently it's configured such that if I have a
>>>>> Service Offering of 4G, and I set memory overprovisioning to 2:1, the
>>>>> guest only actually gets configured with 2G. That's not how
>>>>> overprovisioning is supposed to work, IMO.
>>>>> Here's a vm definition with a 3:1 mem overprovision setting, which
>>>>> ensures that system vms don't work:
>>>>>  <memory unit='KiB'>262144</memory>
>>>>>  <currentMemory unit='KiB'>87040</currentMemory>
>>>>> Note currentMemory needs to be manually tuned if I ever want the vm to
>>>>> use/see more. This is more for live scaling (which is also broken
>>>>> because the guest could just rmmod virtio-balloon and see everything).
>>>>> I'd like to just rip out the code that is setting ballooning feature
>>>>> based on overprovisioning factor, but perhaps there was a reason this
>>>>> was done. From my point of view, if I give someone a service offering
>>>>> that says 4G, it should provide 4G, and if I can do memory
>>>>> deduplication on the backend to overprovision that's up to me to do.
>>>>> Overprovisioning should not be a divider on all service offerings.
>>>> Wow! I also thought, heck, KSM & thin qcows for the win! If
>>>> overprovisioning really "works" as you described then it can't possibly be
>>>> used for any commercial offering ...
>>>> This needs to get fixed.. Too late to see this in 4.3?
>>>> --
>>>> Sent from the Delta quadrant using Borg technology!
>>>> Nux!

View raw message