Bei Start einer VM mit HBA passthrough freezed Proxmox

M

macpret

New Member
Jan 30, 2021
6
0
1
43
Hallo,

ich bin neu in der Proxmox Welt und habe es nun installiert, um ein wenig ein Gefühl für Proxmox und die Möglichkeiten zu erhalten.
Habe ein paar LXC Container, sowie einige VM's erstellt - bis dato auch alles prima.

Nun habe ich in einer VM einen Sata-Controller per PCIe Passthrough durchgereicht und an diesen zwei 10TB Festplatten gehängt.
Sobald ich nun die VM mit angesteckten Festplatten starte friert das gesamte System ein und es hilft lediglich ein Neustart.
Wenn ich die Festplatten abklemme fährt die VM ohne Probleme hoch. Wenn ich dann im laufenden Betrieb die Festplatten anstecke funktioniert es wie es soll.

Hat jemand eine Idee woran es liegen kann?

Danke und Gruß
Björn
 
Ein ähnliches Problem tritt bei mir nach einem upgrade auf.
Bei mir funktioniert der passthrough nur bis Kernel 5.3.18-2.
An einer besseren Lösung wäre ich auch interessiert.
 
Ich habe nun einmal einen Kerneldowngrade auf 5.3.18-2 sowie 5.3.13-3 versucht - beides leider ohne Änderung des Problems.

Ich habe die zeitliche Komponente noch weiter eingeschränken können.
Mit der Option "CPU Freeze at startup" habe ich das System nach Start eingefroren. Bis dahin können die Festplatten angesteckt sein.
Dann kann ich die Festplatten abziehen, die VM bis ins SeaBIOS starten ("Esc" gedrückt), die Festplatten dann wieder anstecken und die VM normal starten.

Sobald ich zwischen dem CPU Freeze und dem BIOS die Festplatten angesteckt habe friert Proxmox ein.
Was passiert in Proxmox bis zum Abschluss des BIOS?
Hat jemand eine Idee?
 
Last edited:
ist vielleicht der treiber noch geladen ?

was sagt denn das syslog und dmesg?
 
ich habe im syslog nichts auffälliges gefunden - aber ich kann den Fehler gleich noch einmal provozieren. Worauf sollte ich denn dort achten? - auch bei der Ausgabe von dmesg?

Wie meinst du, dass vllt. der Treiber noch geladen ist?
 
macpret said:
Wie meinst du, dass vllt. der Treiber noch geladen ist?
Click to expand...
was ist denn der output von 'lspci -kvnn' ? am besten bevor die vm startet. da sieht man welcher kernel treiber geladen ist.
auch die komplette ausgabe von 'dmesg' wäre praktisch.

mein verdacht war, dass die disken bereits vom host genutzt werden (weil vllt. der treiber geladen ist) bevor die vm startet
(dh wenn keine disk steckt, geht das passthrough)
 
Hallo,

habe nun ein paar Versuche gemacht:
Ausgabe von lspci -kvnn, dies ist der Controller, an welchem die Festplatten hängen:

Code: 
03:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 02) (prog-if 01 [AHCI 1.0])
        Subsystem: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:1060]
        Flags: bus master, fast devsel, latency 0, IRQ 135
        I/O ports at 3050 [size=8]
        I/O ports at 3040 [size=4]
        I/O ports at 3030 [size=8]
        I/O ports at 3020 [size=4]
        I/O ports at 3000 [size=32]
        Memory at b1010000 (32-bit, non-prefetchable) [size=512]
        Expansion ROM at b1000000 [disabled] [size=64K]
        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [78] Power Management version 3
        Capabilities: [80] Express Legacy Endpoint, MSI 00
        Capabilities: [100] Virtual Channel
        Kernel driver in use: ahci
        Kernel modules: ahci

dieses ändert sich auch nicht, wenn die VM mit dem Passthrough geladen ist.

der Output von dsmg ist im Angang.
 
Last edited:
ok das würde es erklären.

meine vermutung:

der controller treiber wird vom kernel geladen, dieser sieht und benutzt die disks
nun wird beim passthrough das pci device resettet und der kernel kennt sich nicht mehr aus...

man müsste wahrscheinlich dem kernel im initramfs sagen dass er vor dem 'ahci' treiber
das device an den 'vfio-pci' treiber binden soll

eine grobe anleitung dafür gibt es in der referenz doku: https://pve.proxmox.com/wiki/PCI(e)_Passthrough
es gibt auch schon einige threads wo das und ähnliche dinge besprochen werden, zb hier https://forum.proxmox.com/threads/pci-passthrough-selection-with-identical-devices.63042/
 
OK, also ich hatte die Anleitung zunächst anscheinend nicht vollständig gelesen.
Habe es nun nachgeholt und nach lspci hat dies auch funktioniert:

03:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 02) (prog-if 01 [AHCI 1.0]) Subsystem: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:1060] Flags: bus master, fast devsel, latency 0, IRQ 255 I/O ports at 3050 [size=8] I/O ports at 3040 [size=4] I/O ports at 3030 [size=8] I/O ports at 3020 [size=4] I/O ports at 3000 [size=32] Memory at b1010000 (32-bit, non-prefetchable) [size=512] Expansion ROM at b1000000 [disabled] [size=64K] Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit- Capabilities: [78] Power Management version 3 Capabilities: [80] Express Legacy Endpoint, MSI 00 Capabilities: [100] Virtual Channel Kernel driver in use: vfio-pci Kernel modules: ahci

Allerdings besteht das Problem weiterhin.

Absturz, solange sich eine Festplatte am Controller befindet zwischen "CPU Freeze at Startup" und BIOS start.

