ESXi: Passthroughed-GPU zwischen VMs automatisiert wechseln

[eehm]

Seit ich jetzt eine echte GPU (Quadro K2000) im meinem EXSi Backup Server habe, bin ich richtig auf den Geschmack gekommen. Aktuell nutze ich den Backup-Server so ein wenig als Zweit-PC. Also Monitor hängt direkt am DP-Anschluss und USB ist auch per Passthrough durchgereicht.
Aktuell läuft hier eine Windows 10 VM.
Jetzt hätte ich noch gerne eine Linux VM inkl. Passthrough dazu.
Generell habe ich schon erfolgreich probiert die Windwos-VM auszuschalten (über einen anderen Rechner) und dann die Linux-VM zu starten. Diese holt sich dann ebenfalls die Grafikkarte und die USB-Karte und das Bild kommt auf den Monitor.
Soweit so gut!

Jetzt würde ich allerdings gerne direkt von der Windows VM oder der Linux VM den Host dazu bewegen, dass er die aktuell aktive VM herunterfährt (dann habe ich kein Bild mehr am Monitor) und im Anschluss die andere VM startet (Bild wäre nach dem Start wieder auf dem Monitor). Also im Grund möchte ich den Umweg über einen separaten PC umgehen.
Denk ihr das kann man dem EXSi Host irgendwie beibringen, notfalls per Skript über SSH?

 

[besterino]

Ja.

 

[eehm]

Ja.

Hast du es ggf. schon selbst im Einsatz gehabt und ggf. einen Code-Schnipsel für mich mit dem ich weiterarbeiten bzw. darauf aufbauen kann?
Oder vielleicht einen Link mit einem Tutorial oder ähnlichem?

 

[besterino]

Nope.

Und weil ich heute gut drauf bin, noch etwas mehr als nur die Ein-Satz-Antwort: Hab nichts Fertiges. Du kannst aber z.B. mit dem entsprechenden Schnippsel aus meinem Tutorial zur APCUPSD-VM starten, das gibt Dir immerhin Hinweise zum Zugriff per SSH auf den ESXI-Host und wie man eine bestimmte VM per Commando stoppt. Zum Rest (Starten VM, Ausführung SSH-Script auf nem Windows-Client, ggf. Starten einer ESXi-VM, ggf. Aus- und Einhängen der GPU) findest Du mit ein wenig Initiative ganz bestimmt im Netz.

 

[eehm]

Da die Frage hier eigentlich besser rein passt als in den ESXi-Thread:

Gibt es in ESXi 7u2 eigentlich die Möglichkeit bei GPU-Passthrough entweder

• die GPU (Passthrough) als primäre GPU dem Gast zu übergeben und die vmware SVGA als sekundäre GPU
  
  oder
  
  
• die vmware SVGA komplett zu deaktivieren, dass sie der Gast nicht sieht
  Die Option svga.present = false hat bei mir nicht funktioniert und den Host wohl sogar einmal zum Absturz gebracht.

 

[Trambahner]

