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 <shadow...@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 <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> >>>> >>>> >>>> >>
