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
