Random freezes due to host CPU type

fiona said:
Hi,

please share the output of pveversion -v. Anything in the system journal around the time of the issue? Is the latest CPU microcode installed: https://pve.proxmox.com/pve-docs/chapter-sysadmin.html#sysadmin_firmware_cpu ?
Click to expand...
Yeah there's a lot of thing, don't know what is related to the freeze tho since idk when it happened, i was working today
Have this tho:
Code: 
root@pve:~# pveversion -v
proxmox-ve: 9.0.0 (running kernel: 6.14.8-2-pve)
pve-manager: 9.0.3 (running version: 9.0.3/025864202ebb6109)
proxmox-kernel-helper: 9.0.3
proxmox-kernel-6.14.8-2-pve-signed: 6.14.8-2
proxmox-kernel-6.14: 6.14.8-2
amd64-microcode: 3.20250311.1
ceph-fuse: 19.2.3-pve1
corosync: 3.1.9-pve2
criu: 4.1.1-1
dnsmasq: 2.91-1
frr-pythontools: 10.3.1-1+pve4
ifupdown2: 3.3.0-1+pmx9
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.0
libproxmox-backup-qemu0: 2.0.1
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.0.3
libpve-apiclient-perl: 3.4.0
libpve-cluster-api-perl: 9.0.6
libpve-cluster-perl: 9.0.6
libpve-common-perl: 9.0.9
libpve-guest-common-perl: 6.0.2
libpve-http-server-perl: 6.0.3
libpve-network-perl: 1.1.6
libpve-rs-perl: 0.10.7
libpve-storage-perl: 9.0.13
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2
lxc-pve: 6.0.4-2
lxcfs: 6.0.4-pve1
novnc-pve: 1.6.0-3
proxmox-backup-client: 4.0.9-1
proxmox-backup-file-restore: 4.0.9-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.1.1
proxmox-kernel-helper: 9.0.3
proxmox-mail-forward: 1.0.2
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.0
proxmox-widget-toolkit: 5.0.4
pve-cluster: 9.0.6
pve-container: 6.0.9
pve-docs: 9.0.7
pve-edk2-firmware: 4.2025.02-4
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.3
pve-firmware: 3.16-3
pve-ha-manager: 5.0.4
pve-i18n: 3.5.2
pve-qemu-kvm: 10.0.2-4
pve-xtermjs: 5.5.0-2
qemu-server: 9.0.16
smartmontools: 7.4-pve1
spiceterm: 3.4.0
swtpm: 0.8.0+pve2
vncterm: 1.9.0
zfsutils-linux: 2.3.3-pve1
root@pve:~


I already have installed the latest microcode, and It's still borked:
1762459876079.png
 
Last edited:
Hey so i got some logs now because i was getting really annoyed at these crashes:

1762803350310.png
Those are all the last boot times i can get, that's how i knew when it crashed recently but as you can see it was always crashing/hangingimg-2025-11-10-20-37-38.png
 
What you could still try is to connect via another machine via SSH and monitor the journal there with journalctl -f. Maybe the logs cannot make it to disk, but you can see them "live". You could also try to avoid using the host CPU model for your VMs as a workaround like reported earlier in this thread.
 
fiona said:
What you could still try is to connect via another machine via SSH and monitor the journal there with journalctl -f. Maybe the logs cannot make it to disk, but you can see them "live". You could also try to avoid using the host CPU model for your VMs as a workaround like reported earlier in this thread.
Click to expand...
I already don't use the "host" cpu model, otherwise i would see the full cpu name in windows:

1762882251278.png
1762882446690.png
Alright journalctl -f setup done, since i got two servers i connected the other stable as you said to the unstable one and ran the command in a tmux session so i can exit without killing it, we'll see the result, i hope it comes to a fix/patch
 
Last edited:
Darky said:
ran the command in a tmux session so i can exit without killing it
Click to expand...
Just to be sure, the tmux session is on the stable server?
 
Given the logs you posted, I would start by removing docker from that host (it's not officially supported) and not exposing critical services like ssh to the internet. You also mention "VNC", which makes me think maybe you installed PVE on top of Debian and might be using a desktop enviroment. In other words: looks like your setup isn't 100% standard PVE and something else might be triggering your issues as you have more moving parts than a standard PVE setup.
 
VictorSTS said:
Given the logs you posted, I would start by removing docker from that host (it's not officially supported) and not exposing critical services like ssh to the internet. You also mention "VNC", which makes me think maybe you installed PVE on top of Debian and might be using a desktop enviroment. In other words: looks like your setup isn't 100% standard PVE and something else might be triggering your issues as you have more moving parts than a standard PVE setup.
Click to expand...

I would start by removing docker from that host
Click to expand...
I didn't even install docker in the PVE, so I don't know what that is doing here (why would i install docker on the PVE when it's the hosts that run things anyway), and it doesn't show up in the PVE terminal, so I don't know what this is related to1763200521959.png

not exposing critical services like ssh to the internet
Click to expand...
it's this or i cannot access the remote server, it's not using a simple password anyway it's a keyed setup

You also mention "VNC", which makes me think maybe you installed PVE on top of Debian and might be using a desktop enviroment. In other words: looks like your setup isn't 100% standard PVE and something else might be triggering your issues as you have more moving parts than a standard PVE setup.
Click to expand...

VNC to access the remote machine bootloader, early boot sequence and its bios, there is absolutely not a single DE on this host it's all terminal so VNC is just for debugging and troubleshoot purposes for when things don't boot right, It is a 100% standard PVE 9 setup, how i know, you may ask ? Well because i using the newest (when i added it at least) PVE ISO file to install proxmox on this remote server
 
Last edited:
You must log in or register to reply here.
Top Bottom