Search results

Yes, it's more robust. - everynight vzdump to additional (external) disks - PBS sync job of datastore to additional (external) datastore - everynight rsync /etc/* of host and vz to additional (external) disks

I completely agree with You. rsync and etc are weak place. Adding some additional external datastore for bs's backup is very good approach instead of "hacky" games...

As You said we need another backup server for that... But rsync is for simple straight filesystem copying and need just a additional disk... One more level of paranoya... From my view point "rsync of datastore folder" can cover the case of bs's disk system fall... But second pbs is very good...

Have You noticed *paranoid* in topic's caption? 8))) My backup of vz now contains from - everynight vzdump - standart backup server' activity - rsync of datastore folder - rsync /etc/* of host and vz In fact BS's backups is really cool (!) thing for fast actualizing test zone. vzdump is more...

Appreciate for Your really long support 8)

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 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?

Well, so what is the our old-kernel's guys way? If any... 8)

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 sysctl -a | grep -E "net.core.rmem_default|net.core.rmem_max|net.core.wmem_default|net.core.wmem_max" shows inside guest sysctl: reading key "kernel.apparmor_display_secid_mode"...

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...

Would You try to continue that discussion? Or it's a stuck? Or it's a bug?

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 =...

Well, here You are a starting logs for newly created unprivileged CT without nesting

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...

Exactly! 8) Here You are CT 106 starting from host's log and from guest's log

It's hard to understand how host log can be cut off 8( I just rebooted host and wating log was fullfilled. Would You let me know what substrings combination we are looking for?

I do appreciate for Your competent opinion but would You clarify how i can permit containers reading that? sysctl -a | grep -E "net.core.rmem_default|net.core.rmem_max|net.core.wmem_default|net.core.wmem_max"

What's about "highly unusual and discouraged config" AFAIK it works about 10 years and nobody interested why some past admin made this 8| journalctl -b of restarting attached.

Let's go easier way. Here You are from GUEST 102 (Debian 12). Linux app 6.8.12-9-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-9 (2025-03-16T19:18Z) x86_64 GNU/Linux It has no any difference. Any guest can't access that kernel parameters ((( arch: amd64 cores: 2 features: nesting=1 hostname...

rpool/data/subvol-103-disk-0 on / type zfs (rw,relatime,xattr,posixacl,casesensitive) files on /opt/share type zfs (rw,relatime,xattr,noacl,casesensitive) none on /dev type tmpfs (rw,relatime,size=492k,mode=755,inode64) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) proc on...