[SOLVED] VM mit PCI Passthrough + 80GB Ram startet nicht.

[quanto11]

Hallo Zusammen,

folgendes Problem ist mir gestern aufgefallen.

Ich brauche für eine bestimmte VM in Zukunft mehr RAM, sodass ich die Ressourcen für diese angepasst habe. Diese VM hat zusätzlich eine PCI Karte per Passthrough durchgeschliffen bekommen, welche bisher immer einwandfrei funktioniert hat.

Als ich gestern die Ressourcen, genauer gesagt den RAM von 45GB auf 80GB gestellt habe, viel mir auf, das die VM sehr lange zum starten braucht. Nach 45 Sekunden zeigt Proxmox an, das die Maschine gestartet wurde, jedoch mit einem Fehler. Schaut man sich die Maschine an, funktioniert die Shell nicht und das Summary ist eingefroren, die Maschine reagiert nicht. Anbei der Fehler:

Spoiler: VM Start Fehler

/dev/rbd27
rbd: sysfs write failed
can't unmap rbd device /dev/rbd-pve/8f515fd6-628a-4a4b-bca7-ad03c981189d/XXXXX/vm-133-disk-2: rbd: sysfs write failed
rbd: sysfs write failed
can't unmap rbd device /dev/rbd-pve/8f515fd6-628a-4a4b-bca7-ad03c981189d/Storage/vm-133-disk-0: rbd: sysfs write failed
rbd: sysfs write failed
can't unmap rbd device /dev/rbd-pve/8f515fd6-628a-4a4b-bca7-ad03c981189d/Storage/vm-133-disk-1: rbd: sysfs write failed
rbd: sysfs write failed
can't unmap rbd device /dev/rbd-pve/8f515fd6-628a-4a4b-bca7-ad03c981189d/XXXXX/vm-133-disk-0: rbd: sysfs write failed
volume deactivation failed: XXXXX:vm-133-disk-2 Storage:vm-133-disk-0 Storage:vm-133-disk-1 XXXXX:vm-133-disk-0 at /usr/share/perl5/PVE/Storage.pm line 1234.
TASK ERROR: start failed: command '/usr/bin/kvm -id 133 -name 'FS,debug-threads=on' -no-shutdown -chardev 'socket,id=qmp,path=/var/run/qemu-server/133.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/133.pid -daemonize -smbios 'type=1,uuid=007ff9c7-f25c-4296-84c1-915ff6c82572' -drive 'if=pflash,unit=0,format=raw,readonly=on,file=/usr/share/pve-edk2-firmware//OVMF_CODE_4M.secboot.fd' -drive 'if=pflash,unit=1,id=drive-efidisk0,format=raw,file=/dev/rbd-pve/8f515fd6-628a-4a4b-bca7-ad03c981189d/XXXXX/vm-133-disk-0,size=540672' -smp '12,sockets=1,cores=12,maxcpus=12' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' -vnc 'unix:/var/run/qemu-server/133.vnc,password=on' -no-hpet -cpu 'kvm64,enforce,hv_ipi,hv_relaxed,hv_reset,hv_runtime,hv_spinlocks=0x1fff,hv_stimer,hv_synic,hv_time,hv_vapic,hv_vpindex,+kvm_pv_eoi,+kvm_pv_unhalt,+lahf_lm,+sep' -m 81920 -readconfig /usr/share/qemu-server/pve-q35-4.0.cfg -device 'vmgenid,guid=6667f7be-204c-405f-b659-1e6df41271d2' -device 'usb-tablet,id=tablet,bus=ehci.0,port=1' -device 'vfio-pci,host=0000:21:00.0,id=hostpci0,bus=pci.0,addr=0x10,rombar=0' -device 'VGA,id=vga,bus=pcie.0,addr=0x1' -chardev 'socket,path=/var/run/qemu-server/133.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:33988f729f5' -device 'virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5' -drive 'file=/dev/rbd-pve/8f515fd6-628a-4a4b-bca7-ad03c981189d/XXXXX/vm-133-disk-2,if=none,id=drive-scsi0,discard=on,format=raw,cache=none,aio=io_uring,detect-zeroes=unmap' -device 'scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100' -drive 'file=/dev/rbd-pve/8f515fd6-628a-4a4b-bca7-ad03c981189d/Storage/vm-133-disk-0,if=none,id=drive-scsi1,cache=writeback,discard=on,format=raw,aio=threads,detect-zeroes=unmap' -device 'scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi1,id=scsi1' -drive 'file=/dev/rbd-pve/8f515fd6-628a-4a4b-bca7-ad03c981189d/Storage/vm-133-disk-1,if=none,id=drive-scsi2,cache=writeback,discard=on,format=raw,aio=threads,detect-zeroes=unmap' -device 'scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi2,id=scsi2' -netdev 'type=tap,id=net0,ifname=tap133i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' -device 'virtio-net-pci,mac=XXXXXXXXX,netdev=net0,bus=pci.0,addr=0x12,id=net0' -rtc 'driftfix=slew,base=localtime' -machine 'type=pc-q35-5.0+pve0' -global 'kvm-pit.lost_tick_policy=discard'' failed: got timeout

