Proxmox Host startet zufällig einfach neu

nevakee

Renowned Member
Nov 15, 2015
11
4
68
Hallo,

seit November letztes Jahr habe ich das Problem, dass ein Host einfach zufällig neustartet bzw. abstürtzt.
In den Logs ist nichts zu sehen, als ob einer einfach den Reset Knopf drückt.

Code:
~ # pveversion -v
proxmox-ve: 8.1.0 (running kernel: 6.5.11-8-pve)
pve-manager: 8.1.4 (running version: 8.1.4/ec5affc9e41f1d79)
proxmox-kernel-helper: 8.1.0
pve-kernel-6.2: 8.0.5
proxmox-kernel-6.5: 6.5.11-8
proxmox-kernel-6.5.11-8-pve-signed: 6.5.11-8
proxmox-kernel-6.5.11-7-pve-signed: 6.5.11-7
proxmox-kernel-6.2.16-20-pve: 6.2.16-20
proxmox-kernel-6.2: 6.2.16-20
pve-kernel-6.2.16-3-pve: 6.2.16-3
ceph-fuse: 17.2.6-pve1+3
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx8
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-4
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.0
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.3
libpve-access-control: 8.1.1
libpve-apiclient-perl: 3.3.1
libpve-common-perl: 8.1.0
libpve-guest-common-perl: 5.0.6
libpve-http-server-perl: 5.0.5
libpve-network-perl: 0.9.5
libpve-rs-perl: 0.8.8
libpve-storage-perl: 8.0.5
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 5.0.2-4
lxcfs: 5.0.3-pve4
novnc-pve: 1.4.0-3
proxmox-backup-client: 3.1.4-1
proxmox-backup-file-restore: 3.1.4-1
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.2.3
proxmox-mini-journalreader: 1.4.0
proxmox-widget-toolkit: 4.1.3
pve-cluster: 8.0.5
pve-container: 5.0.8
pve-docs: 8.1.3
pve-edk2-firmware: 4.2023.08-3
pve-firewall: 5.0.3
pve-firmware: 3.9-1
pve-ha-manager: 4.0.3
pve-i18n: 3.2.0
pve-qemu-kvm: 8.1.5-2
pve-xtermjs: 5.3.0-3
qemu-server: 8.0.10
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.2-pve1

Ich habe die Vermutung, dass die Abstürtzt mit einer neuen VM zusammen hängen, die ich Mitte Oktober 2023 installiert habe.
Sobald die VM läuft, ist bis jetzt immer innerhalb von 2 Woche der Host abgestützt. Zwischendurch hatte ich die auch mal 1 Monat ausgeschaltet und hatte der Host ist nicht abgestürtzt.
Anfang letzter Woche habe ich die VM nach ca. 4 Wochen wieder gestartet und heute Morgen war es dann wieder soweit und der Host ist abgestürtzt.

Code:
agent: 1
balloon: 0
bios: ovmf
boot: order=scsi0;net0;ide0
cores: 6
cpu: host
efidisk0: data-nvme:vm-160-disk-0,efitype=4m,pre-enrolled-keys=1,size=1M
ide0: none,media=cdrom
localtime: 1
machine: pc-q35-8.1
memory: 12288
meta: creation-qemu=8.0.2,ctime=1697558041
name: vmname
net0: virtio=96:E7:E6:4A:76:D7,bridge=vmbr1,firewall=1
numa: 0
ostype: win11
scsi0: data-nvme:vm-160-disk-1,cache=writeback,discard=on,iothread=1,mbps_rd=1500,mbps_wr=750,size=75G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=3dda622a-adbe-49af-99ec-5ef2aa804f2b
sockets: 1
startup: order=7
tags: LAN
tpmstate0: data-nvme:vm-160-disk-2,size=4M,version=v2.0
vcpus: 6
vga: virtio
vmgenid: 5a9ea4f8-c480-4715-9797-4aaa7062b625
vmstatestorage: data-nvme

Es handelt sich um eine Windows 11 VM. Die Besonderheit zu den anderen VMs ist, dass bei der VM die Festplatte per Bitlocker (TPM) verschlüsselt ist.
Eine andere VM (ebenfalls Windows 11 mit TPM, nur ohne Bitlocker) läuft seit Jahren problemlos.

