Recent content by kobuki

For whomever is interested and finds this thread via search, I've made a simple python script (parts courtesy of ChatGPT) that is able to extract the complete file tree from a config.db. The script can be used without Proxmox, Python 3 and a few basic Python modules are the requirements. See here.

No solution, nor will ever be. See here.

After upgrading to PVE 8 and several CTs to Debian 12, I experience a loadavg discrepancy. The load averages shown in the CTs are that of the host, divided by the number of CPU cores of the LXC container (per-core loadavg in Zabbix), instead of the load of the LXC guest itself. The commands...

Well, for whomever finds this thread among the other similar ones, the issue was solved by fixing /etc/hosts to align the host names with the desired subnet, and then restarting pve-cluster.service and then corosync.service. Replication and other heavy traffic is flowing on the network it was...

I made a mistake when I created a 5-node cluster. I added all nodes by IP to the cluster and `pvecm status` now shows: Cluster information ------------------- Name: cluster2 Config Version: 5 Transport: knet Secure auth: on Quorum information ------------------ Date...

OK, it was actually a pretty lame issue. I had to clean up the garbage in GRUB_CMDLINE_LINUX in /etc/default/grub and presto, booting like it should. I leave this "solution" here for search engines.

I'm struggling with a seemingly simple task. I've copied the contents of an old Debian 8/Jessie VM from Azure to a PVE 6.1-7 host using rsync. I've set up boot, etc., and the VM does start booting, but I see the messages per attached image and it's stuck there forever. The root partition is a...

I scheduled a reboot and it fixed the issue. Weird.

I've upgraded a 5.2 system to latest 6.3 and experiencing something I've never before. It might or might not be PVE related, I have no idea. The gist of it, is I have a custom iptables firewall that loads without problems and does work. I had to allow a new IP for admin access, something like...

Apparently, this is the way it should be with cgroup v1. Cgroup v2 is supposed to show swap separately again but it's not active in PVE right now. It's unexplained why it was shown correctly (separately, as it should be in v2) in earlier 6.x versions. It's a mess, anyway. See also here.

It seems lxc-pve 4.0.6-2 is in the no-subs repo, so instead of downgrading it should be enough to upgrade to latest... Though I couldn't try it, yet.

Not now, as the system is live and people started working on it, but as an idea, I might try later. But i was under the impression that nesting is only necessary when processes try to create security namespaces and other security measures using cgroup inside CTs so my gut feeling says it won't help.

It has nothing to do with the problem at hand. It's just the tun device config, which is working fine. There's a small, but very definite difference in the CT vs. the older version of pve-lxc. The following mount entry is not present in the newer version: proc on /proc/sys/net type proc...

Sure, here it is: # pct config 101 arch: amd64 cores: 1 hostname: vpn.xxx.private memory: 512 net0: name=eth0,bridge=vmbr0,hwaddr=8A:D3:78:C4:11:22,type=veth onboot: 1 ostype: debian rootfs: thinhdd:vm-101-disk-1,size=8G swap: 128 lxc.cgroup.devices.allow: c 10:200 rwm lxc.mount.entry...

Same issue here with a CT running OpenVPN. It needs to enable IP forwarding in the kernel (e.g. /proc/sys/net/ipv4/ip_forward). Fails with write permission error. Quite the issue, it kills most network/routing oriented containers. Will try downgrading in the meantime. Downgrading...