GPU durchreichen ab 128GB Ram Troubles

OSF

Active Member
Dec 14, 2018
22
1
43
59
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
 
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 ?
 
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:05:D1,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
 
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 ?
 
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
 
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?)
 
mhm... okay dann ist es nicht nur ein fall für ein längeres timeout

vielleicht wären hugepages ein option? (man qm)
 
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)
 
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
 
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
 

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!