Search results

@TErxleben not sure I understand the question, but, what I noticed was that the entries in the kernel log for the interfaces that were entering/exiting promiscuous mode only corresponded to the VMs that were powered off at the time the backups started (see OP). For example, tap100i0, fwpr100p0...

Thanks for the idea, but the box doesn't have an Intel NIC. It's Realtek # lspci | grep Eth 2d:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) 2e:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet...

Not sure if that question was towards me, but the reason for me wanting to try newer kernels is because of this issue I'm having.

How are people doing with this 6.14 kernel in May 2025? I'm tempted to try it, but seems like it might be a bit of a rough ride still.

My backups (to PBS) are scheduled to run every night at 1:30am. For the last few nights, I get a warning from my Unifi switch saying that "multiple devices are using IP address 192.168.20.51..." which is the IP assigned to my bare metal PVE node. Nothing special about the node, it's a Mini NUC...

What tool is generating these graphs please?

Ever figure this out ?

I have a similar issue, and was also was running a WatchYourLan instance in a docker container. I ended up assigning a dedicated NIC for WYL to run in so it didn't need to put my "main" NIC into promisc mode. That quieted down the logs some, but... I am still seeing stuff like this every day...

How can we enable/disable maintenance mode via PVE API?

I tried this before but hit a wall, I don't think the Synology kernel supports this, see below for reference https://github.com/bcleonard/proxmox-qdevice/issues/10#issuecomment-2094267851 https://github.com/bcleonard/proxmox-qdevice/issues/2

Ah ha! Thanks for spotting that. You are right of course. This fixed it: root@nas:~# chmod 0755 /volume1/pbs root@nas:~# chown 34:34 /volume1/pbs root@pbs:~# proxmox-backup-client benchmark --repository syno-pbs Password for "root@pam": ******************* Uploaded 372 chunks in 5 seconds...

Here it is root@pbs:~# stat /mnt/syno-pbs File: /mnt/syno-pbs Size: 64 Blocks: 0 IO Block: 4096 directory Device: 0,43 Inode: 256 Links: 1 Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2025-04-01 00:02:40.550134005 -0400...

My datastore is mounted via NFS, I don't have a /host dir in there at all (?) root@pbs:/# find / -type d -name host /usr/lib/modules/6.8.12-8-pve/kernel/drivers/ufs/host /usr/lib/modules/6.8.12-8-pve/kernel/drivers/memstick/host /usr/lib/modules/6.8.12-8-pve/kernel/drivers/mmc/host...

Thanks for your help, if you have any other thoughts, please do let me know.

This is what I see... root@pbs:~# journalctl -f Mar 31 11:45:51 pbs systemd[1210]: Listening on gpg-agent-extra.socket - GnuPG cryptographic agent and passphrase cache (restricted). Mar 31 11:45:51 pbs systemd[1210]: Listening on gpg-agent-ssh.socket - GnuPG cryptographic agent (ssh-agent...

This: Linux pbs 6.8.12-9-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-9 (2025-03-16T19:18Z) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian...

Thank you for trying to help. No it is not in an LXC - I'm running it from a root shell on my PBS directly, which is a full Debian bookworm VM installed from the official PBS ISO, running on Synology VMM.

Thanks, yes it is on a NFS share, I think it set up correctly, and working fine... backups have been executing for >2 months...

Can anyone help me figure out how to benchmark with the --repository flag? No matter what I try, it doesn't work... https://pbs.proxmox.com/docs/backup-client.html#benchmarking # whoami root # proxmox-backup-client benchmark --repository 192.168.20.55:syno-pbs Password for "root@pam"...

Anything new here in Mar 2025? I am facing the same issue. Only 1 VM that has GPU passthrough enabled, but it keeps failing to back up. edit: In my case it was caused by a failure of PCI passthru, so the VM would not even start. Not actually a backup issue...