GPU durchreichen ab 128GB Ram Troubles

[OSF]

Hallo Miteinander,

habe erfolgreich meine Nvidia P4000 Karte durchgereicht.
Alles funktioniert perfekt, leider startet die VM nicht mehr sobald ich mehr als 128GB Ram zuweise.
Hat jemand eine Idee?

mfg
OSF

 

[dcsapak]

was genau heißt nicht starten? (zb Fehlermeldung, crash, etc.)

wie sieht die vm config genau aus und was ist der output von pveversion -v ?

 

[OSF]

Hallo Dominik,

root@srvhyp6:/var/log# pveversion -v
proxmox-ve: 5.3-1 (running kernel: 4.15.18-9-pve)
pve-manager: 5.3-5 (running version: 5.3-5/97ae681d)
pve-kernel-4.15: 5.2-12
pve-kernel-4.15.18-9-pve: 4.15.18-30
pve-kernel-4.15.18-4-pve: 4.15.18-23
pve-kernel-4.15.18-1-pve: 4.15.18-19
pve-kernel-4.15.17-1-pve: 4.15.17-9
corosync: 2.4.4-pve1
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.1-3
libpve-apiclient-perl: 2.0-5
libpve-common-perl: 5.0-43
libpve-guest-common-perl: 2.0-18
libpve-http-server-perl: 2.0-11
libpve-storage-perl: 5.0-33
libqb0: 1.0.3-1~bpo9
lvm2: 2.02.168-pve6
lxc-pve: 3.0.2+pve1-5
lxcfs: 3.0.2-2
novnc-pve: 1.0.0-2
proxmox-widget-toolkit: 1.0-22
pve-cluster: 5.0-31
pve-container: 2.0-31
pve-docs: 5.3-1
pve-edk2-firmware: 1.20181023-1
pve-firewall: 3.0-16
pve-firmware: 2.0-6
pve-ha-manager: 2.0-5
pve-i18n: 1.0-9
pve-libspice-server1: 0.14.1-1
pve-qemu-kvm: 2.12.1-1
pve-xtermjs: 1.0-5
qemu-server: 5.0-43
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.12-pve1~bpo1

die VM:
agent: 1,fstrim_cloned_disks=1
bios: ovmf
boot: cdn
bootdisk: scsi0
cores: 14
efidisk0: local-lvm:vm-104-disk-4,size=4M
hostpci0: af:00,pcie=1,x-vga=on
ide2: none,media=cdrom
machine: q35
memory: 256000
name: SRVCAD2
net0: virtio=6A:4D:6A:5A:27:3F,bridge=vmbr0
numa: 0
ostype: win10
scsi0: local-lvm:vm-104-disk-3,size=750G
scsihw: virtio-scsi-pci
smbios1: uuid=a17a027e-07d6-4c90-9c06-8fa4b0d927dc
sockets: 2
vga: std

start VM:
UPID:srvhyp6:000015DD:000BA88A:5C127AFE:qmstart:100:root@pam: 1 5C127B1C start failed: command '/usr/bin/kvm -id 100 -name testvm -chardev 'socket,id=qmp,path=/var/run/qemu-server/100.qmp,server,nowait' -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=6f6f8e8c-41ac-4427-ba05-74e6d266925f' -smp '28,sockets=2,cores=14,maxcpus=28' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' -vnc unix:/var/run/qemu-server/100.vnc,x509,password -no-hpet -cpu qemu64 -m 148000 -device 'vmgenid,guid=d75448e8-4780-464f-86ad-80c3e0880d71' -readconfig /usr/share/qemu-server/pve-q35.cfg -device 'usb-tablet,id=tablet,bus=ehci.0,port=1' -device 'vfio-pci,host=af:00.0,id=hostpci0,bus=ich9-pcie-port-1,addr=0x0,rombar=0,romfile=/usr/share/kvm/undefined' -device 'VGA,id=vga,bus=pcie.0,addr=0x1' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:27b43cbcccb' -drive 'file=/var/lib/vz/template/iso/virtio-win-0.1.160.iso,if=none,id=drive-ide0,media=cdrom,aio=threads' -device 'ide-cd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=100' -drive 'file=/var/lib/vz/template/iso/SW_DVD9_Win_Svr_STD_Core_and_DataCtr_Core_2016_64Bit_German_-2_MLF_X21-22827.ISO,if=none,id=drive-ide2,media=cdrom,aio=threads' -device 'ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=101' -device 'virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5' -drive 'file=/dev/pve/vm-100-disk-0,if=none,id=drive-scsi0,format=raw,cache=none,aio=native,detect-zeroes=on' -device 'scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=200' -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=2A:43:CE:FE:051,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300' -rtc 'driftfix=slew,base=localtime' -machine 'accel=tcg,type=q35' -global 'kvm-pit.lost_tick_policy=discard'' failed: got timeout

Danke für Deine Bemühungen

