How lxc can access host's kernel parameters?

For unprivileged CT without nesting the command line

sysctl -a | grep -E "net.core.rmem_default|net.core.rmem_max|net.core.wmem_default|net.core.wmem_max"

gots even more

sysctl: permission denied on key 'kernel.apparmor_display_secid_mode'
sysctl: permission denied on key 'kernel.apparmor_restrict_unprivileged_io_uring'
sysctl: permission denied on key 'kernel.apparmor_restrict_unprivileged_userns_complain'
sysctl: permission denied on key 'kernel.apparmor_restrict_unprivileged_userns_force'
sysctl: permission denied on key 'kernel.cad_pid'
sysctl: permission denied on key 'kernel.unprivileged_userns_apparmor_policy'
sysctl: permission denied on key 'kernel.usermodehelper.bset'
sysctl: permission denied on key 'kernel.usermodehelper.inheritable'
sysctl: permission denied on key 'vm.mmap_rnd_bits'
sysctl: permission denied on key 'vm.mmap_rnd_compat_bits'
sysctl: permission denied on key 'vm.stat_refresh'
 
that is expected, but the question (ignoring errors, or using my command from earlier) it displays the value you are after..
 
  • Like
Reactions: Sasha
HOST

net.core.bpf_jit_enable = 1
net.core.bpf_jit_harden = 0
net.core.bpf_jit_kallsyms = 1
net.core.bpf_jit_limit = 528482304
net.core.busy_poll = 0
net.core.busy_read = 0
net.core.default_qdisc = pfifo_fast
net.core.dev_weight = 64
net.core.dev_weight_rx_bias = 1
net.core.dev_weight_tx_bias = 1
net.core.devconf_inherit_init_net = 0
net.core.fb_tunnels_only_for_init_net = 0
net.core.flow_limit_cpu_bitmap = 0000
net.core.flow_limit_table_len = 4096
net.core.gro_normal_batch = 8
net.core.high_order_alloc_disable = 0
net.core.max_skb_frags = 17
net.core.mem_pcpu_rsv = 256
net.core.message_burst = 10
net.core.message_cost = 5
net.core.netdev_budget = 300
net.core.netdev_budget_usecs = 2000
net.core.netdev_max_backlog = 1000
net.core.netdev_rss_key = 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
net.core.netdev_tstamp_prequeue = 1
net.core.netdev_unregister_timeout_secs = 10
net.core.optmem_max = 131072
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.rps_default_mask = 0000
net.core.rps_sock_flow_entries = 0
net.core.skb_defer_max = 64
net.core.somaxconn = 4096
net.core.tstamp_allow_data = 1
net.core.txrehash = 1
net.core.warnings = 0
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
net.core.xfrm_acq_expires = 30
net.core.xfrm_aevent_etime = 10
net.core.xfrm_aevent_rseqth = 2
net.core.xfrm_larval_drop = 10

GUEST

net.core.optmem_max = 131072
net.core.rps_default_mask = 0000
net.core.somaxconn = 4096
net.core.txrehash = 1
 
Last edited:
I'm a bit stumped at what's going on there, and can't reproduce the issue unfortunately.

what happens if you mount a new procfs somewhere?

e.g., on the host, do "journalctl -f" to get logs, and in a second shell, enter the guest and do "mkdir /tmp/proc; mount -t proc proc /tmp/proc; find /tmp/proc/sys/net/core"
 
  • Like
Reactions: Sasha
I'd like to highlight also, that a have three ProxMox zones (prod test proxy updated to 8.4.1)
It was installed in different times and by different admins on different HW. But on every CT (privileged not privileged nested or not)
command sysctl -a | grep -E "net.core.rmem_default|net.core.rmem_max|net.core.wmem_default|net.core.wmem_max" shows the same as showed above.

Here You are host's shell view with journalctl -f:

Code: 
root@hqm:~# journalctl -f
Jun 03 11:39:08 hqm systemd[2744636]: Reached target default.target - Main User Target.
Jun 03 11:39:08 hqm systemd[2744636]: Startup finished in 108ms.
Jun 03 11:39:08 hqm systemd[1]: Started user@0.service - User Manager for UID 0.
Jun 03 11:39:08 hqm systemd[1]: Started session-3044.scope - Session 3044 of User root.
Jun 03 11:39:08 hqm sshd[2744631]: pam_env(sshd:session): deprecated reading of user environment enabled
Jun 03 11:39:08 hqm sshd[2744634]: Accepted password for root from 192.168.1.45 port 56074 ssh2
Jun 03 11:39:08 hqm sshd[2744634]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Jun 03 11:39:08 hqm systemd-logind[1063]: New session 3046 of user root.
Jun 03 11:39:08 hqm systemd[1]: Started session-3046.scope - Session 3046 of User root.
Jun 03 11:39:08 hqm sshd[2744634]: pam_env(sshd:session): deprecated reading of user environment enabled

Here You are guest's shell with required commands results:

Code: 
[root@db ~]# mkdir /tmp/proc
[root@db ~]# mount -t proc proc /tmp/proc
[root@db ~]# find /tmp/proc/sys/net/core
/tmp/proc/sys/net/core
/tmp/proc/sys/net/core/optmem_max
/tmp/proc/sys/net/core/rps_default_mask
/tmp/proc/sys/net/core/somaxconn
/tmp/proc/sys/net/core/txrehash
/tmp/proc/sys/net/core/xfrm_acq_expires
/tmp/proc/sys/net/core/xfrm_aevent_etime
/tmp/proc/sys/net/core/xfrm_aevent_rseqth
/tmp/proc/sys/net/core/xfrm_larval_drop
 
Last edited:
could you maybe try with the 6.14 kernel? "apt install proxmox-kernel-6.14" (you can always select the 6.8 one at boot time if something doesn't work with it).
 
  • Like
Reactions: Sasha
Linux imedia 6.14.5-1-bpo12-pve #1 SMP PREEMPT_DYNAMIC PMX 6.14.5-1~bpo12+1 (2025-05-21T15:55Z) x86_64 GNU/Linux

Code: 
sysctl -a | grep -E "net.core.rmem_default|net.core.rmem_max|net.core.wmem_default|net.core.wmem_max"

shows inside guest

Code: 
sysctl: reading key "kernel.apparmor_display_secid_mode"
sysctl: reading key "kernel.apparmor_restrict_unprivileged_io_uring"
sysctl: reading key "kernel.apparmor_restrict_unprivileged_userns_complain"
sysctl: reading key "kernel.apparmor_restrict_unprivileged_userns_force"
sysctl: reading key "kernel.unprivileged_userns_apparmor_policy"
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576

I don't understand what sysctl: reading key is, but it looks better 8)
 
okay, so there seems to be a difference how the older and newer kernels handle those sysctls within a namespace.

the 'reading' messages are warnings that some sysctl keys are not accessible in a container, that is normal. you can either ignore that or let sysctl filter the keys, like in my example command earlier..
 
  • Like
Reactions: Sasha
  • Like
Reactions: Sasha
It hurts... My case is exactly "some software inside might want to read"...
But would You shed a light when that greatest commit will be in PVE release?
 
Last edited:
it already is in the 6.14 kernel series, if you don't run into any bugs specific to that you can just use it..
 
  • Like
Reactions: Sasha
Yes it's a really interesting way to use 6.14 on production... What's about official ProxMox support on that way?
It would be great to understand will Proxmox be on 6.14 officially...
 
it is supported, it's just not the default.
 
  • Like
Reactions: Sasha
You must log in or register to reply here.
Top Bottom