sysinfo() liefert in PCT Daten des Host

[Sebastian Lehn]

Hallo Forum,

ich habe festgestellt, dass in Proxmox Containern die Linux Funktion sysinfo (man 2 sysinfo) die Daten des Host liefert und nicht die des Containers.

Das hat zur folge, dass z.B. Monitoring-Agenten wie dem Zabbix-Agent falsche Werte geliefert werden. Abfragbar via:

Zabbix 3.0 agent

zabbix_agentd -t system.swap.size[all,free]

Zabbix 2.x agent

zabbix_agent -t system.swap.size[all,free]

 

[pixelpeter]

Hallo,

VM's emulieren einen kompletten host. Hier ist es auch möglich eine anderen Kernel,OS als im Host zu benutzen.
CT's nutzen den Hostkernel und demnach auch seine settings.
Wenn es ein Problem ist nimm eine VM.

Peter

 

[Sebastian Lehn]

Hallo Peter,

da muss ich dir teilweise widersprechen. PCT verwenden Namespaces und Cgroups um Ressourcen einzuschränken und von einander abzuschotten. Eine Funktionalität ist z.B. die Begrenzung des verfügbaren Speichers. In Proxmox ist dies schon einstellbar und auch im /proc/meminfo sichtbar. Da aber nicht alle Programme den verwendeten Speicher aus dem procfs abrufen, sondern z.B. die Methode sysinfo() verwenden, sollte auch diese korrekte Werte liefern.

Lieben Gruß

Sebastian

Hallo,

VM's emulieren einen kompletten host. Hier ist es auch möglich eine anderen Kernel,OS als im Host zu benutzen.
CT's nutzen den Hostkernel und demnach auch seine settings.
Wenn es ein Problem ist nimm eine VM.

Peter

 

[wbumiller]

PCT verwenden Namespaces und Cgroups

Das ist genau der Punkt. Das Konzept eines "Containers" als ganzes ist dem Kernel nicht bekannt, und sysinfo(2) funktioniert nunmal so.

 

[Sebastian Lehn]

Ich möchte gern auf folgenden Link hinweisen: fabiokung DOT com /2014/03/13/memory-inside-linux-containers/

Damals (2014) gab es das Problem, dass free und top immer den kompletten Speicherbereit des Hostsystems ausgewiesen haben. Heute, gibt es eine Anpassung im LXC/PCT welche dafür sorgt, dass diese Tools über /proc/meminfo lediglich die Werte aus der entsprechenden Cgroup ausweisen.

Ich halte eine "Das ist nun mal so wie es ist" nicht für akzeptabel. Die sysinfo(2) Funktion wurde in 2013 selbst von libvirt-lxc für den Container umgesetzt. Ich denke Proxmox Container sollten dies genauso können. Siehe www DOT redhat DOT com/archives/libvir-list/2013-April/msg00301.html

Gruß
Sebastian

 

[dcsapak]

Ich halte eine "Das ist nun mal so wie es ist" nicht für akzeptabel. Die sysinfo(2) Funktion wurde in 2013 selbst von libvirt-lxc für den Container umgesetzt. Ich denke Proxmox Container sollten dies genauso können. Siehe www DOT redhat DOT com/archives/libvir-list/2013-April/msg00301.html

der patch im link macht etwas ganz anderes: da geht es um die sysinfo vom host des lxc hypervisors (also wo lxc läuft) nicht um einen container

damit der container mit einem syscall etwas anderes sieht als der host, muss das bereits im kernel implementiert sein, da das abfangen eines (aller?) syscalls nicht wirklich trivial ist

 

[Sebastian Lehn]

@dcsapak: Danke. Dann wäre es vielleicht richtiger einen Bug beim Kernel auf zu machen?

 

[dcsapak]

ich glaube besser wäre einen bug beim monitoring tool zu machen, da ich nicht glaube das so eine funktionalität in den kernel kommt. wie @wbumiller bereits gesagt hat: der kernel hat kein Konzept eines "containers" also hat es dann auch keinen sinn einem prozess "falsche" werte zurückzugeben (wie sollte der kernel denn zb zwischen systemcontainern wie lxc und applikationscontainern unterscheiden?, aus kernel sicht sind das einfach zwei prozesse in einer cgroup)