Spoiler: PVE Version

()
proxmox-ve: 7.4-1 (running kernel: 5.19.17-2-pve)
pve-manager: 7.4-3 (running version: 7.4-3/9002ab8a)
pve-kernel-6.1: 7.3-6
pve-kernel-5.15: 7.3-3
pve-kernel-5.19: 7.2-15
pve-kernel-6.1.15-1-pve: 6.1.15-1
pve-kernel-6.1.10-1-pve: 6.1.10-1
pve-kernel-6.1.6-1-pve: 6.1.6-1
pve-kernel-6.1.2-1-pve: 6.1.2-1
pve-kernel-6.1.0-1-pve: 6.1.0-1
pve-kernel-5.19.17-2-pve: 5.19.17-2
pve-kernel-5.19.17-1-pve: 5.19.17-1
pve-kernel-5.19.7-2-pve: 5.19.7-2
pve-kernel-5.15.102-1-pve: 5.15.102-1
pve-kernel-5.15.85-1-pve: 5.15.85-1
pve-kernel-5.15.83-1-pve: 5.15.83-1
pve-kernel-5.15.74-1-pve: 5.15.74-1
pve-kernel-5.15.30-2-pve: 5.15.30-3
ceph: 17.2.5-pve1
ceph-fuse: 17.2.5-pve1
corosync: 3.1.7-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve2
libproxmox-acme-perl: 1.4.4
libproxmox-backup-qemu0: 1.3.1-1
libproxmox-rs-perl: 0.2.1
libpve-access-control: 7.4-2
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.3-4
libpve-guest-common-perl: 4.2-4
libpve-http-server-perl: 4.2-1
libpve-rs-perl: 0.7.5
libpve-storage-perl: 7.4-2
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.2-2
lxcfs: 5.0.3-pve1
novnc-pve: 1.4.0-1
proxmox-backup-client: 2.4.1-1
proxmox-backup-file-restore: 2.4.1-1
proxmox-kernel-helper: 7.4-1
proxmox-mail-forward: 0.1.1-1
proxmox-mini-journalreader: 1.3-1
proxmox-offline-mirror-helper: 0.5.1-1
proxmox-widget-toolkit: 3.6.5
pve-cluster: 7.3-3
pve-container: 4.4-3
pve-docs: 7.4-2
pve-edk2-firmware: 3.20221111-2
pve-firewall: 4.3-1
pve-firmware: 3.6-4
pve-ha-manager: 3.6.0
pve-i18n: 2.12-1
pve-qemu-kvm: 7.2.0-8
pve-xtermjs: 4.16.0-1
qemu-server: 7.4-3
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.8.0~bpo11+3
vncterm: 1.7-1
zfsutils-linux: 2.1.9-pve1

Spoiler: VM conf