Die ersten Monate hatte ich ballooning noch eingeschaltet, aber Anfang letzte Woche mal ausgeschaltet, um zu testen, ob es evtl. daran lag, aber scheinbar auch nicht.

Hat vielleicht einer eine Idee, was genau das Problem ist?
 
Ich stelle mal die Vermutung an, dass der OOM Killer zugeschlagen haben könnte.

Wie viel RAM hat deine Node und wie viel GB hast du all deine VMs zugewiesen? Nutzt du ZFS?
 
Der Node hat 128 GB, wovon 70 GB von den VMs belegt sind und 32 GB von ZFS. Also etwas über 100 GB von 128 GB.
10-30 Sekunden vor dem Abstürzt waren laut Monitoring noch 25 GB frei.
Bei dem OOM Killer würde ich aber eher vermuten, dass nur die VM dann abstürtzt, aber gleich der komplette Host?

CPU ist ein AMD Ryzen 9 7900 und ein Gigybyte MC13-LE1.
 
Last edited:
Ja, das Problem kenne ich von einem ähnlichen System hier, ein ASRock 470D4U + Ryzen + 128GB ECC-RAM.

Auffällig ist, dass es im Kernel-Log folgende Einträge gibt, wobei ich nicht sagen kann, ob das etwas mit dem Reboot zu tun hat:

[Wed Aug 30 13:18:28 2023] mce: [Hardware Error]: Machine check events logged
[Wed Aug 30 13:18:28 2023] [Hardware Error]: Corrected error, no action required.
[Wed Aug 30 13:18:28 2023] [Hardware Error]: CPU:1 (19:21:0) MC24_STATUS[-|CE|-|-|-|-|-|-|-]: 0x800000029f9a1163
[Wed Aug 30 13:18:28 2023] [Hardware Error]: IPID: 0x0000000000000000
[Wed Aug 30 13:18:28 2023] [Hardware Error]: Bank 24 is reserved.
[Wed Aug 30 13:18:28 2023] [Hardware Error]: cache level: L3/GEN, tx: INSN
[Sun Sep 3 07:19:21 2023] mce: [Hardware Error]: Machine check events logged
[Sun Sep 3 07:19:21 2023] [Hardware Error]: Corrected error, no action required.
  • Das Phänomen tritt auf der Kombination ASRock X470D2U + Ryzen 5000
  • Auf der Kombination X470D2U2-T2 + Ryzen 3000 tritt das Problem (vermutlich) nicht auf
Es kommt mir nicht unwahrscheinlich vor, dass es sporadisch zu "Uncorrectable Errors" kommt, was sich dann in dem Reboot äußert.

Die sporadischen Reboots treten auch auf einer Maschine auf, wo ein Terminalserver mit ca. 70GB RAM läuft. Es gibt da bei keine Logeinträge, nichts, die Maschine bootet einfach neu. Dies scheint auch Linux-Kernel-unabhängig zu sein, ein BIOS-Upgrade auf ein neues AGESA hat auch nichts gebracht.

Im Internet habe ich folgende Ressourcen gefunden:

https://community.amd.com/t5/proces...k-exception-asus-prime-x570/m-p/490684#M43631
https://forums.servethehome.com/ind...k-x470d4u-and-zen3-ryzen-5900x-support.32258/
https://www.computerbase.de/forum/threads/ryzen-und-random-reboots-freezes.2108138/
https://www.reddit.com/r/ASRock/comments/sqm7x1/where_is_pbo_on_x470d4u/

-> Bislang habe ich keine Lösung gefunden, aber die Reboots kommen zum Glück nur alle paar Wochen vor.

Es scheint sich leider wieder mal zu bewahrheiten, dass die AMD-Systeme instabiler sind als die Intel-Systeme.
 
Ich würde nicht pauschal auf AMD schimpfen, eventuell liegt es an der Kombination Ryzen+ECC RAM.
 
