On 14.01.2016 16:01, Daniel P. Berrange wrote:
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. [1]
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. [2]
Thanks for answer, Daniel. So actual[1] and proposed[2] behaviour are different if in [2] you mean 'fail' when say 'cannot change'. So wouldn't fixing [1] to [2] be a degradation? It is a case of a really lame libvirt usage but nevertheless. Thes same question raises to XML config. If adding checks can break somebody?
Regards, Daniel