agent: 1,fstrim_cloned_disks=1
balloon: 0
bios: ovmf
boot: order=scsi0
cores: 12
efidisk0: XXXXX:vm-133-disk-0,efitype=4m,pre-enrolled-keys=1,size=528K
hostpci0: 0000:23:00,rombar=0
machine: pc-q35-5.0
memory: 48000
meta: creation-qemu=7.0.0,ctime=1667595828
name: FS
net0: virtio=XXXXXXXXX,bridge=vmbr1,tag=20
numa: 0
ostype: win10
scsi0: XXXXX:vm-133-disk-2,discard=on,size=150G
scsi1: XXXXX:vm-133-disk-0,backup=0,cache=writeback,discard=on,size=50000G
scsi2: XXXXX:vm-133-disk-1,backup=0,cache=writeback,discard=on,size=10000G
scsihw: virtio-scsi-pci
smbios1: uuid=007ff5c7-f25c-4226-84c1-935ff6c82112
sockets: 1
vmgenid: 776f7be-215c-455f-b119-1e6df11231d2

Entfernt man die PCI Karte, startet die VM ganz normal, ohne Fehler mit 80GB Ram. Fügt man sie wieder hinzu, startet die Maschine nicht. Lässt man die PCI Karte in der VM und stellt den Ram auf 45GB, startet diese wieder einwandfrei.

Gibt es eine Möglichkeit, die VM trotz PCI Karte mit deutlich mehr Ram zu betreiben?

Host:
CPU: AMD EPYC 7413 24-Core Processor
RAM: 220GB

Danke.

 

[Falk R.]

Was mich stutzig macht, sind die Write Errors auf Disk. Da scheint noch etwas anderes im argen zu sein.
Wegen RAM und PCI, ist der Server ein Single oder Dual Sockel Server?

 

[fweber]

Hi, PCI-Passthrough und viel RAM verzögern offenbar die VM-Startup-Zeit erheblich, siehe diesen Bug-Report [1]. Per default setzt PVE beim VM-Start ein Timeout von 30 Sekunden bzw. dem RAM in GiB (40GiB RAM ~ 40 Sekunden) -- je nach dem was höher ist. Vielleicht ist das Timeout in deinem Setup trotzdem zu kurz.

Könntest du versuchen, die VM manuell mit qm start VMID --timeout 300 zu starten? Das setzt einen Timeout von 5 Minuten.

[1] https://bugzilla.proxmox.com/show_bug.cgi?id=3502#c2

 

[quanto11]

Hallo Friedrich,

vielen Dank für den Hinweis. Ich hab den Bugtracker Eintrag nicht gesehen oder falsch gesucht. Der Grund für das lange starten mit passthrough ist nachvollziehbar, den timeout Wert anpassen hilft tatsächlich. Top Hinweis

 

[fweber]

Hallo @quanto11, ich arbeite gerade an einem Patch, der bei Nutzung von PCI-Passthrough anhand des zugewiesenen RAM ein höheres Timeout setzt. Dafür wäre es spannend zu wissen, wie lang deine VM mit PCI-Passthrough und 80GiB RAM denn tatsächlich zum Starten braucht. Könntest du das evtl. herausfinden? Das ist wahrscheinlich die "Duration" des VM-Start-Tasks, die du sehen kannst, wenn du auf den Task im Task-Log doppelklickst und im Reiter "Status" nachschaust.

 

[quanto11]

Hallo @fweber,

klar helfe ich gern weiter. Jedoch musste ich das Setup ein wenig umbauen, da die jeweilige Maschine, die die eigentliche Problematik erzeugt hat, ein wenig sensibel auf Ram Schwankungen/Anpassungen reagiert. Ich habe eine andere Maschine genommen und dort den Benchmark ausgeführt. Anbei die Resultate:

Neue VM:
mit 80GB ohne PCI Passthrough -> 1 bis 2 Sekunden
mit 80GB mit PCI Passthrough -> 4m 37s <- Speicher komplett reserviert
mit 70GB mit PCI Passthrough -> 2m 37s <- Speicher komplett reserviert
mit 60GB mit PCI Passthrough -> 2m 15s <- Speicher komplett reserviert

Jetzt eine Kuriosität, die mir nach mehreren Monaten nicht mehr aufgefallen ist. Der eigentliche Server, der mit 80GB Ram nicht starten wollte, dürfte auch nicht mit 70 oder 60 GB starten, da das Timeout über 60 Sekunden liegt. Das interessante ist jedoch, das der Server mit 75GB und PCI Passthrough lediglich 10-13 Sekunden zum starten braucht, anstatt < 2 Minuten. Anbei die Resultate:

Alte VM, für die dieser Thread aufgemacht wurde:

mit 75GB ohne PCI Passthrough -> 1 bis 2 Sekunden
mit 75GB mit PCI Passthrough -> 10 - 13 Sekunden <- Speicher nicht komplett reserviert

Der eigentliche Unterschied zwischen den VMs liegt darin, das die neue VM den Speicher komplett reserviert, bevor das System startet, die alte macht das nicht und ist auch deshalb nicht mehr von dem Timeout Prozess betroffen. Wieso das so ist, weiß ich nicht, da keine spezielle Einstellung dafür vorgenommen wurde.

 

[fweber]

Hi, super, danke für die Informationen, das hilft mir sehr!

Neue VM:
mit 80GB ohne PCI Passthrough -> 1 bis 2 Sekunden
mit 80GB mit PCI Passthrough -> 4m 37s <- Speicher komplett reserviert
mit 70GB mit PCI Passthrough -> 2m 37s <- Speicher komplett reserviert

Auch interessant, dass hier 10G mehr die VM-Startup-Zeit um zwei Minuten verlängern.

mit 75GB ohne PCI Passthrough -> 1 bis 2 Sekunden
mit 75GB mit PCI Passthrough -> 10 - 13 Sekunden <- Speicher nicht komplett reserviert

Der eigentliche Unterschied zwischen den VMs liegt darin, das die neue VM den Speicher komplett reserviert, bevor das System startet, die alte macht das nicht und ist auch deshalb nicht mehr von dem Timeout Prozess betroffen. Wieso das so ist, weiß ich nicht, da keine spezielle Einstellung dafür vorgenommen wurde.

Das ist allerdings spannend. Nur aus Interesse: Was für ein Device wird denn jeweils in der alten und den neuen VMs durchgereicht, und welches Betriebssystem läuft in den VMs?

 

[quanto11]

Hey Friedrich,

es handelt sich um Win Server 2019 und als Karte kommt eine LSI SAS9207-8E zum Einsatz. Woran ich mich erinnern kann ist, das die ersten Starts der VM immer länger dauert haben und er bis zu einem gewissen Punkt immer den Speicher reserviert hat. Hast du eventuell eine Ahnung, was ich prüfen kann, um zu schauen, wieso er bei der alten VM nicht mehr den Speicher reservieren muss? Das wäre für zukünftige Geräte eventuell hilfreich.

Danke.

 

[fweber]

Hi,

Kleines Update: Ab qemu-server > 8.0.7 wird beim VM-Start automatisch ein höheres Timeout gewählt, wenn PCI-Passthrough aktiviert ist (siehe Commit [1]). Damit sollte es hoffentlich nicht mehr nötig sein, manuell ein höheres Timeout mitzugeben. Danke nochmal für die Hilfe!

es handelt sich um Win Server 2019 und als Karte kommt eine LSI SAS9207-8E zum Einsatz. Woran ich mich erinnern kann ist, das die ersten Starts der VM immer länger dauert haben und er bis zu einem gewissen Punkt immer den Speicher reserviert hat. Hast du eventuell eine Ahnung, was ich prüfen kann, um zu schauen, wieso er bei der alten VM nicht mehr den Speicher reservieren muss? Das wäre für zukünftige Geräte eventuell hilfreich.

Seltsam -- momentan kann ich mir auch nicht erklären, warum die alte VM so viel schneller startet. Verstehe ich denn richtig, dass sich alles auf demselben PVE-Host abspielt? Könntest du die Ausgabe von pveversion -v sowie die Configs der alten und der neuen VM posten? Das wäre jeweils die Ausgabe von qm config VMID --current.

[1] https://git.proxmox.com/?p=qemu-server.git;a=commit;h=95f1de689e3c898382f8fcc721b024718a0c910a

 

[quanto11]

Hallo Friedrich,

danke für das Update. Ich hab die Änderung getestet, muss aber leider dazu sagen, das sich nichts in meiner Konstellation verändert hat. Die Maschine startet weiterhin maximal eine Minute und bricht das den Start ab. Anbei ein paar Daten für dich:

Spoiler: VM Current

