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 <shadow...@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 <shadow...@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 <bharat.ku...@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 >>> <shadow...@gmail.com<mailto:shadow...@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 >>> <harikrishna.patn...@citrix.com<mailto:harikrishna.patn...@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 >>> <shadow...@gmail.com<mailto:shadow...@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!" <n...@li.nux.ro<mailto:n...@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> >>> >>> >>>
