VMs mit mehr als 2 GB RAM starten nicht durch - PVE läuft nested auf Hyper-V

B

Bob.Dig

Active Member
Sep 12, 2023
176
30
33
addicted to GUI
Code: 
proxmox-ve: 9.2.0 (running kernel: 7.0.12-1-pve)
pve-manager: 9.2.3 (running version: 9.2.3/d0fde103346cf89a)
proxmox-kernel-helper: 9.2.0
proxmox-kernel-7.0: 7.0.12-1
proxmox-kernel-7.0.12-1-pve-signed: 7.0.12-1
amd64-microcode: 3.20251202.1~bpo13+1
ceph-fuse: 19.2.3-pve2
corosync: 3.1.10-pve2
criu: 4.1.1-1
frr-pythontools: 10.6.1-1+pve2
ifupdown2: 3.3.0-1+pmx12
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.1
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.1
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.6
libpve-cluster-perl: 9.1.6
libpve-common-perl: 9.1.16
libpve-guest-common-perl: 6.0.4
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.6
libpve-notify-perl: 9.1.6
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.6
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-1
proxmox-backup-client: 4.2.2-1
proxmox-backup-file-restore: 4.2.2-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.3
proxmox-kernel-helper: 9.2.0
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.4
proxmox-widget-toolkit: 5.2.5
pve-cluster: 9.1.6
pve-container: 6.1.10
pve-docs: 9.2.2
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.18-4
pve-ha-manager: 5.2.4
pve-i18n: 3.8.0
pve-qemu-kvm: 11.0.0-4
pve-xtermjs: 6.0.0-1
qemu-server: 9.1.17
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.8.0+pve3
vncterm: 1.9.2
zfsutils-linux: 2.4.2-pve1
Habe aktuell das Problem, dass mein PVE wohl keine VMs mehr mit mehr als 2 GB RAM starten kann. Mir ist das erst vor kurzem aufgefallen, da ich zuletzt nur noch LXCs genutzt habe. Mit denen gibt es das Problem nicht. Hat jemand eine Idee, was dahinterstecken könnte?
Code: 
Jun 27 11:53:01 pve pvedaemon[14772]: VM 451 started with PID 14783.
Jun 27 11:53:01 pve pvedaemon[1744]: <root@pam> end task UPID:pve:000039B4:00005DA4:6A3F9D7C:qmstart:451:root@pam: OK
Jun 27 11:53:07 pve QEMU[14783]: KVM: entry failed, hardware error 0xffffffffffffffff
Jun 27 11:53:07 pve QEMU[14783]: EAX=00000000 EBX=bc003d28 ECX=000000b2 EDX=000000b2
Jun 27 11:53:07 pve QEMU[14783]: ESI=00000000 EDI=00000058 EBP=bc003c90 ESP=bc003c68
Jun 27 11:53:07 pve QEMU[14783]: EIP=00008000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=1 HLT=0
Jun 27 11:53:07 pve QEMU[14783]: ES =0000 00000000 ffffffff 00809300
Jun 27 11:53:07 pve QEMU[14783]: CS =f900 7bff9000 ffffffff 00809300
Jun 27 11:53:07 pve kernel: kvm_amd: set kvm_amd.dump_invalid_vmcb=1 to dump internal KVM state.
Jun 27 11:53:07 pve QEMU[14783]: SS =0000 00000000 ffffffff 00809300
Jun 27 11:53:07 pve QEMU[14783]: DS =0000 00000000 ffffffff 00809300
Jun 27 11:53:07 pve QEMU[14783]: FS =0000 00000000 ffffffff 00809300
Jun 27 11:53:07 pve QEMU[14783]: GS =0000 00000000 ffffffff 00809300
Jun 27 11:53:07 pve QEMU[14783]: LDT=0000 00000000 00000000 00000000
Jun 27 11:53:07 pve QEMU[14783]: TR =0040 691ca000 00004087 00008b00
Jun 27 11:53:07 pve QEMU[14783]: GDT=     691c8000 0000007f
Jun 27 11:53:07 pve QEMU[14783]: IDT=     00000000 00000000
Jun 27 11:53:07 pve QEMU[14783]: CR0=00050032 CR2=bea01000 CR3=0012d000 CR4=00000000
Jun 27 11:53:07 pve QEMU[14783]: DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
Jun 27 11:53:07 pve QEMU[14783]: DR6=00000000ffff0ff0 DR7=0000000000000400
Jun 27 11:53:07 pve QEMU[14783]: EFER=0000000000000000
Jun 27 11:53:07 pve QEMU[14783]: Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <bb> 4d 80 2e a1 38 fb 48 2e 89 07 2e 66 a1 30 fb 2e 66 89 47 02 2e 66 0f 01 17 b8 08 00 2e
Es gibt bei mir auch ein paar Besonderheiten. So läuft PVE nested auf einem Hyper-V. Außerdem ist auf dem PVE-Host auch PBS, PDM und zfsnas-chezmoi installiert.

