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 <bharat.ku...@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 <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> >>> >>> >>> >
