TrueNAS und Proxmox > VM startet nicht

[gio2022]

Hallo Fabian,
die Logs waren die von der Host. Als Anhang die von der VM.

Ja, dass kann ich. Aber was passiert mit dem andere HBA? der wo gerade alle meine Backup stehen. . . ?
Ich habe zwei Broadcom Controller.
Ich kenne mich nicht so gut damit aus, deswegen frage ich lieber zwei mal.

echo "blacklist mpt3sas" >> /etc/modprobe.d/blacklist.conf

Vielen Dank

 

[fabian]

ah, sorry, das hatte ich nicht parat! kannst du vielleicht noch lspci -v hinzufuegen?

 

[gio2022]

Hallo Fabian,
hier als Attachment
Merci

 

[fabian]

okay, also blacklisten in dem fall keine gute idee, weil beide verwenden denselben treiber

kurz zusammengefasst:

- 2 HBAs, einmal auf 02:00.0, einmal auf 84:00.0
- 84:00.0 wird durchgereicht
- wenn du die VM startest, verliert der host nicht nur das durchgereichte HBA sondern beide (bzw. die disks die jeweils draenhaengen)?

 

[gio2022]

Hallo Fabian,
ne Gott sei Dank ich behalte die Platte auch wenn ich die VM starte.
Aber die VM bekommt keine Platte. Truenas sieht nur eine kleine 128GB Platte...

 

[fabian]

kannst dus mal mit einer Debian livecd als boot medium der VM probieren und von dort boot log und "lspci -v" output posten?

 

[gio2022]

ja, mache ich es. Sobald ich das PCI Controller einbinden, versucht die Maschine darauf zu booten. Auch die Debian livecd. Ich warte jetzt bis ich dann sagen kann: weiter...
Kann ich etwas machen, um das zu verhindern?

 

[gio2022]

Hallo Fabian, das ist die ausgabe.
Mit fdisk-l sehe ich alle meine 44 PLatten

 

[fabian]

okay, also unter debian funktoniert der passthrough wie erwartet? dann liegt es wohl an truenas selbst.. welche version verwendest du denn? core/enterprise oder scale?

 

[gio2022]

scale, letzte Version.
Das beste ist, dass wir bevor die erste VM verschwand ein Pool eingerichtet hatten. Die ZFS ist noch da...

 

[fabian]

was meinst du mit "die zfs ist noch da"? wenn der zpool import worden ist, muessen ja die disks auch da sein?

 

[gio2022]