Mit 2 GB RAM laufen VMs dagegen ohne Probleme:
Screenshot 2026-06-30 at 13-53-30 pve - Proxmox Virtual Environment.png
Der RAM selbst wurde geprüft und hat keine Fehler. Das Ändern des CPU-Types für die VM ändert nichts. Zwei andere zu Testzwecken aufgesetzte VMs zeigten das gleiche, problematische Verhalten.
 
Last edited:
Ich würde mir folgendes ansehen
Bash: 
lscpu
free -h
cat /proc/cmdline
journalctl -b0 -g "svm|kvm|virt|vt"
qm config VMIDHIER
Kannst du auch ein bisschen Info zur Hardware geben?
 
Hmm. PVE selbst scheint als virtuelle Maschine unter Windows zu laufen. Ich habe mit Hyper-V wenig Erfahrung. Wieso dieses Setup?
 
  • Like
Reactions: micneu and ThoSo
Impact said:
Hmm. PVE selbst scheint als virtuelle Maschine unter Windows zu laufen. Ich habe mit Hyper-V wenig Erfahrung. Wieso dieses Setup?
Click to expand...
Sehe ich auch so. Fehler steht ja schon in dmesg drin:

Code: 
Jun 30 13:39:33 pve QEMU[64897]: KVM: entry failed, hardware error 0xffffffffffffffff
Jun 30 13:41:15 pve kernel: kvm: kvm [68075]: vcpu0, guest rIP: 0xffffffff8388840f Unhandled WRMSR(0xc0010007) = 0xffff

Somit wie viele Supporter immer fordern: nachstellen auf "richtiger" Hardware.
 
  • Like
Reactions: micneu, ThoSo and Johannes S
Wie in aller Welt kommt man darauf, PVE nested zu betreiben?
in solchen Fällen, die ich meide wie der Teufel das Weihwasser, suche ich zuerst im System, welches die "Hardware" zur Verfügung stellt.
 
Last edited:
  • Like
Reactions: micneu and Johannes S
Das "lief früher, jetzt nicht mehr" ist eigentlich der spannende Teil. Check mal auf dem Windows-Host, ob Core Isolation / Speicherintegrität (VBS) an ist. Die 24H2/25H2-Updates knipsen das gern von selbst an, und sobald Windows den Hypervisor über VBS übernimmt, wird die nested AMD-V für deine PVE-VM unzuverlässig bis kaputt. Das passt perfekt zu deinem "plötzlich geht's nicht mehr".

Ab >2 GB kippt's, riecht aber nach nested SLAT/EPT beim SMM-Init (im Dump steht ja SMM=1).

Nested PVE auf Hyper-V bleibt Gebastel, egal was du drehst. Wenn's was Ernstes werden soll, nimm echtes Blech, dann ist der Zirkus weg.
 
  • Like
Reactions: Johannes S, Bob.Dig, micneu and 1 other person
TErxleben said:
Wie in aller Welt kommt man darauf, PVE nested zu betreiben?
in solchen Fällen, die ich meide wie der Teufel das Weihwasser, suche ich zuerst im System, welches die "Hardware" zur Verfügung stellt.
Click to expand...
PVE nested in PVE funktioniert sehr gut. Beispielsweise, wenn du einen Cluster mit vielen Nodes simulieren willst und nur eine dicke Maschine hast. Übrigens i. d. R. auch was bei Webinaren und Schulungen zu PVE gemacht wird schon alleine um Hardware zu sparen.
 
  • Like
