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