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 -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list