libvirt users - Oct 2019 - libvirt_lxc memory limit, emulator process part of the cgroup?

hi,

I am currently investigating a bug with libvirt lxc. Whenever I do a
systemctl daemon-reload on the host, my container loses his memory limit
and then reports having access to 8 exabyte of memory.

I have tracked the issue down to two parts:

memory.limit_in_bytes jumps from the correct value to 9223372036854771712.

libvirt lxc appears to set the memory limit in transient way without
writing a config for systemd. I can't prevent memory.limit_in_bytes
changing by setting the correct value through systemctl set-property
--runtime <scope> MemoryLimit
tasks in the memory cgroup gets cleaned up.

After starting the container the cgroup contains 3 pid. The pid of the
libvirt_lxc process, the pid of the init process in the container and
third unknown pid that doesn't exists in /proc/.

After a demon-reload only the init process  remains in the cgroup and
unless I move the libvirt_lxc process into the cgroup the memory limit
isn't enforced.

I have also noticed that when starting libvirtd it complains about
GetMachineByPID failing for the libvirt_lxc process.


This leaves me with one big question, the the emulator process
libvirt_lxc supposed to be part of the container's cgroup or not? The
leader of the container is the init process in the container. I am
unsure on how the additional emulator process is supposed to be registered.


Using: Debian Stretch, libvirt 5.0.0-4, systemd 241-7~deb10u1 and hybrid
cgroups.


Regards,
Maximilian Philipps

On 10/28/19 6:41 AM, Maximilian Philipps wrote:
> hi,
> 
> I am currently investigating a bug with libvirt lxc. Whenever I do a
> systemctl daemon-reload on the host, my container loses his memory limit
> and then reports having access to 8 exabyte of memory.
> 
> I have tracked the issue down to two parts:
> 
> memory.limit_in_bytes jumps from the correct value to 9223372036854771712.
> 
> libvirt lxc appears to set the memory limit in transient way without
> writing a config for systemd. I can't prevent memory.limit_in_bytes
> changing by setting the correct value through systemctl set-property
> --runtime <scope> MemoryLimit> 
> tasks in the memory cgroup gets cleaned up.
> 
> After starting the container the cgroup contains 3 pid. The pid of the
> libvirt_lxc process, the pid of the init process in the container and
> third unknown pid that doesn't exists in /proc/.
> 
> After a demon-reload only the init process  remains in the cgroup and
> unless I move the libvirt_lxc process into the cgroup the memory limit
> isn't enforced.
> 
> I have also noticed that when starting libvirtd it complains about
> GetMachineByPID failing for the libvirt_lxc process.
> 
> 
> This leaves me with one big question, the the emulator process
> libvirt_lxc supposed to be part of the container's cgroup or not? The
> leader of the container is the init process in the container. I am
> unsure on how the additional emulator process is supposed to be registered.
> 
CCing danpb who likely knows best

You may want to give latest libvirt a shot though, there was a lot of
cgroup changes since 5.0.0 release. It may actually make things worse
with lxc driver though, but it will be another data point at least

- Cole