root@host:~# qm config 141 --current
agent: 1
balloon: 0
bios: ovmf
boot: order=scsi0;ide2;net0
cores: 6
cpu: host
efidisk0: VMs:vm-141-disk-0,efitype=4m,pre-enrolled-keys=1,size=528K
hostpci0: 0000:21:00.0,rombar=0
hotplug: disk,network,usb
ide2: none,media=cdrom
machine: pc-q35-5.1
memory: 61440
meta: creation-qemu=7.0.0,ctime=1668171015
name: TESTVM
net0: virtio=FA:E8:63:41:23:28,bridge=vmbr1,tag=20
numa: 0
ostype: win11
scsi0: VMs:vm-141-disk-1,discard=on,size=232G,ssd=1
scsihw: virtio-scsi-pci
smbios1: uuid=cbf946e8-077d-42a5-b0fd-6e6eea7a40d1
sockets: 1
vmgenid: 3c80870e-3d2a-4771-896b-60bc9090e084

Spoiler: pveversion

proxmox-ve: 8.0.2 (running kernel: 6.2.16-12-pve)
pve-manager: 8.0.4 (running version: 8.0.4/d258a813cfa6b390)
pve-kernel-6.2: 8.0.5
proxmox-kernel-helper: 8.0.3
pve-kernel-5.15: 7.4-6
pve-kernel-6.1: 7.3-6
pve-kernel-5.19: 7.2-15
proxmox-kernel-6.2.16-15-pve: 6.2.16-15
proxmox-kernel-6.2: 6.2.16-15
proxmox-kernel-6.2.16-12-pve: 6.2.16-12
pve-kernel-6.2.16-11-bpo11-pve: 6.2.16-11~bpo11+2
pve-kernel-6.2.16-4-bpo11-pve: 6.2.16-4~bpo11+1
pve-kernel-6.1.15-1-pve: 6.1.15-1
pve-kernel-6.1.10-1-pve: 6.1.10-1
pve-kernel-6.1.6-1-pve: 6.1.6-1
pve-kernel-6.1.2-1-pve: 6.1.2-1
pve-kernel-6.1.0-1-pve: 6.1.0-1
pve-kernel-5.19.17-2-pve: 5.19.17-2
pve-kernel-5.19.17-1-pve: 5.19.17-1
pve-kernel-5.19.7-2-pve: 5.19.7-2
pve-kernel-5.15.116-1-pve: 5.15.116-1
pve-kernel-5.15.108-1-pve: 5.15.108-2
pve-kernel-5.15.107-2-pve: 5.15.107-2
pve-kernel-5.15.104-1-pve: 5.15.104-2
pve-kernel-5.15.102-1-pve: 5.15.102-1
pve-kernel-5.15.85-1-pve: 5.15.85-1
pve-kernel-5.15.83-1-pve: 5.15.83-1
pve-kernel-5.15.74-1-pve: 5.15.74-1
pve-kernel-5.15.30-2-pve: 5.15.30-3
ceph: 17.2.6-pve1+3
ceph-fuse: 17.2.6-pve1+3
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx4
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-4
libknet1: 1.25-pve1
libproxmox-acme-perl: 1.4.6
libproxmox-backup-qemu0: 1.4.0
libproxmox-rs-perl: 0.3.0
libpve-access-control: 8.0.4
libpve-apiclient-perl: 3.3.1
libpve-common-perl: 8.0.7
libpve-guest-common-perl: 5.0.3
libpve-http-server-perl: 5.0.4
libpve-rs-perl: 0.8.4
libpve-storage-perl: 8.0.2
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 5.0.2-4
lxcfs: 5.0.3-pve3
novnc-pve: 1.4.0-2
proxmox-backup-client: 3.0.2-1
proxmox-backup-file-restore: 3.0.2-1
proxmox-kernel-helper: 8.0.3
proxmox-mail-forward: 0.2.0
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.2
proxmox-widget-toolkit: 4.0.9
pve-cluster: 8.0.2
pve-container: 5.0.4
pve-docs: 8.0.5
pve-edk2-firmware: 3.20230228-4
pve-firewall: 5.0.3
pve-firmware: 3.8-2
pve-ha-manager: 4.0.2
pve-i18n: 3.0.7
pve-qemu-kvm: 8.0.2-6
pve-xtermjs: 4.16.0-3
qemu-server: 8.0.7
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.1.13-pve1

