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 :|