You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Marcus Sorensen <sh...@gmail.com> on 2014/01/28 01:49:10 UTC
KVM memory overprovision breaking me
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.
Re: KVM memory overprovision breaking me
Posted by Marcus Sorensen <sh...@gmail.com>.
I see that the same approach has been taken for CPU overprovisioning,
but it actually works there, because cpu is allocated in 'shares',
which are abstract and relative to all shares allocated. With memory,
we can't just divide the raw size allocated and call it good. I think
this was an oversight.
On Mon, Jan 27, 2014 at 5:49 PM, Marcus Sorensen <sh...@gmail.com> 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.
Re: KVM memory overprovision breaking me
Posted by Marcus Sorensen <sh...@gmail.com>.
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 <sh...@gmail.com> 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
> <ha...@citrix.com> 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 <sh...@gmail.com> wrote:
>>
>>> Its an easy fix on the KVM side, just waiting to hear any objections.
>>> On Jan 27, 2014 6:11 PM, "Nux!" <nu...@li.nux.ro> 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!
>>>> www.nux.ro
>>>>
>>
Re: KVM memory overprovision breaking me
Posted by Marcus Sorensen <sh...@gmail.com>.
just send an email requesting that it be cherry-picked, with the
reasoning. I don't feel strongly that it's a bug, but if you really
want it in 4.3 it's worth a shot to make your case.
On Tue, Jan 28, 2014 at 10:57 AM, Nux! <nu...@li.nux.ro> wrote:
> On 28.01.2014 17:49, Marcus Sorensen wrote:
>>
>> Commit 1530c162e58abd8e572a89d2a2706de00bd49e26 in branch
>> refs/heads/master from [~mlsorensen]
>> [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1530c16 ]
>>
>> CLOUDSTACK-5968 create vm.memballoon.disable agent parameter
>
>
> How do I lobby for it? :)
>
> Lucian
>
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
Re: KVM memory overprovision breaking me
Posted by Nux! <nu...@li.nux.ro>.
On 28.01.2014 17:49, Marcus Sorensen wrote:
> Commit 1530c162e58abd8e572a89d2a2706de00bd49e26 in branch
> refs/heads/master from [~mlsorensen]
> [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1530c16 ]
>
> CLOUDSTACK-5968 create vm.memballoon.disable agent parameter
How do I lobby for it? :)
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
Re: KVM memory overprovision breaking me
Posted by Marcus Sorensen <sh...@gmail.com>.
Commit 1530c162e58abd8e572a89d2a2706de00bd49e26 in branch
refs/heads/master from [~mlsorensen]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1530c16 ]
CLOUDSTACK-5968 create vm.memballoon.disable agent parameter
This is just a tuneable that you have to explicitly set, otherwise
everything remains as-is. If you'd like you can lobby to cherry-pick
that into 4.3
On Tue, Jan 28, 2014 at 3:15 AM, Nux! <nu...@li.nux.ro> wrote:
> On 28.01.2014 09:56, Bharat Kumar wrote:
>>
>> Hi,
>>
>> The calculations when overcommitting are on a per VM basis. I am not
>> sure if these will be valid when using KSM.
>> IMO KSM is applicable to a set of VMs not a single VM. so how do we
>> keep track of how much free memory is actually available on the host.
>> This was not problem in case of ballooning as we knew upfront about
>> the limits that we want to set on a per VM basis.
>
>
> The problem with ballooning is that it depends in you having exclusive root
> access on the VMs and on running an agent inside the VMs (it doesnt even
> work for all OSes afaik).
> This is a very particular situation and for people who want to sell
> cloudstack to the public it's a no-go.
> I would be very happy if ACS allowed me to set an overprovisioning factor
> and then let me use KSM without having to mess with the VMs. Available
> memory on the hypervisor could be tracked by standard linux utils via the
> agent (`free`?).
>
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
Re: KVM memory overprovision breaking me
Posted by Nux! <nu...@li.nux.ro>.
On 28.01.2014 09:56, Bharat Kumar wrote:
> Hi,
>
> The calculations when overcommitting are on a per VM basis. I am not
> sure if these will be valid when using KSM.
> IMO KSM is applicable to a set of VMs not a single VM. so how do we
> keep track of how much free memory is actually available on the host.
> This was not problem in case of ballooning as we knew upfront about
> the limits that we want to set on a per VM basis.
The problem with ballooning is that it depends in you having exclusive
root access on the VMs and on running an agent inside the VMs (it doesnt
even work for all OSes afaik).
This is a very particular situation and for people who want to sell
cloudstack to the public it's a no-go.
I would be very happy if ACS allowed me to set an overprovisioning
factor and then let me use KSM without having to mess with the VMs.
Available memory on the hypervisor could be tracked by standard linux
utils via the agent (`free`?).
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
Re: KVM memory overprovision breaking me
Posted by Marcus Sorensen <sh...@gmail.com>.
They don't seem to be on a per-vm basis. It seems to be service
offering size divided by cluster overprovision setting.
I do get what is trying to be accomplished, the best is to have both
KSM and balloon. Ideally the balloon settings would all be maxed by
default, and then if KSM is insufficient to handle the overcommit and
the host starts to really run out of memory, then the admin-provided
balloon daemon swoops in and starts reducing individual memory on each
vm to ensure the host system doesn't run itself out. The balloon
daemon would presumably set all vms to their max to start. I assume
the agent sets it to minimum to ensure that there's no OOM condition
if the admin has no balloon daemon.
There are other issues with balloon, though. You lose memory to it
even if you push the setting to max:
http://blog.braastad.org/?p=211
So I think we need a vm.balloon.disable=true for the agent.properties
(which just skips setting it in the xml), and perhaps some clearer
documentation about how the admin needs to provide a balloon daemon so
that the vm can see all of its assigned memory.
On Tue, Jan 28, 2014 at 2:56 AM, Bharat Kumar <bh...@citrix.com> wrote:
> Hi,
>
> The calculations when overcommitting are on a per VM basis. I am not sure if these will be valid when using KSM.
> IMO KSM is applicable to a set of VMs not a single VM. so how do we keep track of how much free memory is actually available on the host.
> This was not problem in case of ballooning as we knew upfront about the limits that we want to set on a per VM basis.
>
> Thanks,
> Bharat.
>
> On 28-Jan-2014, at 3:05 pm, Nux! <nu...@li.nux.ro> wrote:
>
>> On 28.01.2014 06:57, Marcus Sorensen wrote:
>>> Actually, does anyone have objections to adding an agent.properties
>>> tunable to disable balloon? That would allow anyone who wants to
>>> overcommit to do so, without messing with the existing FS, and the
>>> calculations for allocation at least are all accurate. And I won't
>>> have to maintain another local patch.
>>> I just can't give someone a 4G VM and have it only show 2-1G inside,
>>> just like I wouldn't give someone a 1T thin-provisioned disk and only
>>> show them 100G. I know KSM will give me X memory dedup for my
>>> workload, and I'd prefer to straight up over allocate VMs to the
>>> guests based on that. Balloon just doesn't work anyway for most,
>>> only if the customers are internal and agree not to meddle with it. I
>>> think that goes for all hypervisors.
>>
>> +100 on the above! You can count of me for testing.
>>
>> Lucian
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>
Re: KVM memory overprovision breaking me
Posted by Bharat Kumar <bh...@citrix.com>.
Hi,
The calculations when overcommitting are on a per VM basis. I am not sure if these will be valid when using KSM.
IMO KSM is applicable to a set of VMs not a single VM. so how do we keep track of how much free memory is actually available on the host.
This was not problem in case of ballooning as we knew upfront about the limits that we want to set on a per VM basis.
Thanks,
Bharat.
On 28-Jan-2014, at 3:05 pm, Nux! <nu...@li.nux.ro> wrote:
> On 28.01.2014 06:57, Marcus Sorensen wrote:
>> Actually, does anyone have objections to adding an agent.properties
>> tunable to disable balloon? That would allow anyone who wants to
>> overcommit to do so, without messing with the existing FS, and the
>> calculations for allocation at least are all accurate. And I won't
>> have to maintain another local patch.
>> I just can't give someone a 4G VM and have it only show 2-1G inside,
>> just like I wouldn't give someone a 1T thin-provisioned disk and only
>> show them 100G. I know KSM will give me X memory dedup for my
>> workload, and I'd prefer to straight up over allocate VMs to the
>> guests based on that. Balloon just doesn't work anyway for most,
>> only if the customers are internal and agree not to meddle with it. I
>> think that goes for all hypervisors.
>
> +100 on the above! You can count of me for testing.
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
Re: KVM memory overprovision breaking me
Posted by Nux! <nu...@li.nux.ro>.
On 28.01.2014 06:57, Marcus Sorensen wrote:
> Actually, does anyone have objections to adding an agent.properties
> tunable to disable balloon? That would allow anyone who wants to
> overcommit to do so, without messing with the existing FS, and the
> calculations for allocation at least are all accurate. And I won't
> have to maintain another local patch.
>
> I just can't give someone a 4G VM and have it only show 2-1G inside,
> just like I wouldn't give someone a 1T thin-provisioned disk and only
> show them 100G. I know KSM will give me X memory dedup for my
> workload, and I'd prefer to straight up over allocate VMs to the
> guests based on that. Balloon just doesn't work anyway for most,
> only if the customers are internal and agree not to meddle with it. I
> think that goes for all hypervisors.
+100 on the above! You can count of me for testing.
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
Re: KVM memory overprovision breaking me
Posted by Marcus Sorensen <sh...@gmail.com>.
One last comment... since you mention that it doesn't actually work
for KVM without an admin writing or adding a script, maybe it would
make more sense for the agent.properties tunable to *enable* balloon,
basically saying that they have done that scripting portion and want
to enable the balloon for scaling?
On Mon, Jan 27, 2014 at 11:57 PM, Marcus Sorensen <sh...@gmail.com> wrote:
> Actually, does anyone have objections to adding an agent.properties
> tunable to disable balloon? That would allow anyone who wants to
> overcommit to do so, without messing with the existing FS, and the
> calculations for allocation at least are all accurate. And I won't
> have to maintain another local patch.
>
> I just can't give someone a 4G VM and have it only show 2-1G inside,
> just like I wouldn't give someone a 1T thin-provisioned disk and only
> show them 100G. I know KSM will give me X memory dedup for my
> workload, and I'd prefer to straight up over allocate VMs to the
> guests based on that. Balloon just doesn't work anyway for most,
> only if the customers are internal and agree not to meddle with it. I
> think that goes for all hypervisors.
>
> On Mon, Jan 27, 2014 at 11:28 PM, Marcus Sorensen <sh...@gmail.com> wrote:
>> Yeah, I'm a little disappointed that the functional spec doesn't
>> really address memory deduplication, which is the real version of
>> overcommit, IMO. Since it looks like the feature is already fully
>> implemented, I'm not sure I have much of a leg to stand on in trying
>> to change it. I'll just patch it out of our builds. Thanks for the
>> input.
>>
>> On Mon, Jan 27, 2014 at 11:13 PM, Bharat Kumar <bh...@citrix.com> wrote:
>>> Hi Marcus,
>>>
>>> in case of KVM the guest memory is not dynamically adjusted by hypervisor, this is a hypervisor limitation. we have documented this in the FS in prerequisites for KVM.
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CPU+and+RAM+Overcommit
>>>
>>> One way to make this work automatically is to use a script to monitor the memory pressure in the guest VM and adjust the memory using cgroups.
>>> one such script is Memory over commit manager.
>>> more info here http://aglitke.wordpress.com/2011/03/03/automatic-memory-ballooning-with-mom/
>>>
>>> Thanks,
>>> Bharat.
>>>
>>>
>>>
>>> On 28-Jan-2014, at 11:23 am, Marcus Sorensen <sh...@gmail.com>> 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
>>> <ha...@citrix.com>> 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 <sh...@gmail.com>> wrote:
>>>
>>> Its an easy fix on the KVM side, just waiting to hear any objections.
>>> On Jan 27, 2014 6:11 PM, "Nux!" <nu...@li.nux.ro>> 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!
>>> www.nux.ro<http://www.nux.ro>
>>>
>>>
>>>
Re: KVM memory overprovision breaking me
Posted by Marcus Sorensen <sh...@gmail.com>.
Actually, does anyone have objections to adding an agent.properties
tunable to disable balloon? That would allow anyone who wants to
overcommit to do so, without messing with the existing FS, and the
calculations for allocation at least are all accurate. And I won't
have to maintain another local patch.
I just can't give someone a 4G VM and have it only show 2-1G inside,
just like I wouldn't give someone a 1T thin-provisioned disk and only
show them 100G. I know KSM will give me X memory dedup for my
workload, and I'd prefer to straight up over allocate VMs to the
guests based on that. Balloon just doesn't work anyway for most,
only if the customers are internal and agree not to meddle with it. I
think that goes for all hypervisors.
On Mon, Jan 27, 2014 at 11:28 PM, Marcus Sorensen <sh...@gmail.com> wrote:
> Yeah, I'm a little disappointed that the functional spec doesn't
> really address memory deduplication, which is the real version of
> overcommit, IMO. Since it looks like the feature is already fully
> implemented, I'm not sure I have much of a leg to stand on in trying
> to change it. I'll just patch it out of our builds. Thanks for the
> input.
>
> On Mon, Jan 27, 2014 at 11:13 PM, Bharat Kumar <bh...@citrix.com> wrote:
>> Hi Marcus,
>>
>> in case of KVM the guest memory is not dynamically adjusted by hypervisor, this is a hypervisor limitation. we have documented this in the FS in prerequisites for KVM.
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CPU+and+RAM+Overcommit
>>
>> One way to make this work automatically is to use a script to monitor the memory pressure in the guest VM and adjust the memory using cgroups.
>> one such script is Memory over commit manager.
>> more info here http://aglitke.wordpress.com/2011/03/03/automatic-memory-ballooning-with-mom/
>>
>> Thanks,
>> Bharat.
>>
>>
>>
>> On 28-Jan-2014, at 11:23 am, Marcus Sorensen <sh...@gmail.com>> 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
>> <ha...@citrix.com>> 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 <sh...@gmail.com>> wrote:
>>
>> Its an easy fix on the KVM side, just waiting to hear any objections.
>> On Jan 27, 2014 6:11 PM, "Nux!" <nu...@li.nux.ro>> 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!
>> www.nux.ro<http://www.nux.ro>
>>
>>
>>
Re: KVM memory overprovision breaking me
Posted by Bharat Kumar <bh...@citrix.com>.
Hi Marcus,
if you want to get what is assigned in the service offering then we can simply disable the overcommit feature.
Thanks,
Bharat.
On 28-Jan-2014, at 12:37 pm, Marcus Sorensen <sh...@gmail.com> wrote:
> They're both very specific. As mentioned, ballooning only works if
> you're basically just making vms for yourself. And even then you have
> to add your own script to make it work, hence my suggestion to enable
> it via agent.properties.
>
> Again, my main concern is that it messes with the service offering,
> you don't get what you see in the offering. It's downright painful for
> system vms.
>
> On Mon, Jan 27, 2014 at 11:44 PM, Bharat Kumar <bh...@citrix.com> wrote:
>> Hi Marcus,
>>
>> KSM or memory de-duplication on KVM can only be used when the memory pages are identical.
>> IMO this is a huge constraint which is true only for specific use cases. using KSM to implement overprovisioning
>> will limit this feature to a specific use case and hence memory ballooning was chosen which is more generic.
>>
>> Thanks,
>> Bharat.
>>
>> On 28-Jan-2014, at 11:58 am, Marcus Sorensen <sh...@gmail.com> wrote:
>>
>>> Yeah, I'm a little disappointed that the functional spec doesn't
>>> really address memory deduplication, which is the real version of
>>> overcommit, IMO. Since it looks like the feature is already fully
>>> implemented, I'm not sure I have much of a leg to stand on in trying
>>> to change it. I'll just patch it out of our builds. Thanks for the
>>> input.
>>>
>>> On Mon, Jan 27, 2014 at 11:13 PM, Bharat Kumar <bh...@citrix.com> wrote:
>>>> Hi Marcus,
>>>>
>>>> in case of KVM the guest memory is not dynamically adjusted by hypervisor, this is a hypervisor limitation. we have documented this in the FS in prerequisites for KVM.
>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CPU+and+RAM+Overcommit
>>>>
>>>> One way to make this work automatically is to use a script to monitor the memory pressure in the guest VM and adjust the memory using cgroups.
>>>> one such script is Memory over commit manager.
>>>> more info here http://aglitke.wordpress.com/2011/03/03/automatic-memory-ballooning-with-mom/
>>>>
>>>> Thanks,
>>>> Bharat.
>>>>
>>>>
>>>>
>>>> On 28-Jan-2014, at 11:23 am, Marcus Sorensen <sh...@gmail.com>> 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
>>>> <ha...@citrix.com>> 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 <sh...@gmail.com>> wrote:
>>>>
>>>> Its an easy fix on the KVM side, just waiting to hear any objections.
>>>> On Jan 27, 2014 6:11 PM, "Nux!" <nu...@li.nux.ro>> 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!
>>>> www.nux.ro<http://www.nux.ro>
>>>>
>>>>
>>>>
>>
Re: KVM memory overprovision breaking me
Posted by Marcus Sorensen <sh...@gmail.com>.
They're both very specific. As mentioned, ballooning only works if
you're basically just making vms for yourself. And even then you have
to add your own script to make it work, hence my suggestion to enable
it via agent.properties.
Again, my main concern is that it messes with the service offering,
you don't get what you see in the offering. It's downright painful for
system vms.
On Mon, Jan 27, 2014 at 11:44 PM, Bharat Kumar <bh...@citrix.com> wrote:
> Hi Marcus,
>
> KSM or memory de-duplication on KVM can only be used when the memory pages are identical.
> IMO this is a huge constraint which is true only for specific use cases. using KSM to implement overprovisioning
> will limit this feature to a specific use case and hence memory ballooning was chosen which is more generic.
>
> Thanks,
> Bharat.
>
> On 28-Jan-2014, at 11:58 am, Marcus Sorensen <sh...@gmail.com> wrote:
>
>> Yeah, I'm a little disappointed that the functional spec doesn't
>> really address memory deduplication, which is the real version of
>> overcommit, IMO. Since it looks like the feature is already fully
>> implemented, I'm not sure I have much of a leg to stand on in trying
>> to change it. I'll just patch it out of our builds. Thanks for the
>> input.
>>
>> On Mon, Jan 27, 2014 at 11:13 PM, Bharat Kumar <bh...@citrix.com> wrote:
>>> Hi Marcus,
>>>
>>> in case of KVM the guest memory is not dynamically adjusted by hypervisor, this is a hypervisor limitation. we have documented this in the FS in prerequisites for KVM.
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CPU+and+RAM+Overcommit
>>>
>>> One way to make this work automatically is to use a script to monitor the memory pressure in the guest VM and adjust the memory using cgroups.
>>> one such script is Memory over commit manager.
>>> more info here http://aglitke.wordpress.com/2011/03/03/automatic-memory-ballooning-with-mom/
>>>
>>> Thanks,
>>> Bharat.
>>>
>>>
>>>
>>> On 28-Jan-2014, at 11:23 am, Marcus Sorensen <sh...@gmail.com>> 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
>>> <ha...@citrix.com>> 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 <sh...@gmail.com>> wrote:
>>>
>>> Its an easy fix on the KVM side, just waiting to hear any objections.
>>> On Jan 27, 2014 6:11 PM, "Nux!" <nu...@li.nux.ro>> 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!
>>> www.nux.ro<http://www.nux.ro>
>>>
>>>
>>>
>
Re: KVM memory overprovision breaking me
Posted by Bharat Kumar <bh...@citrix.com>.
Hi Marcus,
KSM or memory de-duplication on KVM can only be used when the memory pages are identical.
IMO this is a huge constraint which is true only for specific use cases. using KSM to implement overprovisioning
will limit this feature to a specific use case and hence memory ballooning was chosen which is more generic.
Thanks,
Bharat.
On 28-Jan-2014, at 11:58 am, Marcus Sorensen <sh...@gmail.com> wrote:
> Yeah, I'm a little disappointed that the functional spec doesn't
> really address memory deduplication, which is the real version of
> overcommit, IMO. Since it looks like the feature is already fully
> implemented, I'm not sure I have much of a leg to stand on in trying
> to change it. I'll just patch it out of our builds. Thanks for the
> input.
>
> On Mon, Jan 27, 2014 at 11:13 PM, Bharat Kumar <bh...@citrix.com> wrote:
>> Hi Marcus,
>>
>> in case of KVM the guest memory is not dynamically adjusted by hypervisor, this is a hypervisor limitation. we have documented this in the FS in prerequisites for KVM.
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CPU+and+RAM+Overcommit
>>
>> One way to make this work automatically is to use a script to monitor the memory pressure in the guest VM and adjust the memory using cgroups.
>> one such script is Memory over commit manager.
>> more info here http://aglitke.wordpress.com/2011/03/03/automatic-memory-ballooning-with-mom/
>>
>> Thanks,
>> Bharat.
>>
>>
>>
>> On 28-Jan-2014, at 11:23 am, Marcus Sorensen <sh...@gmail.com>> 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
>> <ha...@citrix.com>> 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 <sh...@gmail.com>> wrote:
>>
>> Its an easy fix on the KVM side, just waiting to hear any objections.
>> On Jan 27, 2014 6:11 PM, "Nux!" <nu...@li.nux.ro>> 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!
>> www.nux.ro<http://www.nux.ro>
>>
>>
>>
Re: KVM memory overprovision breaking me
Posted by Marcus Sorensen <sh...@gmail.com>.
Yeah, I'm a little disappointed that the functional spec doesn't
really address memory deduplication, which is the real version of
overcommit, IMO. Since it looks like the feature is already fully
implemented, I'm not sure I have much of a leg to stand on in trying
to change it. I'll just patch it out of our builds. Thanks for the
input.
On Mon, Jan 27, 2014 at 11:13 PM, Bharat Kumar <bh...@citrix.com> wrote:
> Hi Marcus,
>
> in case of KVM the guest memory is not dynamically adjusted by hypervisor, this is a hypervisor limitation. we have documented this in the FS in prerequisites for KVM.
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CPU+and+RAM+Overcommit
>
> One way to make this work automatically is to use a script to monitor the memory pressure in the guest VM and adjust the memory using cgroups.
> one such script is Memory over commit manager.
> more info here http://aglitke.wordpress.com/2011/03/03/automatic-memory-ballooning-with-mom/
>
> Thanks,
> Bharat.
>
>
>
> On 28-Jan-2014, at 11:23 am, Marcus Sorensen <sh...@gmail.com>> 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
> <ha...@citrix.com>> 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 <sh...@gmail.com>> wrote:
>
> Its an easy fix on the KVM side, just waiting to hear any objections.
> On Jan 27, 2014 6:11 PM, "Nux!" <nu...@li.nux.ro>> 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!
> www.nux.ro<http://www.nux.ro>
>
>
>
Re: KVM memory overprovision breaking me
Posted by Bharat Kumar <bh...@citrix.com>.
Hi Marcus,
in case of KVM the guest memory is not dynamically adjusted by hypervisor, this is a hypervisor limitation. we have documented this in the FS in prerequisites for KVM.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CPU+and+RAM+Overcommit
One way to make this work automatically is to use a script to monitor the memory pressure in the guest VM and adjust the memory using cgroups.
one such script is Memory over commit manager.
more info here http://aglitke.wordpress.com/2011/03/03/automatic-memory-ballooning-with-mom/
Thanks,
Bharat.
On 28-Jan-2014, at 11:23 am, Marcus Sorensen <sh...@gmail.com>> 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
<ha...@citrix.com>> 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 <sh...@gmail.com>> wrote:
Its an easy fix on the KVM side, just waiting to hear any objections.
On Jan 27, 2014 6:11 PM, "Nux!" <nu...@li.nux.ro>> 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!
www.nux.ro<http://www.nux.ro>
Re: KVM memory overprovision breaking me
Posted by Marcus Sorensen <sh...@gmail.com>.
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
<ha...@citrix.com> 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 <sh...@gmail.com> wrote:
>
>> Its an easy fix on the KVM side, just waiting to hear any objections.
>> On Jan 27, 2014 6:11 PM, "Nux!" <nu...@li.nux.ro> 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!
>>> www.nux.ro
>>>
>
Re: KVM memory overprovision breaking me
Posted by Harikrishna Patnala <ha...@citrix.com>.
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 <sh...@gmail.com> wrote:
> Its an easy fix on the KVM side, just waiting to hear any objections.
> On Jan 27, 2014 6:11 PM, "Nux!" <nu...@li.nux.ro> 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!
>> www.nux.ro
>>
Re: KVM memory overprovision breaking me
Posted by Marcus Sorensen <sh...@gmail.com>.
Its an easy fix on the KVM side, just waiting to hear any objections.
On Jan 27, 2014 6:11 PM, "Nux!" <nu...@li.nux.ro> 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!
> www.nux.ro
>
Re: KVM memory overprovision breaking me
Posted by Nux! <nu...@li.nux.ro>.
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!
www.nux.ro