OSF

 

[dcsapak]

was möglich wäre ist mit 'qm showcmd ID --pretty' die qemu commandline auszugeben und mal zu starten und zu sehen ob er überhaupt startet und wenn ja wielang er braucht

wir haben beim starten ein 10 sekunden timeout, vielleicht müssen wir das für pci passthrough / viel memory erhöhen

funktionierts ohne pci passthrough denn ?

 

[OSF]

Ohne pci passthrough startet die VM tadellos.

qm showcmd 902 --pretty
/usr/bin/kvm \
-id 902 \
-name SRVCAD2 \
-chardev 'socket,id=qmp,path=/var/run/qemu-server/902.qmp,server,nowait' \
-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/902.pid \
-daemonize \
-smbios 'type=1,uuid=a17a027e-07d6-4c90-9c06-8fa4b0d927dc' \
-drive 'if=pflash,unit=0,format=raw,readonly,file=/usr/share/pve-edk2-firmware//OVMF_CODE.fd' \
-drive 'if=pflash,unit=1,format=raw,id=drive-efidisk0,file=/dev/pve/vm-902-disk-0' \
-smp '4,sockets=1,cores=4,maxcpus=4' \
-nodefaults \
-boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' \
-vnc unix:/var/run/qemu-server/902.vnc,x509,password \
-no-hpet \
-cpu 'host,+kvm_pv_unhalt,+kvm_pv_eoi,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,hv_synic,hv_stimer,kvm=off' \
-m 150000 \
-object 'memory-backend-ram,id=ram-node0,size=150000M' \
-numa 'node,nodeid=0,cpus=0-3,memdev=ram-node0' \
-readconfig /usr/share/qemu-server/pve-q35.cfg \
-device 'usb-tablet,id=tablet,bus=ehci.0,port=1' \
-device 'vfio-pci,host=af:00.0,id=hostpci0,bus=ich9-pcie-port-1,addr=0x0,rombar=0,romfile=/usr/share/kvm/undefined' \
-device 'VGA,id=vga,bus=pcie.0,addr=0x1' \
-iscsi 'initiator-name=iqn.1993-08.org.debian:01:27b43cbcccb' \
-drive 'if=none,id=drive-ide2,media=cdrom,aio=threads' \
-device 'ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200' \
-device 'virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5' \
-drive 'file=/dev/pve/vm-104-disk-3,if=none,id=drive-scsi0,format=raw,cache=none,aio=native,detect-zeroes=on' \
-device 'scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100' \
-netdev 'type=tap,id=net0,ifname=tap902i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' \
-device 'virtio-net-pci,mac=6A:4D:6A:5A:27:3F,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300' \
-rtc 'driftfix=slew,base=localtime' \
-machine 'type=q35' \
-global 'kvm-pit.lost_tick_policy=discard'

Gruß
OSF

 

[dcsapak]

startet der befehl so wenn man direkt auf der command line eingibt? und wielange bis sich der prozess in den hintergrund verschoben hat? (10s? 20s? > 2 min?)

 

[OSF]

die Maschine startet auf der Kommandozeile mit 150GB Ram
mit 650 GB hängt die VM jetzt schon einige Minuten......

 

[OSF]

hängt noch immer ......

 

[dcsapak]

mhm... okay dann ist es nicht nur ein fall für ein längeres timeout

vielleicht wären hugepages ein option? (man qm)

 

[OSF]

also mit "hugepages: any" schaffen wir 350GB.....
700GB wäre der Wunsch
LG
OSF

 

[dcsapak]

also mit "hugepages: any" schaffen wir 350GB.....

mit normalem 'qm start' oder mit qemu commandline von hand starten?
wenn ersteres, dann wäre es interessant wie lange es tatsächlich dauert wenn kein timeout angewandt wird.

auch helfen könnte noch ballon ausschalten (balloon: 0)
oder zu versuchen den host neustarten und diese vm als erstes zu starten (damit gestartet wird wenn der RAM so wenig fragmentiert ist wie nur möglich)

 

[OSF]

Guten Morgen,
hab noch etwas herumgespielt, über die 350GB komme ich leider nicht :-(
Auch mit qm start hängt die VM und startet nicht.
Noch jemand eine Idee?

Grüße
OSF

 

[dcsapak]

hmm... werden eigentlich 1gb oder 2mb hugepages verwendet?
man kann auch die hugepages beim booten reservieren e.g. in /etc/default/grub folgendes zur commandline hinzufügen (zitat von unserer mailing liste)

1GB hugepages can be allocated at boot if user want it.
hugepages need to be contiguous, so sometime it's not possible to reserve them on the fly

/etc/default/grub : GRUB_CMDLINE_LINUX_DEFAULT="quiet hugepagesz=1G hugepages=x"

danach update-grub nicht vergessen

 

[xiaolin0199]

You try numa to change to 1, add hugepages=2, then try again