Search results

With that much ram just disable swap on the host. Much has changed since I last posted on this thread. We no longer use zram on hosts or in guests. On any host with more than 64GB of RAM we completely disable swap. I have never seen a situation where swap on the Proxmox host was beneficial but...

We use openvswitch and tagged vlans. When rebooting into kernel 5.4.114-1 we starting having network issues SSH connections would break, live migrations failing. Eventually networking stopped entirely. Rebooted with kernel 5.4.106-1 and everything works fine again. Intel 10G network card Not...

I have checked the MTU on all interfaces it is 1500 everywhere. I'm seeing the issue between proxmox nodes, have not seen it in guests so far.

Anyone at Proxmox have thoughts on this?

After recently upgrading to the latest version we started seeing these errors in the kernel on a few nodes. We are using openvswitch, the only thing I found using google that might explain the problem is this: https://lkml.org/lkml/2020/8/10/522 Before the update we were running kernel...

I had already downloaded and updated the firmware to the latest that I could find on Micron's website. These cards were working flawless in Proxmox 5, something changed in the kernel to cause this problem. I can setup a test system with my p420m cards to test solutions to the issue if anyone...

Never found a solution to the problem. We resolved the issue by removing the p420m and installing an Intel SSD in its place.

To answer my own question, the above patch does seem to be included in both the 5.3 and 5.4 pve kernels. I am currently testing older kernels to identify the latest version that does not have this problem.

Any way to tell if this patch is included in the proxmox kernel? https://lore.kernel.org/stable/20191006000130.GE25255@sasha-vm/T/ This seems to describe the exact issue I am having: The node having issues is only a drbd secondary, getting only writes from DRBD.

I have a p420m SSD that uses the mtip32xx driver in the kernel. This drive worked perfectly fine in Proxmox 5.x, after upgrading to 6.x write IO to the disk stalls frequently and can only be recovered with a reboot. We first experienced the problem within hours of upgrading to 6.x The...

@gkovacs After reading every comment in this thread I am in agreement with you. This problem exists, has existed for years now and while the sysctl settings mentioned help they do not entirely resolve it. I am tired of having outages because of it. The whole point of being able to move disks to...

So basically we cannot add new 6.x nodes until the cluster only contains 6.x nodes.

During the upgrade process I have some nodes that I would like to reinstall rather then do a dist-upgrade to 6.x. Is it possible to do this?: Upgrade Corosync to new version in 5.x cluster Upgrade some but not all 5.x to 6.x using dist-upgrade Delete a 5.x node from the cluster Do fresh...

Yes, we have very few windows servers. We do leave swap enabled for Windows but usually set it to a specific size instead of allowing Windows to manage it.

We currently have 20 nodes in production with no swap. The nodes range from 32GB RAM to 256GB RAM with the majority of them having 128GB RAM. Most of the VMs are configured NUMA aware. I usually do not set it if the VM uses little RAM and very few cores. I cannot recall ever having a VM get...

I have wrestled with this problem for years and never found a great solution, most of my nodes are NUMA too. Changing swappiness never prevented it. Any process that is idle will end up having its RAM swapped to disk if the kernel thinks that the RAM would be better used for buffer/cache. In my...

While running swapoff on a couple of nodes the swapoff task would hang, unable to turn swap off on zram devices. They would hang generating task hung messages. I believe these systems are still running. Could we get any diagnostic data from these systems that might help discover the source of...

We have not had any issues since turning off zRam over a month ago.

Server has 128GB RAM, Virtual servers all combined are assigned just under 60GB. We have zfs_arc_max set to 20GB We have not had any issues since turning off zram on the 15th. It needs to run stable for at least a month to have confidence that turning off zram fixed anything. I am considering...

If I am not mistaken zfs module was upgraded recently and I have already run zpool upgrade. I do not think it would be OK to boot up kernel with older zfs module, right? I went digging in the logs, these are attached as text files. All of these occurred when we had zfs swap and zram enabled...