Search results

That was spot-on. Thank you! I was looking in the wrong direction as I thought it was the updates in proxmox that caused this issue, but you are right, downgrading coreutils to 9.1-3 solved the issue.

I am running ArchLinux in LXC container and I just noticed something strange started happening recently. ArchLinux's AUR (Arch User Reposity) packages files make heavy use of "install" command/utility from GNU coreutils when after compilation. A day ago I went to get new updates installed and...

I would create a new thread. I don't believe the issue in this thread is related to what you are experiencing.

11th gen intel here and HW acceleration would stop working for me completely after a couple of passes. Nothing definitive in the Plex/emby logs so I just reverted to 5.15. I thought it was just me or my particular setup.

I wouldn't be too concerned about it if you are not using ksmbd (in-kernel smb server, userspace smb implementation - samba - is not affected). Also it is only of concern to those who do use ksmbd with many random users.

calcru: runtime went backwards from 1373029 usec to 763269 usec for pid 14053 (dpinger) calcru: runtime went backwards from 96102 usec to 53228 usec for pid 14053 (dpinger) I also run OPNsense on proxmox and have been seeing these for as long as I remember. Just a friendly FYI, not sure if it...

FYI I've been having this issue on 11th gen mobile CPU i5-1145G7 (before the workaround) and no issues on i7-9700. Both have latest proxmox and run Windows server 2022 Standard. The one with 9700 still has no workaround applied and it has been rock solid.

I think the statement about older CPUs is misleading. I have 11th gen Intel host with this issue, yet another system with 9th gen Intel is fine. kvm.tdp_mmu=N seems to have helped though. It's been 2 days now. Somehow CPU Usage went up a little though, after applying kvm.tdp_mmu=N . Not sure if...

I know this is an old thread, but since nobody had a solution I thought I would post for anyone who stumbles upon this thread later on. Given that Device Manager has no exclamation marks anywhere and every driver seems to be installed, I tried disabling "Use tablet for pointer" under "Options"...

ah, you need choose VirtIO Block instead of SCSI for the HardDisk Bus/Device

I'm guessing you need nested virtualization enabled. IIRC WSL2 requires VT-d/AMD-v instructions while WSL1 does not

1. wrong VM type (no big deal). 2. Wrong driver. You need vioscsi

It looks like they released an update (6.3.-8) which fixed it, https://github.com/proxmox/qemu-server/commit/0761e6194af3a5a486b2b8fc1bc698e4c286d65b Might've been after they saw this thread :) Full commit log: https://github.com/proxmox/qemu-server/commits/master

So did you try to go to VM->Hardware->Machine (Make sure "Advanced" is ticked) and change "Version" to one newer (or older) before you reconfigured the NICs within the VM itself? I didn't have a change before I discovered this.

Same happened with me. I have 2 nics in 2 Windows VMs so had to change 4 connections :( In the device manager if you go to View and check "Show hidden devices" it will show the "old" NICs there. I compared several properties under the "Details" tab for "old" and "new" ones and the only...

https://forum.proxmox.com/threads/solved-systemd-247-breaks-networking-in-lxc.80115/#post-354932

Thank you, sir. Much appreciate your help.

Thank you, that made it work with systemd 247. I also removed lxc.mount.auto: sys and it's still working fine. Do you know why new systemd would require nesting to be enabled?

Hi, Certainly: arch: amd64 cores: 4 features: fuse=1 hostname: SRV02 memory: 4096 mp0: /media/8TB,mp=/media/storage-pool nameserver: 10.0.0.1 net0: name=eth0,bridge=vmbr10,gw=10.0.0.1,hwaddr=xx:xx:xx:xx:xx,ip=10.0.0.6/24,type=veth onboot: 1 ostype: archlinux rootfs...

Running Archlinux in LXC here. Once again upgrading systemd 246.6-1 => 247.1-1 breaks networking within the LXC container. Downgrading systemd to 246.6-1 fixes the issues. Solution from https://forum.proxmox.com/threads/systemd-244-1-breaks-networking-in-lxc.61862 is already in place and does...