Der Host wurde nicht neugestartet, die QEMU Server Version jedoch passt. Die Test VM wurde mehrmals gestartet, leider immer mit dem gleichen Ergebnis.

Sag Bescheid wenn ich noch was testen kann.

 

[fweber]

Hi, sorry, die verlinkten Änderungen sind in qemu-server 8.0.7 (deiner installierten Version) noch nicht enthalten, sondern werden erst in der nächsten Version enthalten sein (also einer Version die höher ist als 8.0.7). Diese nächste Version wurde aber noch nicht released -- das hätte ich in meiner Nachricht etwas klarer herausstellen sollen. Vielen Dank aber für deine Bereitschaft zum Testen! Ich melde mich dann hier noch einmal, wenn die neue Version von qemu-server mit den Änderungen verfügbar ist -- wenn du willst, kannst du diese neue Version dann noch einmal ausprobieren.

 

[fweber]

Hi, sorry für die verspätete Rückmeldung. Der Patch ist in qemu-server 8.0.8 enthalten, diese Version ist seit PVE 8.1 verfügbar [1]. Falls doch noch Probleme mit dem VM-Start in Verbindung mit PCI-Passthrough auftreten sollten, sag gern Bescheid.

[1] https://git.proxmox.com/?p=qemu-server.git;a=blob;f=debian/changelog;h=9ba7327d#l23

 

[quanto11]

Hey Friedrich,

sorry, das die Antwort so spät kommt, leider liefen diverse Prozesse auf der jeweiligen VM, welche viel Zeit in Anspruch nehmen. Ich konnte es jetzt erneut testen, leider jedoch nicht mit ganz so gutem Feedback. Als Test wurde eine Win10 erstellt mit folgender Conf:

Spoiler: QM Conf

agent: 1
balloon: 0
bios: ovmf
boot: order=scsi0;net0;ide2
cores: 8
cpu: host
efidisk0: VMs:vm-XXX-disk-0,efitype=4m,pre-enrolled-keys=1,size=528K
hostpci0: 0000:21:00.0,rombar=0
ide2: none,media=cdrom
machine: pc-q35-8.1
memory: 61440
meta: creation-qemu=7.1.0,ctime=167707ID6
name: Test
net0: virtio=XXXXXX
numa: 0
ostype: win10
scsi0: VMs:vm-XXX-disk-1,discard=on,size=50G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=XXXX
sockets: 1

Der Host selbst hat eine Uptime von 60 Tagen. Beim Starten der VM reserviert der Host knapp 200-300 MB die Sekunde. Das scheint schon mal deutlich langsamer zu sein, als bei den letzten Test, welche ungefähr 444 MB pro Sekunde reserviert hat (grob gerechnet). Das Interessante ist, das von 10 Tests, die VM nur 4 mal gestartet hat, folgende sind die Zeiten, in der sie gestartet wurde: 3m 47s, 3m 27s und 3m 47s, 3m 22s.

Folgende Meldung tauchen noch im Syslog auf, sind aber bestimmt nicht relevant:

Spoiler: Syslog

Jan 27 20:38:12 pve pvestatd[7692]: VM ID qmp command failed - VM ID qmp command 'query-proxmox-support' failed - unable to connect to VM ID qmp socket - timeout after 51 retries
Jan 27 20:38:13 pve pvestatd[7692]: status update time (8.612 seconds)
Jan 27 20:38:22 pve pvestatd[7692]: VM ID qmp command failed - VM ID qmp command 'query-proxmox-support' failed - unable to connect to VM ID qmp socket - timeout after 51 retries
Jan 27 20:38:22 pve pvestatd[7692]: status update time (8.616 seconds)
Jan 27 20:38:27 pve kernel: vfio-pci 0000:21:00.0: vfio_ecap_init: hiding ecap 0x19@0x1e0 <-- kommt nur, wenn die VM es in der vorgegebenen Zeit schafft zu starten

Somit reicht das Zeitfenster komischerweise nicht immer aus, um die VM zu starten. Ich weiß jedoch nicht, wieso sie manchmal länger zum starten braucht. Der Host selbst hat keine Auslastung und läuft vielleicht auf maximal 15% Last. Ram ist noch mehr als 100GB frei, bevor die VM gestartet wird.

Lass mich wissen, wenn du mehr Infos brauchst.