Search results

I was current as of yesterday! Sorry I missed the announcement... congrats!

Solution is a kernel later than 4.15. If you want to patch in a custom kernel, you could use 4.18, but this is unsupported. It doesn't appear that Proxmox 5 will be released with a new kernel branch considering it doesn't seem to affect everyone and the reasons one system is affected but not...

My apologies for the necrobump, but I upgraded to 5.3-6 over the weekend and am experiencing the same issue starting LXC containers again. Is there a known regression and/or a fix?

I've had no issues at all with kernel 4.15. It was integrated into the latest Proxmox. Check the release notes of the new version.

@fabian - thanks for your update! I guess I missed where the kernel was available in stable, just not as default. I think taking the time to test is prudent prior to moving it to default in stable. In that case, I'll probably test 4.15 kernel the next time I reboot the machine. Is there any...

Proxmox admins posted on the another thread that they are in testing, but won't release it until they consider it stable. I don't know what is required to occur. You could ask there, but it sounded like they have a "it'll be ready when it's ready" perspective - which is fair, they don't want...

The other threads mentioned above have a new kernel in test which solves this problem. You can either choose to use that new kernel now or wait until it comes out in the stable branch as an update. Unfortunately, until then, it seems you need a hard reboot of the host to fix the problem...

I'm a couple upgrades behind (5.1_43) - is this a regression? I've had no issues with multiple IPs on a container, or kworker CPU utilization. One container has three, and they persist with no special configuration through a container or server reboot (single node, no HA).

Could you explain issue 3? I have multiple containers running multiple IPs, though they are on different configured interfaces (host has multiple VLANs configured and shares them as separate network cards to the containers). Are you assigning multiple IPs from the same network interface /...

Thanks for your testing, Vasu. I'm patiently waiting for this to move to stable, as I am running a mixed system with qemu and lxc. Good to know that the solution is around the corner!

Thanks! I followed those threads too. It does seem like the same issue - filesystem locking makes sense if I'm seeing frozen processes. I am running Proxmox in a homelab, so it's not as mission critical. I'll probably wait for the official fix. It's just irritating to have to reboot the server...

Once again this occurred. This time, I had restarted an LXC container a few times over the past week, but all seemed well, except the fact that there was network information on the dashboard, but the system showed 0 CPU and Memory utilization (even though the container was in fact running). I...

Just had another occurrence of this happening. Created an LXC container a few days ago, and has been well. Apache DS LDAP system, container is Debian. It had been sitting idle, waiting for me to get home to configure it. Today, I went to use the console via the control panel, but it was...

@Ale_IF - Thanks, I understand. Your English is good, I just wasn't sure which resource was the issue. I'm not anywhere near the RAM or CPU utilization, so for me that isn't a reason for the lockup problem.

@Ale_IF - I'm not sure what you mean by redistributing the resources. For my system, I'm running nowhere near the hardware's limits. I do see that Proxmox adds specific CPU identifiers to the LXC containers when I limit it to X cores, and some of them overlap with other containers, but it...

It might be related to a timeout during shutdown of the container causing the frozen monitor task? I cut some long-running processes out of 103 for test and was able to shut down and restart this container (which is usually my problem child) multiple times with no issue. I'll keep testing...

I've been having the same issues, without the 100% CPU issue. I find that when I reboot the system, it works normally, but if I start and stop more than one or two containers after the initial startup sequence, that container I'm start/restarting dies. When that happens, I get the same (?)...