Re: [libvirt] [RFC] memory settings interface for containers

On Thu, Nov 12, 2015 at 11:11:31AM +0300, Nikolay Shirokovskiy wrote: > Hi, everyone. > > I plan to add means to configure vz containers memory setting and have trouble > getting it done thru libvirt interface. Looks like current interface fits good > for vm memory managment but its not clear how to use it with containers. First > let's take aside memory hotplugging which is obviously not suitable for > containers. Then memory interface is represented by 2 parameters: total_memory > and cur_balloon. For VMs total_memory can't be changed at runtime, cur_ballon > can't be greater than total_memory. But for containers memory model is > different. We have only one parameter and it can be changed for running > domains. So question is how to map this model to existing interface (it is > unlikely to have a new interface for this case). I plan to make both parameters > to have same meaning and be equal for containers and update virsh, API and xml > model documentation accordingly. > > I'd be happy to hear core developers opinions on this topic. So from VM POV, the 'total_memory' represents the initial populated memory map. This is traditionally fixed at boot and cannot be changed while the VM is running. 'cur_balloon' represents the current memory after balloon adjustments and must be strictly less than or equal to total_memory. When the VM is shutoff, both values can be changed, but if you want to increase 'cur_balloon' you must first increase 'total_memory'. With LXC we essentially ignore 'cur_balloon' and just set the cgroups memory.limit_in_bytes to the 'total_memory' value.

For reasons that escape me, we forbid changes to 'total_memory' in LXC driver, despite the fact that we could trivially allow them. We should fix that. In the virDomainInfo struct, things are a little different. For VMs we report 'current' as being the current balloon level. For LXC we report 'current' as being the current container usage, as reported by memory.usage_in_bytes cgroup field. I agree we should be more explicit about this all in the docs. For initial XML config, we should just raise an error if both <memory> and <currentMemory> are present and have different values, or possibly just clamp <currentMemory> to match <memory>. In virDomainSetMemoryFlags() we should document that with container based virt, you cannot change the CURRENT_MEMORY setting, and with machine based virt you cannot change the MAX_MEMORY setting but containers should allow it.

Regards, Daniel