ich sehe es aus fdisk.
Importierten kann in nicht mit zfs-fuse :-(

ich versuche die Platten aus ZFS zu befreien. Vielleich ist das der Grund TrueNas sie nicht sieht... obwohl TrueNas diese Tank erzeuugt hat.

Was kann ich machen, damit die VM nicht aus der PCI booten versucht?

 

[gio2022]

von der Debian VM konnte ich sogar den pool importieren.

 

[gio2022]

Hallo Fabian,
also ich würde jetzt die Truenas VM noch mal installieren.
Mir würden zwei punkte helfen.
Wie verhindere ich, dass die VM aus der controller booten will?
Wie sorge ich dafür, dass die VM den Startup timeout in der Config bekomme?

 

[fabian]

die VM sollte die bootorder respektieren die du in der config gesetzt hast - hier steht meist die disk vor dem CD laufwerk (was truenas dann in weiterer folge nach der installation als bootloader installiert und was der tut kann PVE nicht kontrollieren ). du kannst aber in der konsole direkt nach dem start mit Escape auch einmal einen boot override machen (so wie bei einer bare metal maschine auch).

der timeout ist in der config (noch) nicht setzbar - sh. https://bugzilla.proxmox.com/show_bug.cgi?id=3502 , aber beim start selbst schon ("qm start XXX --timeout YYY")

 

[gio2022]

Morgen Fabian,
es sieht so aus, als ob mene Maschine die Konfig ignorieren würde.

Das ist meine Cofig.
agent: 1
balloon: 0
boot: order=scsi0;net0
cores: 6
memory: 145000
meta: creation-qemu=7.2.0,ctime=1688980023
name: truenasscale
net0: virtio=c2:4f:69:21:14:15,bridge=vmbr0
numa: 0
ostype: l26
scsi0: local-lvm:vm-100-disk-0,iothread=1,size=64G
scsihw: virtio-scsi-single
hostpci0: 0000:84:00
smbios1: uuid=40d8dd69-1400-45a2-8d27-80f40c00dd64
sockets: 2
tags:
vmgenid: 76e33ecd-4ea2-4b3c-b2a2-15a673b2d769


qm start 100 --timeout 140

jul 18 09:09:41 hotstandby pvestatd[15875]: status update time (8.626 seconds)
Jul 18 09:09:42 hotstandby qm[561818]: start failed: command '/usr/bin/kvm -id 100 -name 'truenasscale,debug-threads=on' -no-shutdown -chardev 'socket,id=qmp,path=/var/run/qemu-server/100.qmp,server=on,wait=off' -mon 'chardev=qmp,mode=control' -chardev 'socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5' -mon 'chardev=qmp-event,mode=control' -pidfile /var/run/qemu-server/100.pid -daemonize -smbios 'type=1,uuid=40d8dd69-1400-45a2-8d27-80f40c00dd64' -smp '12,sockets=2,cores=6,maxcpus=12' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' -vnc 'unix:/var/run/qemu-server/100.vnc,password=on' -cpu kvm64,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+lahf_lm,+sep -m 145000 -object 'iothread,id=iothread-virtioscsi0' -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e' -device 'pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f' -device 'pci-bridge,id=pci.3,chassis_nr=3,bus=pci.0,addr=0x5' -device 'vmgenid,guid=76e33ecd-4ea2-4b3c-b2a2-15a673b2d769' -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' -device 'usb-tablet,id=tablet,bus=uhci.0,port=1' -device 'vfio-pci,host=0000:84:00.0,id=hostpci0,bus=pci.0,addr=0x10' -device 'VGA,id=vga,bus=pci.0,addr=0x2' -chardev 'socket,path=/var/run/qemu-server/100.qga,server=on,wait=off,id=qga0' -device 'virtio-serial,id=qga0,bus=pci.0,addr=0x8' -device 'virtserialport,chardev=qga0,name=org.qemu.guest_agent.0' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:d9ed19d296b' -device 'virtio-scsi-pci,id=virtioscsi0,bus=pci.3,addr=0x1,iothread=iothread-virtioscsi0' -drive 'file=/dev/pve/vm-100-disk-0,if=none,id=drive-scsi0,format=raw,cache=none,aio=io_uring,detect-zeroes=on' -device 'scsi-hd,bus=virtioscsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100' -netdev 'type=tap,id=net0,ifname=tap100i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' -device 'virtio-net-pci,mac=c2:4f:69:21:14:15,netdev=net0,bus=pci.0,addr=0x12,id=net0,rx_queue_size=1024,tx_queue_size=1024,bootindex=101' -machine 'type=pc+pve0'' failed: got timeout

 

[fabian]

was genau meinst du? der timeout ist vielleicht nicht hoch genug? passthrough ist ja immer noch aktiv..

 

[gio2022]

Habe Dich falsch verstanden, dass der Timeout kann maximal den Anzahl der RAM in GB der VM?

 

[fabian]

nein. der timeout ist wenn nicht explizit angegeben mind. 30s, wenn die VM mehr als 30GB RAM hat dann die RAM Groesse. ein manueller timeout kann nochmal hoeher sein (genau fuer solche faelle wie pass through wo die initialisierung moeglicherweise lange dauert)

 

[gio2022]

Danake! Jetzt habe ich verstanden und mit 1000 bekomme ich die VM hoch. Leider stimmt trotz richtige config (meine ich). Die boot reienfolge nicht