Re: [RFC] memory settings interface for containers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]