I see that the same approach has been taken for CPU overprovisioning, but it actually works there, because cpu is allocated in 'shares', which are abstract and relative to all shares allocated. With memory, we can't just divide the raw size allocated and call it good. I think this was an oversight.
On Mon, Jan 27, 2014 at 5:49 PM, Marcus Sorensen <shadow...@gmail.com> 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.