Ich denke, die erste Option ist eh Standard . Was primär und sekundär ist, sollte bei Windows dann die Anzeigeeinstellung ("Diesen Monitor als Hauptbildschirm) regeln.

 

[eehm]

Was primär und sekundär ist, sollte bei Windows dann die Anzeigeeinstellung ("Diesen Monitor als Hauptbildschirm) regeln.

Das stimmt.
Leider ist das bei Linux nicht ganz so einfach. Bisher habe ich es nicht geschafft den vmware Grafikadapter zu deaktivieren und den Monitor über die Quadro anzusteuern.
Deshalb habe ich mir gedacht, dass es das Einfachste wäre, wenn die SVGA von ESXi erst garnicht an den Gast übergeben würde!

 

[eehm]

Ich habe jetzt stundenlang rumprobiert.
Der Parameter svga.present = false und ein paar Anpassungen in Linux haben mir jetzt doch ein Bild auf den Monitor gebracht.

Jetzt habe ich aber das nächste "Problem". Wenn ich die VM heruterfahre, dann gibt der ESXi-Host die zuvor per Passthrough durchgereichte Grafikkarte nicht mehr frei.
Am Monitor wird ein schwarzes Bild dauerhaft angezeigt und ein zuweisen der GPU an eine weitere VM ist nicht mehr möglich.
Nach einem Reboot des Hosts ist die Karte wieder für jede beliebige VM EINMAL zuweisbar.
Gibt es eine Möglichkeit, dass ESXi die Ressource wieder freigibt, wenn eine VM Heruntergefahren wird und die GPU nicht mehr benötigt?

 

[besterino]

Unter 6.x konnte musste man bisweilen dazu in der passthru.map mit den Settings spielen, glaub d3d0, link oder bridge und mit einem davon gings dann… war dummerweise von GPU zu GPU, Plattform zu Plattform und ESXi-Version zu ESXi-Version unterschiedlich. Sehr nervig.

Das Problem trat übrigens auch bei ein und derselben VM auf, also dass man die auch nicht Neustarten konnte ohne den kompletten ESXi-Host zu rebooten.

Guck mal hier und in beiden Threads dann jeweils ein paar der nachfolgenden Postings von mir:

NAS/Server Hardwareguide 2019

Da wäre ich entspannter. Ich kenne keinen Server-RAM, der in seinem Specs betrieben Ärger macht. Aber am Ende simmer uns ja einig: mit den Samsungs wird’s bestimmt laufen.

www.hardwareluxx.de

[Lösung] Passthrough für Nvidia Geforce GTX Consumer GPUs in VSphere (ESXi) 6.0

Hat schon einer so eine GTX 1070 erfolgreich zum Laufen gebracht ? Überlege mir die in meinen neuen AiO-Server zu stecken (AMD Epyc). Epyc und Zocken ist ein eher abwegiger Ansatz, da Epyc nur sehr niedrige Taktraten erreicht.

www.hardwareluxx.de

Wie das jetzt bei 7 aussieht? Keine Ahnung. Ich hab das nicht mehr im Einsatz. Trambahner und Ceib3r (?) hatten das aber wohl mal getestet und hinbekommen. War für mich persönlich eine sehr lehrreiche Zeit. Und die Lehre am Ende: für mich zu viel Aufwand für zu wenig Mehrwert in der Praxis / im Alltag.

 

[eehm]

Wie das jetzt bei 7 aussieht? Keine Ahnung. Ich hab das nicht mehr im Einsatz. Trambahner und Ceib3r (?) hatten das aber wohl mal getestet und hinbekommen.

Weißt du, ob die beiden das ggf. hier verewigt haben wie sie dazu in 7.0 vorgegangen sind?

 

[besterino]

Wenn dann im weiteren Verlauf der oben bereits genannten Threads.

 

[eehm]

Ich habe jetzt gestern fast den ganzen Tag in Foren gesucht, getestet und ausprobiert. Und zum Teil sogar erfreuliche Ergebnisse/Erkenntnisse erhalten.
Leider brachten alle Modifikationen z.B. auch in der passthru.map keine vollständige Lösung.
Diese Parameter habe ich probiert (rot sind meine spezifischen IDs):
# Quadro K2000
10de 0ffe link false
10de 0e1b link false

oder
# Quadro K2000
10de 0ffe d3d0 false
10de 0e1b d3do false

Allerdings habe ich einen aus meiner Sicht interessanten Anhaltspunkt gefunden.
Wenn ich den GPU-Wechsel mit diversen Linux-VMs (Ubuntu-Basis) teste, dann kann ich die GPU nach dem herunterfahren der einen VM ohne Probleme an die nächste VM durchreichen und bekomme ein Bild auf dem Monitor!
Also generell scheint es zu funktionieren.

Sobald ich allerdings einer Windows10-VM die GPU durchreiche, kann ich sie nur noch mit dieser einen VM benutzen. In andere VMs funktioniert sie allerdings dann bis zum Neustart des Hostes nicht mehr.
Hat ggf. jemand eine Idee was die Windows VM im Hintergrund anstellt, dass das Verhalten sich so darstellt?
Ich verstehe es nämlich überhaupt nicht, weil eine Ausgeschaltete VM sollte doch eigentlich keinen Einfluss ehr haben.

 

[Morpheuz]

PC wird als eingeschaltet angezeigt obwohl er aus ist

Hi, ich nutze das kostenlose Tool "pc time on off" seit einigen Wochen zeigt der mir dass ich durchschnittlich 19 Stunden am PC sitze. Was nicht korrekt ist. Der PC wird dort als auch zu Zeiten als eingeschaltet registriert, wenn er eigentlich aus war und ich im Bett. Keine Ahnung ob das in...

www.hardwareluxx.de

Info bzgl runterfahren eines Windows systems, hibernate, Fastboot oder ähnlichem.

 

[besterino]

Definitiv Fastboot & Co. sowie alle sleep-States disablen.

Testweise mal die VM mit „shutdown /s /t 0“ in einer CMD statt übers Startmenü runterfahren. Gehts dann?

Mal die „andere“ Variante des Boot-Modus‘ der VM versucht, also statt UEFI mal BIOS bzw. umgekehrt?

Stochere grad auch nur im Dunkeln: bei den Startparametern auch mal Secure-Boot disabled?

In den VM-Parametern ggf. auch mal für die Nvidia-devices MSI.enabled auf 0 (oder war’s msi.disabled auf 1?) setzen.

 

[eehm]

Definitiv Fastboot & Co. sowie alle sleep-States disablen.

Habe ich alles in Windows deaktiviert.

Testweise mal die VM mit „shutdown /s /t 0“ in einer CMD statt übers Startmenü runterfahren. Gehts dann?

Danke für den Tipp, aber leider NEIN!

Mal die „andere“ Variante des Boot-Modus‘ der VM versucht, also statt UEFI mal BIOS bzw. umgekehrt?

Das hatte ich auch schon vermutet und bereits getestet. Diesbezüglich verhalten sich die UEFI-Win10-VM und die Bios-Win10-VM leider identisch.

bei den Startparametern auch mal Secure-Boot disabled?

Ja, ist bei beiden sowohl in UEFI als auch in Bios bei den Win10-VMs aus.

Das einzige was mir noch aufgefallen ist, aber auch hier hat eine Änderung bisher nicht gebracht.
Die Settings zum Passthrough sind folgende in den vmx-Dateien:

• Win10
  pciPassthru0.id = "00000:001:00.0"
  pciPassthru0.deviceId = "0x0ffe"
  pciPassthru0.vendorId = "0x10de"
  pciPassthru0.systemId = "61fff0a8-1edf-2b00-8c4e-3497f65b85db"
  pciPassthru0.present = "TRUE"
  pciPassthru1.id = "00000:001:00.1"
  pciPassthru1.deviceId = "0x0e1b"
  pciPassthru1.vendorId = "0x10de"
  pciPassthru1.systemId = "61fff0a8-1edf-2b00-8c4e-3497f65b85db"
  pciPassthru1.present = "TRUE"
  pciPassthru2.id = "00000:003:00.0"
  pciPassthru2.deviceId = "0x0194"
  pciPassthru2.vendorId = "0x1033"
  pciPassthru2.systemId = "61fff0a8-1edf-2b00-8c4e-3497f65b85db"
  pciPassthru2.present = "TRUE"
  sched.mem.pin = "TRUE"
  pciPassthru0.pciSlotNumber = "256"
  pciPassthru1.pciSlotNumber = "1184"
  pciPassthru2.pciSlotNumber = "1216"
  
  
• Linux
  pciPassthru0.id = "00000:001:00.0"
  pciPassthru0.deviceId = "0x0ffe"
  pciPassthru0.vendorId = "0x10de"
  pciPassthru0.systemId = "61fff0a8-1edf-2b00-8c4e-3497f65b85db"
  pciPassthru0.present = "TRUE"
  pciPassthru1.id = "00000:001:00.1"
  pciPassthru1.deviceId = "0x0e1b"
  pciPassthru1.vendorId = "0x10de"
  pciPassthru1.systemId = "61fff0a8-1edf-2b00-8c4e-3497f65b85db"
  pciPassthru1.present = "TRUE"
  pciPassthru2.id = "00000:003:00.0"
  pciPassthru2.deviceId = "0x0194"
  pciPassthru2.vendorId = "0x1033"
  pciPassthru2.systemId = "61fff0a8-1edf-2b00-8c4e-3497f65b85db"
  pciPassthru2.present = "TRUE"
  pciPassthru0.pciSlotNumber = "192"
  pciPassthru1.pciSlotNumber = "224"
  pciPassthru2.pciSlotNumber = "256"

Ggf. ist das das Problem, aber ich habe auch schon in beide Richtungen die IDs in den vmx-Dateien gleichgezogen.
Leider auch ohne Besserung. Allerdings bin ich mir hier nicht sicher, ob eine Änderung nur in den vmx-Dateien ausreicht oder ob ich noch in einem anderen File Anpassungen vornehmen müsste?


Ich hänge hier im Anschluss einfach mal die gesamte vmx-Datei der BIOS-Win10-VM an, vielleicht ist hier der Hase begraben
.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "19"
vmci0.present = "TRUE"
floppy0.present = "FALSE"
numvcpus = "4"
memSize = "8192"
bios.bootRetry.delay = "10"
powerType.suspend = "soft"
tools.upgrade.policy = "manual"
sched.cpu.units = "mhz"
sched.cpu.affinity = "all"
vm.createDate = "1647157084094216"
scsi0.virtualDev = "lsisas1068"
scsi0.present = "TRUE"
sata0.present = "TRUE"
usb_xhci.present = "TRUE"
scsi0:0.deviceType = "scsi-hardDisk"
scsi0:0.fileName = "Win10-Bios.vmdk"
sched.scsi0:0.shares = "normal"
sched.scsi0:0.throughputCap = "off"
scsi0:0.present = "TRUE"
ethernet0.virtualDev = "e1000e"
ethernet0.networkName = "VM Network"
ethernet0.addressType = "generated"
ethernet0.wakeOnPcktRcv = "FALSE"
ethernet0.present = "TRUE"
sata0:0.deviceType = "cdrom-image"
sata0:0.fileName = "/vmfs/volumes/620026b6-99a7df5f-096e-3497f65b85db/ISOs/Windows10.iso"
sata0:0.present = "TRUE"
displayName = "Win10-Bios"
guestOS = "windows9-64"
toolScripts.afterPowerOn = "TRUE"
toolScripts.afterResume = "TRUE"
toolScripts.beforeSuspend = "TRUE"
toolScripts.beforePowerOff = "TRUE"
tools.syncTime = "FALSE"
uuid.bios = "56 4d 88 ff e7 0e e1 13-d9 c4 db 8d 02 26 30 50"
uuid.location = "56 4d 88 ff e7 0e e1 13-d9 c4 db 8d 02 26 30 50"
vc.uuid = "52 bd 6c a0 47 10 82 bc-48 67 20 12 f4 55 1f e0"
sched.cpu.min = "0"
sched.cpu.shares = "normal"
sched.mem.min = "8192"
sched.mem.minSize = "8192"
sched.mem.shares = "normal"
ethernet0.generatedAddress = "00:0c:29:26:30:50"
vmci0.id = "36057168"
cleanShutdown = "TRUE"
pciPassthru0.id = "00000:001:00.0"
pciPassthru0.deviceId = "0x0ffe"
pciPassthru0.vendorId = "0x10de"
pciPassthru0.systemId = "61fff0a8-1edf-2b00-8c4e-3497f65b85db"
pciPassthru0.present = "TRUE"
pciPassthru1.id = "00000:001:00.1"
pciPassthru1.deviceId = "0x0e1b"
pciPassthru1.vendorId = "0x10de"
pciPassthru1.systemId = "61fff0a8-1edf-2b00-8c4e-3497f65b85db"
pciPassthru1.present = "TRUE"
pciPassthru2.id = "00000:003:00.0"
pciPassthru2.deviceId = "0x0194"
pciPassthru2.vendorId = "0x1033"
pciPassthru2.systemId = "61fff0a8-1edf-2b00-8c4e-3497f65b85db"
pciPassthru2.present = "TRUE"
sched.mem.pin = "TRUE"
pciPassthru0.pciSlotNumber = "256"
pciPassthru1.pciSlotNumber = "1184"
pciPassthru2.pciSlotNumber = "1216"
vvtd.enable = "TRUE"
tools.guest.desktop.autolock = "FALSE"
nvram = "Win10-Bios.nvram"
svga.present = "FALSE"
pciBridge0.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "TRUE"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "TRUE"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "TRUE"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
hpet0.present = "TRUE"
cpuid.coresPerSocket = "4"
sched.cpu.latencySensitivity = "normal"
svga.autodetect = "TRUE"
disk.EnableUUID = "TRUE"
numa.autosize.cookie = "40042"
numa.autosize.vcpu.maxPerVirtualNode = "4"
sched.swap.derivedName = "/vmfs/volumes/46f47d0f-0172f94e/Win10-Bios/Win10-Bios-f1419535.vswp"
vm.genid = "151605997855902485"
vm.genidX = "1542060103497127426"
pciBridge0.pciSlotNumber = "17"
pciBridge4.pciSlotNumber = "21"
pciBridge5.pciSlotNumber = "22"
pciBridge6.pciSlotNumber = "23"
pciBridge7.pciSlotNumber = "24"
scsi0.pciSlotNumber = "160"
ethernet0.pciSlotNumber = "192"
usb_xhci.pciSlotNumber = "224"
vmci0.pciSlotNumber = "32"
sata0.pciSlotNumber = "33"
scsi0.sasWWID = "50 05 05 6f e7 0e e1 10"
vmotion.checkpointFBSize = "16777216"
vmotion.checkpointSVGAPrimarySize = "16777216"
vmotion.svga.mobMaxSize = "16777216"
vmotion.svga.graphicsMemoryKB = "16384"
ethernet0.generatedAddressOffset = "0"
monitor.phys_bits_used = "39"
softPowerOff = "FALSE"
tools.remindInstall = "FALSE"
migrate.hostLog = "./Win10-Bios-f1419535.hlog"
scsi0:0.redo = ""
usb_xhci:4.present = "TRUE"
usb_xhci:4.deviceType = "hid"
usb_xhci:4.port = "4"
usb_xhci:4.parent = "-1"

 

[besterino]

Tjo das wird jetzt das bereits erwähnte üble Trail & Error ohne Garantie auf Erfolg.

Brauchst Du das 2. Nvidia device? Ist vermutlich Audio?

Ich würde als Nächstes:

1. Erst einmal NUR die reine GPU (ohne das 2. PCIE-Device) testen
und dazu dann nochmal die verschiedenen Kombinationen zu den Reset-Parametern (d3d0/link/Bridge/gar nichts) zunächst einzeln für die GPU probieren. Beginnen mit den Eintrag für Nvidia komplett auskommentieren.

2. Je nachdem ob das nur mit GPU zum Laufen kommt: wenn ja, das gefundene Setting für die GPU einzelnen setzen und ggf. dann Schritt 1 für das 2. Device wiederholen. Wenn nein, alle Kombinationen für Device 1 und 2 durch probieren, also einzeln:

D3d0/d3d0
D3d0/link
D3d0/bridge
D3d0/nix
link/d3d0
link/link
link/bridge
Link/nix
Bridge/d3d0
…

3
Wenn das nix bringt, weitere Vm-Settings ausprobieren, insbesondere:

pcipassthru#.msiEnabled = FALSE (# jeweils für das Nvidia-Device)

…und das auch wieder ALLE EINZELN in ALLEN Kombinationen für ALLE Nvidia-Devices….

Gibt noch weitere Settings, von denen man an verschiedenen Stellen lesen konnte, dass sie Auswirkungen hätten. Nach meiner Erinnerung war das aber bei mir nicht relevant.

 

[eehm]

Brauchst Du das 2. Nvidia device? Ist vermutlich Audio?

Am Ende wäre es schon ganz gut es zu haben, aber das ist ein guter Ansatz, dass ich mich mal nur auf die Grafik konzentriere .... ggf. ist hier das Problem in der Konstellation!

In den verschiedenen pciPassthru0.pciSlotNumber denkst du nicht, dass das Problem versteckt sein könnte?

Ich finde es halt sehr merkwürdig, dass mit Linux-VMs alles flutschen würde und Windows hier Ärger macht!
Die Frage ist nur, was macht ggf. Windows hier anders als Linux vor dem Herunterfahren oder was konfiguriert der ESXi im Hintergrund bei Windows anders, dass es am Ende zu diesem Phänomen kommt!

 

[besterino]

Vermutung: Linux und Windows bzw. die jeweiligen Nvidia-Treiber (!) unterscheiden sich darin, wie sie im Detail mit dem Nvidia-Gerät beim Shutdown umgehen und dementsprechend passt das eben für den ESXi mal ja und mal nein. Genau darum drehen sich jedenfalls die verschiedenen Parameter in der passthru.map und auch in den VM-Einstellungen, also was wird dem virtualisierten OS von ESXI „suggeriert“, damit das zur darunter liegenden Hardware und damit die Kette VM-OS/Treiber—ESXi—Hardware passt. Da ESXi keine Kontrolle über ein Passthrough-Device (mehr) hat, ist ESXi quasi darauf angewiesen, dass das kontrollierende Gast-OS die Hardware sauber „herunter fährt“ bzw. wieder freigibt. Der Parameter MSI.enabled betraf z.B. die Frage, wie Interrupts der Hardware gehandhabt werden. Da galt eigentlich, dass man das nur bis ESXi 5.5 auf FALSE setzen sollte (und ab 6.x das einfach funzt), musste das aber bei bestimmten Konstellationen trotzdem auch bei glaube 6.7 für einzelne Devices setzen.

 

[eehm]

Da ESXi keine Kontrolle über ein Passthrough-Device (mehr) hat, ist ESXi quasi darauf angewiesen, dass das kontrollierende Gast-OS die Hardware sauber „herunter fährt“ bzw. wieder freigibt. Der Parameter MSI.enabled betraf z.B. die Frage, wie Interrupts der Hardware gehandhabt werden.

OK, das leuchtet mir ein. Danke für die Erläuterung. So wird es in diesem Fall dann leider sein.
Gibt es ggf. einen Befehl um im ESXi die Grafikarte "zurückzusetzen"?
Also im Grunde einen Reboot für die GPU durchführen.
Ich habe auch schon versucht den Toogle Button zu benutzen. Also Passthrough Ein/- Ausschalten .... leider ohne Erfolg!

 

[eehm]

Vermutung: Linux und Windows bzw. die jeweiligen Nvidia-Treiber (!) unterscheiden sich darin, wie sie im Detail mit dem Nvidia-Gerät beim Shutdown umgehen und dementsprechend passt das eben für den ESXi mal ja und mal nein.

Ich habe heute wieder Stunden lang rumprobiert und kann deine Vermutung jetzt bestätigen.
Leider habe ich aus meiner Sicht viel zu lange gebraucht um folgendes zu versuchen.

GPU im Win10 Gerätemanager deaktivieren (Bild am Monitor ist weg) und dann über Remote herunterfahren. Ergebnis: Die GPU geht im folgenden wieder unter Linux und Windows.

Jetzt muss ich nur eine Lösung finden um den Vorgang zu Automatisieren.
Für das Deaktivieren der GPU im Gerätemanage sollte ich das recht einfach über ein Skript hinbekommen.

devcon enable pci \ ID_GPU
devcon disable pci \ ID_GPU

Die Frage ist nur, wie ich es beim Starten wieder per Skript aktiviert bekommen, wenn noch keine Windows Anmeldung stattgefunden hat?

 

[besterino]

Das mit der GPU deaktivieren war insgesamt ein Workaround für den Reboot-Bug. M.E. hast du immer noch nicht die richtigen Settings in der passthru.map bzw. ggf. auch im BIOS.

 

[eehm]

M.E. hast du immer noch nicht die richtigen Settings in der passthru.map bzw. ggf. auch im BIOS.

Meinst du im BIOS des ESXi-Hosts oder im VM-Bios?
Im VM-Bios wüsste ich leider nicht was ich dort anpassen könnte?

 

[besterino]

Hardware BIOS.

 

[eehm]

Hardware BIOS.

Hast du ggf. eine Vermutung nach was ich schauen könnte bzw. was ich versuchen könnte umzustellen?

 

[besterino]

Mit welcher Plattform bist du denn unterwegs?

 

[eehm]

Mit welcher Plattform bist du denn unterwegs?

• CPU: Xeon E3-1245 v5
• Board: Asus P10S-E-4L
• RAM: 64 GB DDR4 ECC
• GPU: Nvidia Quadro K2000 für Passthrough-VM
• USB: USB3.0 Karte für Passthrough-VM
• Host: ESXi 7u2

 

[eehm]

nicht die richtigen Settings in der passthru.map

Bisher habe ich nach jeder Änderung den Host neu gestartet. Das ist natürlich sehr zeitaufwändig.
Muss der Host nach Änderungen in der passthru.map neu gestartet werden oder geht das auch ohne Neustart?

 

[besterino]

Bin ich nicht sicher. Bei 6.x musste man neu starten - bei 7 keine Ahnung (meine irgendwo gelesen zu haben, dass das nicht nötig wäre - aber alle Angaben ohne Gewähr...).

Schau' auch noch einmal, ob Du in Deinem Hardware-BIOS irgendwas von ARI und ACS Support findest (siehe zum Beispiel "ACS Enable" bzw. "PCIe ARI Support" im Screenshot hier) und das ggf. mal testweise auf enabled setzen.

Ich sagte ja: hässliches trial & error (vor allem wegen der Reboots).

Weiterer Ansatz könnte noch sein, wie deine Kiste physisch bestückt ist: zu weiteren Testzwecken sollte die GPU entweder in einem PCIE-Slot stecken, der sich keine Lanes mit einem anderen Slot teilen kann, oder wenn es so einen Slot nicht gibt, sollte in dem anderen Slot nichts eingesteckt sein. Ich nehme mal an, dass Deine GPU im Slot6 steckt (oberster / einziger x16 Slot, siehe Handbuch). Dann sollte in Slot5 (direkt daneben) NICHTS stecken, sondern erst wieder in Slot4 (unterster PCIE-Slot).

Kann übrigens dann gut sein, dass sich Deine USB-Karte dann schon nicht mehr per Passthrough durchreichen lässt, weil der PCIE4 am Chipsatz hängt... für Testzwecke also zur Not einmal NUR die Graka stecken & durchreichen, dann schauen ob Reboot funzt.

Kannst auch mal probieren, ob ein Deaktivieren von ASPM (Einstellung unter den PCIE-Optionen) oder da noch mit weiteren Parametern spielen hilft. Und wie gesagt: bei/nach jeder Änderung im BIOS kannst (musst) du die ganze Litanei mit der passthru.map mit allen Kombinationsmöglichkeiten durchprobieren...

Spaß ist definitiv anders.

 

[eehm]

Spaß ist definitiv anders.

Das darfst du laut sagen.
Ich bleibe jetzt erst mal bei meine Workaround und falls am Wochenende schlechtes Wetter ist werde ich die nächsten Stunden investieren.
Es ist wirklich sehr zeitaufwändig die Testerei und vor allem auch nervig, weil man ständig alles dokumentieren muss, dass man nicht Möglichkeiten vergisst.
Und leider bisher alles ohne Erfolg.