Code:
agent: 1
balloon: 0
bios: ovmf
boot: order=scsi0;net0;ide0
cores: 6
cpu: host
efidisk0: data-nvme:vm-160-disk-0,efitype=4m,pre-enrolled-keys=1,size=1M
ide0: none,media=cdrom
localtime: 1
machine: pc-q35-8.1
memory: 12288
meta: creation-qemu=8.0.2,ctime=1697558041
name: vmname
net0: virtio=96:E7:E6:4A:76:D7,bridge=vmbr1,firewall=1
numa: 0
ostype: win11
scsi0: data-nvme:vm-160-disk-1,cache=writeback,discard=on,iothread=1,mbps_rd=1500,mbps_wr=750,size=75G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=3dda622a-adbe-49af-99ec-5ef2aa804f2b
sockets: 1
startup: order=7
tags: LAN
tpmstate0: data-nvme:vm-160-disk-2,size=4M,version=v2.0
vcpus: 6
vga: virtio
vmgenid: 5a9ea4f8-c480-4715-9797-4aaa7062b625
vmstatestorage: data-nvme
Was mir eben beim noch einmal lesen auffällt. Du hast bei der VM Disk Limits gesetzt. Kannst du die mal entfernen.
 
Hab die Limits gerade entfernt. Gestern habe ich den CPU Typ testweise noch von Host auf x86-64-v2-AES gesetzt.
Mal abwarten, was in den nächsten 1-2 Wochen passiert...

Die config sieht jetzt so aus:
Code:
agent: 1
balloon: 0
bios: ovmf
boot: order=scsi0;ide0;net0
cores: 6
cpu: x86-64-v2-AES
efidisk0: data-nvme:vm-160-disk-0,efitype=4m,pre-enrolled-keys=1,size=1M
ide0: none,media=cdrom
machine: pc-q35-8.1
memory: 12288
meta: creation-qemu=8.0.2,ctime=1697558041
name: vmname
net0: virtio=96:E7:E6:4A:76:D7,bridge=vmbr1,firewall=1
numa: 0
ostype: win11
scsi0: data-nvme:vm-160-disk-1,cache=writeback,discard=on,iothread=1,size=75G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=3dda622a-adbe-49af-99ec-5ef2aa804f2b
sockets: 1
startup: order=7
tags: LAN
tpmstate0: data-nvme:vm-160-disk-2,size=4M,version=v2.0
vga: virtio

Code:
~ # pveversion -v
proxmox-ve: 8.2.0 (running kernel: 6.8.4-3-pve)
pve-manager: 8.2.2 (running version: 8.2.2/9355359cd7afbae4)
proxmox-kernel-helper: 8.1.0
pve-kernel-6.2: 8.0.5
proxmox-kernel-6.8: 6.8.4-3
proxmox-kernel-6.8.4-3-pve-signed: 6.8.4-3
proxmox-kernel-6.8.4-2-pve-signed: 6.8.4-2
proxmox-kernel-6.5.13-5-pve-signed: 6.5.13-5
proxmox-kernel-6.5: 6.5.13-5
proxmox-kernel-6.2.16-20-pve: 6.2.16-20
proxmox-kernel-6.2: 6.2.16-20
pve-kernel-6.2.16-3-pve: 6.2.16-3
ceph-fuse: 17.2.6-pve1+3
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx8
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-4
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.1
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.3
libpve-access-control: 8.1.4
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.0.6
libpve-cluster-perl: 8.0.6
libpve-common-perl: 8.2.1
libpve-guest-common-perl: 5.1.2
libpve-http-server-perl: 5.1.0
libpve-network-perl: 0.9.8
libpve-rs-perl: 0.8.8
libpve-storage-perl: 8.2.1
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.4.0-3
proxmox-backup-client: 3.2.3-1
proxmox-backup-file-restore: 3.2.3-1
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.2.3
proxmox-mini-journalreader: 1.4.0
proxmox-widget-toolkit: 4.2.3
pve-cluster: 8.0.6
pve-container: 5.1.10
pve-docs: 8.2.2
pve-edk2-firmware: 4.2023.08-4
pve-esxi-import-tools: 0.7.0
pve-firewall: 5.0.7
pve-firmware: 3.11-1
pve-ha-manager: 4.0.4
pve-i18n: 3.2.2
pve-qemu-kvm: 8.1.5-6
pve-xtermjs: 5.3.0-3
qemu-server: 8.2.1
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.3-pve2
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!