[libvirt-users] 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
participants (2)
-
Cole Robinson
-
Maximilian Philipps