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 > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list