syslog:
Feb 3 19:52:26 SanPVE pvedaemon[1233]: <root@pam> starting task UPID:SanPVE:00000C84:000042A9:601AF0EA:qmstart:150:root@pam: Feb 3 19:52:26 SanPVE pvedaemon[3204]: start VM 150: UPID:SanPVE:00000C84:000042A9:601AF0EA:qmstart:150:root@pam: Feb 3 19:52:26 SanPVE systemd[1]: Created slice qemu.slice. Feb 3 19:52:26 SanPVE systemd[1]: Started 150.scope. Feb 3 19:52:26 SanPVE systemd-udevd[3214]: Using default interface naming scheme 'v240'. Feb 3 19:52:26 SanPVE systemd-udevd[3214]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Feb 3 19:52:26 SanPVE systemd-udevd[3214]: Could not generate persistent MAC address for tap150i0: No such file or directory Feb 3 19:52:26 SanPVE kernel: [ 170.886968] device tap150i0 entered promiscuous mode Feb 3 19:52:26 SanPVE systemd-udevd[3214]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Feb 3 19:52:26 SanPVE systemd-udevd[3214]: Could not generate persistent MAC address for fwbr150i0: No such file or directory Feb 3 19:52:26 SanPVE systemd-udevd[3211]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Feb 3 19:52:26 SanPVE systemd-udevd[3211]: Using default interface naming scheme 'v240'. Feb 3 19:52:26 SanPVE systemd-udevd[3211]: Could not generate persistent MAC address for fwpr150p0: No such file or directory Feb 3 19:52:26 SanPVE systemd-udevd[3217]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Feb 3 19:52:26 SanPVE systemd-udevd[3217]: Using default interface naming scheme 'v240'. Feb 3 19:52:26 SanPVE systemd-udevd[3217]: Could not generate persistent MAC address for fwln150i0: No such file or directory Feb 3 19:52:26 SanPVE kernel: [ 170.905042] fwbr150i0: port 1(fwln150i0) entered blocking state Feb 3 19:52:26 SanPVE kernel: [ 170.905043] fwbr150i0: port 1(fwln150i0) entered disabled state Feb 3 19:52:26 SanPVE kernel: [ 170.905079] device fwln150i0 entered promiscuous mode Feb 3 19:52:26 SanPVE kernel: [ 170.905127] fwbr150i0: port 1(fwln150i0) entered blocking state Feb 3 19:52:26 SanPVE kernel: [ 170.905128] fwbr150i0: port 1(fwln150i0) entered forwarding state Feb 3 19:52:26 SanPVE kernel: [ 170.907568] vmbr0: port 4(fwpr150p0) entered blocking state Feb 3 19:52:26 SanPVE kernel: [ 170.907569] vmbr0: port 4(fwpr150p0) entered disabled state Feb 3 19:52:26 SanPVE kernel: [ 170.907609] device fwpr150p0 entered promiscuous mode Feb 3 19:52:26 SanPVE kernel: [ 170.908102] vmbr0: port 4(fwpr150p0) entered blocking state Feb 3 19:52:26 SanPVE kernel: [ 170.908103] vmbr0: port 4(fwpr150p0) entered forwarding state Feb 3 19:52:26 SanPVE kernel: [ 170.937824] fwbr150i0: port 2(tap150i0) entered blocking state Feb 3 19:52:26 SanPVE kernel: [ 170.937825] fwbr150i0: port 2(tap150i0) entered disabled state Feb 3 19:52:26 SanPVE kernel: [ 170.937870] fwbr150i0: port 2(tap150i0) entered blocking state Feb 3 19:52:26 SanPVE kernel: [ 170.937871] fwbr150i0: port 2(tap150i0) entered forwarding state Feb 3 19:52:28 SanPVE pvedaemon[1233]: <root@pam> end task UPID:SanPVE:00000C84:000042A9:601AF0EA:qmstart:150:root@pam: OK Feb 3 19:52:31 SanPVE pvedaemon[1234]: VM 150 qmp command failed - VM 150 qmp command 'guest-ping' failed - got timeout ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@$
 

Attachments

Last edited:
mhmm.. im dmesg sieht man leider nicht viel...
wie sieht denn die vm config aus (qm config ID)?

nachdem keine fehler, warnungen, oÄ vorkommen, würde ich ein hardware problem vermuten...
 
aktuell wie folgt:

agent: 1 balloon: 2048 boot: order=scsi0 cores: 4 freeze: 1 hostpci0: 03:00,pcie=1 machine: q35 memory: 8192 name: OMV net0: virtio=C2:93:F8:62:3C:FA,bridge=vmbr0,firewall=1 numa: 0 ostype: l26 parent: OMV_20210130 scsi0: local-lvm:vm-150-disk-0,discard=on,size=20G,ssd=1 scsihw: virtio-scsi-pci smbios1: uuid=5c3eb7b1-8be1-4fb5-be49-ab64b63d24e9 sockets: 1 vmgenid: ba87e81b-3468-41f0-93cb-12e434edcc21 OMV_20210130] #30.01.2021 - Status%3A Fehler mit angesteckten Festplatten agent: 1,fstrim_cloned_disks=1 balloon: 2048 boot: order=scsi0;hostpci0 cores: 2 hostpci0: 03:00 memory: 4096 name: OMV net0: virtio=C2:93:F8:62:3C:FA,bridge=vmbr0,firewall=1 numa: 0 ostype: l26 protection: 1 scsi0: local-lvm:vm-150-disk-0,discard=on,size=20G,ssd=1 scsihw: virtio-scsi-pci smbios1: uuid=5c3eb7b1-8be1-4fb5-be49-ab64b63d24e9 snaptime: 1611961916 sockets: 1 vmgenid: ba87e81b-3468-41f0-93cb-12e434edcc21
 
You must log in or register to reply here.
Top Bottom