Reactions: Johannes S, ThoSo and Bu66as
Bob.Dig said:
Hat keinen Einfluss, gerade getestet. Nutze hier übrigens Win Server25.
Click to expand...
Mich würde interessieren, warum du dein Setup genau so gewählt hast: Also Proxmox VE als VM auf einem Windows Server mit Hyper‑V.
Gibt es einen bestimmten Grund, warum die VMs, die aktuell unter PVE laufen, nicht direkt auf Hyper‑V betrieben werden, obwohl Hyper‑V das ja grundsätzlich auch kann?
Auf diese Frage aus meinem ersten Beitrag bist du bisher noch nicht eingegangen - könntest du das bitte noch kurz erläutern?

PS: Was sagt der Windoof Support zu dem Problem?
 
Last edited:
  • Like
Reactions: Johannes S
Ok, dann ist VBS raus als Ursache, gut zu wissen. Bleibt der SMM-Verdacht, im Dump kippt's ja genau bei SMM=1. Probier testweise eine VM mit SeaBIOS statt OVMF (Maschinentyp i440fx statt q35) und schau ob die mit 4-8 GB durchbootet. Dann weißt du, ob's wirklich das nested SMM/SLAT-Gefrickel unter Hyper-V ist oder an deinem PVE liegt. Interessant wäre auch, ob's exakt bei >2 GB kippt oder ob die Grenze anders liegt wenn du in 512-MB-Schritten hochtastest.
 
Bu66as said:
probier testweise eine VM mit SeaBIOS statt OVMF (Maschinentyp i440fx statt q35)
Click to expand...
Hab mal i440fx und q35 und SeaBIOS und OVMF getestet, jeweils mit einer einfachen Debian 13 VM. Alle liefen...
D.h. es ist wohl komplizierter. Ich hatte neben HomeAssistant noch eine andere VM getestet, die auch betroffen war. Leider fällt mir nicht mehr ein, was es gewesen ist.
Was auch immer es ist, denke, MS muss das in seiner Hyper-V Integration für Linux fixen.
Die Grenze ist übrigens nicht genau bei 2048 MB, aber auch nicht erheblich darüber.
 
Last edited:
Der Screenshot zeigt's: die betroffene VM ist 451 (haos), genau die aus dem ersten Log. Post #15 ist neu und ändert was. Die BIOS/Maschinentyp-Theorie aus #14 wurde getestet und eine simple Debian läuft in allen Kombis. Das ist ne neue Situation (VM-spezifisch statt RAM-Deckel).

Dass ne simple Debian in allen vier Kombis (i440fx/q35, SeaBIOS/OVMF) mit mehr RAM sauber durchläuft ist eigentlich die beste Info bisher. Damit ist der generelle "nested frisst kein >2GB"-Verdacht vom Tisch, klingt jetzt nach einer Eigenheit der betroffenen VM und nicht nach nem RAM-Deckel.

Die 451 aus deinem Log ist doch die haos? Post mal qm config 451 und daneben die config der Debian die läuft, irgendein Detail unterscheidet die zwei (ballooning, machine-Version gepinnt, extra args, cpu-flags, hostpci...). Da würd ich ansetzen bevor's an MS geht. Wenn ne 08/15-Debian mit 8GB durchbootet, ist die Hyper-V-Schicht ja nicht grundsätzlich im Eimer, dann liegt das Problem ziemlich sicher an nem bestimmten Config-Bit.
 
Bu66as said:
Die 451 aus deinem Log ist doch die haos
Click to expand...
Die andere VM war wie gesagt etwas anderes und auch betroffen. Ballooning etc. wurde schon von mir getestet, daran liegt es nicht. Und da diese VMs auf PVE ohne Hyper-V laufen, ist es vermutlich ein MS Problem. Für mich ist die Sache damit erst mal durch. Ich werde ab und an testen, ob sich was getan hat. Auch kann es sein, dass ich Hyper-V komplett aufgebe, MS macht mir insb. im Client OS immer mehr Probleme und wenn ich das wechsel, brauch ich auch keinen WinServer mehr. :cool:
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back