Search results

Hello. Unfortunately, nothing new here. The only workaround for us was to enable compression when using remote storage.

That's not it. In this case, all tests were made with pure ext4/RAID1 on two HDD disks as NFS target. No deduplication is used now. Since backup is (more or less) linear write, it should not matter if it is HDD, SSD or NVMe drives. Also, I ran atop and iostat on target machine (NFS server)...

Hello again, I've made some tests. And now I'm even more confused. First backup (compress=0), remote NFS: backup log ---------- INFO: starting new backup job: vzdump 4031 --mode snapshot --notes-template '{{guestname}}' --remove 0 --storage backup --compress 0 --notification-mode auto --node...

Hi, I think this is a problem with asymmetric routing. Please try with tcpdump -ni any icmp and host 10.10.100.105 on ProxmoxB and run ping 10.10.125.100 from 10.10.100.105. I may be wrong, but there should be incoming packet on interface vmbrYork, and outgoing one on vmbr0 The solution would...

Are you sure it's not a routing problem? Are you able to PING different IPs both ways? In default PVE installation, pveproxy listens on tcp/8006 port on all interfaces, so it should not be a case. To be honest, some diagram would be great here ;-)

Messages are from VM, not PVE host. PVE seems to be working fine. Backups are invoked by Backup Job on PVE cluster: INFO: starting new backup job: vzdump 4031 --notification-mode auto --node pk05 --remove 0 --compress 0 --storage backup --mode snapshot --notes-template '{{guestname}}' INFO...

The whole environment was migrated to 8.2.2 PVE couple of days ago. I was fighting with NFS bug since then and, honestly, didn't notice rcu one. So it's hard to tell how long it's an issue for us. I see no problems on Proxmox host itself (dmesg is clear). Other VMs/CTs also works fine (i tried...

It's because we use NFS for keeping backups and hit an error with memory leak in 6.8 kernel: https://bugzilla.kernel.org/show_bug.cgi?id=218671 So 6.5.13-5-pve is the newest one that works without this issue. Thread you mentioned says that rcu issue was fixed around 6.5.11-4-pve or 6.5.11-5-pve

Hello, We've got 6 node cluster with a bunch on VMs and CTs on it. All nodes are updated to PVE 8.2.2 (pve-manager/8.2.2/9355359cd7afbae4, kernel 6.5.13-5-pve) and work (almost) smoothy. Unfortunately, there are some weird issues with "rcu_sched self-detected stall on cpu" during the backup. A...

I had the same problem. chmod helped (use at your own risk!): root@w:/# ls -ld / drwx------ 23 root root 4096 Jun 17 11:51 / root@w:/# chmod 755 / But still not sure what happend that this permission was changed :-\