please install all updates first before reporting issues, as things may have already been fixed.
There were no available updates at the time I observed this message (no-subscription repositories).
Sorry, typo:
PU(s) 16 x 13th Gen Intel(R) Core(TM) i5-13500H (1 Socket)
Kernel Version Linux 6.14.11-4-pve (2025-10-10T08:04Z)
Boot Mode EFI (Secure Boot)
Manager Version pve-manager/9.0.11/3bf5476b8a4699e2
Same. Yesterday got. But have CIFS to another machine from host side mapped to one LXC (PBS). Latest version too.
System Information Manufacturer: MINIX | Product Name: NEO Z150-0dB
Kernel Version Linux 6.14.11-4-pve (2025-10-10T08:04Z)
Boot Mode EFI (Secure Boot)
Manager Version pve-manager/9.0.11/3bf5476b8a4699e2
Code:
Nov 03 22:01:55 pve pvestatd[979]: proxmox-backup-client failed: Error: http request timed out
Nov 03 22:01:55 pve pvestatd[979]: status update time (120.242 seconds)
Nov 03 22:02:56 pve kernel: CIFS: VFS: \\192.168.0.100 has not responded in 180 seconds. Reconnecting...
Nov 03 22:02:56 pve kernel: CIFS: VFS: close cached dir rc -11
Nov 03 22:03:06 pve pvestatd[979]: proxmox-backup-client failed: Error: EHOSTDOWN: Host is down
Nov 03 22:03:07 pve pvestatd[979]: status update time (71.617 seconds)
Nov 03 22:03:43 pve kernel: watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [tokio-runtime-w:622612]
Nov 03 22:03:43 pve kernel: Modules linked in: dm_snapshot bluetooth nf_conntrack_netlink xt_nat xt_tcpudp macvlan xt_conntrack xt_MASQUERADE xt_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype nft_compat xfrm_user xfrm_algo overlay cmac nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm >
Nov 03 22:03:43 pve kernel: x86_pkg_temp_thermal soundwire_bus intel_powerclamp snd_soc_sdca coretemp snd_soc_avs kvm_intel snd_soc_hda_codec snd_hda_ext_core i915 snd_soc_core kvm snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel sch_fq_codel snd_intel_dspcfg irqbypass snd_intel_sdw_acpi polyval_clmulni polyv>
Nov 03 22:03:43 pve kernel: CPU: 2 UID: 34 PID: 622612 Comm: tokio-runtime-w Tainted: P W O 6.14.11-4-pve #1The io_thread method cannot help with OS installation, since the ISO was used and the system became unresponsive during the process. I'm on versoin 9.
The only way to bypass this soft freeze is to stop all other VMs, which is very annoying. Otherwise, no new VM can be 'installed'.
The only way to bypass this soft freeze is to stop all other VMs, which is very annoying. Otherwise, no new VM can be 'installed'.
I'm on Proxmox 9.0.11 with a similar problem. For storage they were using local, LVM-Thin storage. It should be pretty fast storage, it's just LVM-Thin running on some NVME disks.
I already had IO thread checked (aka iothread=1)
And my 2 VM's were using 'VirtIO SCSI single' for the SCSI Controller. But the CPU was set to something other than "host"... so I just changed the CPU to 'host', and while I was at it I set the Async IO (aka aio) to "threads" instead of the default of 'io_uring'.
I don't know if reducing the cores, changing CPU to host, and setting Async IO to 'threads' (aka aio=threads) will fix the issue but it's all I could come up with after going over this forum post and comments.
----
EDIT: Nope, that did not do the trick. i don't see the error in the kernel logs in the VM's anymore but there's still clearly something going on with resources, any type of activity in one VM will cause the other VM to become unresponsive until i stop the activity in the 1st VM. This is very odd.
I already had IO thread checked (aka iothread=1)
And my 2 VM's were using 'VirtIO SCSI single' for the SCSI Controller. But the CPU was set to something other than "host"... so I just changed the CPU to 'host', and while I was at it I set the Async IO (aka aio) to "threads" instead of the default of 'io_uring'.
I don't know if reducing the cores, changing CPU to host, and setting Async IO to 'threads' (aka aio=threads) will fix the issue but it's all I could come up with after going over this forum post and comments.
----
EDIT: Nope, that did not do the trick. i don't see the error in the kernel logs in the VM's anymore but there's still clearly something going on with resources, any type of activity in one VM will cause the other VM to become unresponsive until i stop the activity in the 1st VM. This is very odd.
Last edited: