VMware Fusion / OCLP Ventura: Transportfehler (VMDB) -14: Pipe connection has been broken

bobesch

bobesch

Aktives Mitglied
Thread Starter
Dabei seit
18.08.2011
Beiträge
1.742
Reaktionspunkte
1.036
Nach Upgrade auf OCLP_Ventura erscheint beim "mid2012 15" MBP9,1" beim versuchten Starten einer VM mit VMware Fusion13 die Fehlermeldung "Transportfehler (VMDB) -14: Pipe connection has been broken" während bei gleicher Installations-Routine beim "2013/14er 11"MBair" VMware Fusion13 alles ohne Probleme läuft.
Nach etwas niggeliger Suche im Web stellt sich heraus, dass VMware Fusion die Aktivierung der diskreten Grafikkarte beim 15"MBP abfordert, aber Probleme mit der Umschaltung von interner/intel zur diskreten Grafikkarte hat.
Die dGPU kann man unter Ventura permanent einschalten via "Systemeinstellungen/Batterie/Optionen/Automatischer Wechsel der Grafikmodi=aus".
Oder einfacher über die Menüleiste mit der App "gfxCardStatus by Cody Krieger"
Wahnsinn! Simple Lösung. Und nirgendwo eine Adressierung/Dokumentation/Hilfestellung bzgl. dieses Fehlers bei VMware. Bei Mojave muss(te) man SIP abschalten, damit Fusion funktioniert.
Naja, Hauptsache, es gibt überhaupt eine Lösung ...
 
Zuletzt bearbeitet:
Und nirgendwo eine Adressierung/Dokumentation/Hilfestellung bzgl. dieses Fehlers bei VMware
Das ist ja auch eher ein OCLP Fehler als von VMware, da funktioniert das Umschalten ja bei manchen Geräten nicht.
 
-> Bei mir hat bei gleichem fehler ein erneutes drüberinstallieren von VMware Fusion geholfen.

Das Problem trat bei mir bei allen Virtuellen Maschinen auf. Egal ob Windows oder Linux.
 
Das ist ja auch eher ein OCLP Fehler als von VMware, da funktioniert das Umschalten ja bei manchen Geräten nicht.
Bei OCLP_Ventura vielleicht - aber das besagte Problem bei Mojave ist bei einer normale macOS-Installation auf einem offiziell unterstützen Gerät.
 
Ah, hatte die beiden Links gestern auch schon gefunden.
Der erste bezieht sich, glaube ich, auf eine VM unter Windows:
"Finally, I fixed it!
What work for me was to disable the Windows Subsystem for Linux.
Search for "Turn Windows Features on or off", next, a window will pop up.
Scroll down until you find:
Windows Subsystem for Linux - Uncheck
Also make sure that:
Hyper-V
Virtual Machine Platform
Windows Hipervisor Platform
: Are unckecked/Disabled"



Der zweite Link hat mich auf den Weg gebracht die automatische Umschaltung der Grafikkarten zu deaktivieren, bzw "gfxCardStatus" für eine schnelle manuelle Umschaltung zu nutzen.
"I tried the following methods stated in the other posts regarding this error and nothing worked.
- sudo kextutil /Applications/VMware\ Fusion.app/Contents/Library/kexts/vmmon.kext
- go into system preferences, battery, and disable “Automatic Graphics Switching”
- manually edit the .vmx file, modifying the option mks.forceDiscreteGPU="TRUE" to mks.forceDiscreteGPU="FALSE"
- disable 3D accelerator"


Habe mir den zweiten Artikel nochmal durchgelesen und dann die .vmx Datei geändert:
die Zeile mks.forceDiscreteGPU="TRUE" ist in meiner Konfiguration-Datai garnicht vorhanden.
Habe sie also nachträglich eingefügt (und den Parameter NICHT, wie im Artikel beschrieben, auf "False" gesetzt) und, voilà, die VMs lassen sich nach der Modifikation der .vmx Daten auch bei automatischer Grafikkarten-Umschaltung starten.
Da hat wohl VMware was beim Kodieren vergessen - das ist sicher nicht die Schuld von OCLP.

@tubo Danke, dass Du mich nochmal mit der Nase drauf gestossen hast!
 
  • Gefällt mir
Reaktionen: win2mac
Da hat wohl VMware was beim Kodieren vergessen - das ist sicher nicht die Schuld von OCLP.
Hast du die VM auf dem Rechner erstellt?
Die "Schuld" von OCLP ist, dass es keine automatische Umschaltung unterstützt.
Bzw es ist deine, wenn du erwartest, dass unsupported Bastellösungen irgendwo supported werden. ;)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: win2mac
Hast du die VM auf dem Rechner erstellt?
Die "Schuld" von OCLP ist, dass es keine automatische Umschaltung unterstützt.
Bzw es ist deine, wenn du erwartest, dass unsupported Bastellösungen irgendwo supported werden. ;)
Mit dem Eintrag mks.forceDiscreteGPU="TRUE" funktioniert die automatische Umschaltung unter OCLP_Ventura korrekt.
Nein, die VM habe ich nicht auf dem Ventura-MBP erstellt, sondern von Mojave/Fusion11 migriert.
Unter "offiziellem" Mojave wird der o.g. Eintrag bei Neuanlage einer VM nicht angelegt. Frage mich, woher die oben zitierte Quelle die Info über den Eintrag "mks.forceDiscreteGPU="VALUE" hat ...
Werde heute Abend nochmal testen, was bei Neuanlage einer VM unter Fusion13/OCLP_Ventura passiert.
Hast ja im Prinzip Recht - die Programmierer von VMware werden die Fusion-Versionen nur auf unterstützten Hardware/macOS-Versionen testen.
Mache (gepatchte) Upgrades nur (noch), wenn ich vorher alle meine kritischen Apps und Peripherie an einer Testinstallation gründlich geprüft habe.
Fusion11/Mojave ist eine offizielle Kombi auf dem mid2012er MBP9,1. Und trotzdem gibt's da Probleme ...
 
Heute früh getestet: auch eine auf dem 2012er MBP9,1/OCLP_Ventura erstellte VM (Win10) scheitert daran, dass eine automatische Grafikumschaltung auf die dezidierte Grafikkarte passiert.
Der Eintrag mks.forceDiscreteGPU="TRUE" wird nicht in der .vmx Datei erstellt - wenn nachträglich gesetzt, dann funktioniert die Grafikumsschaltung.
Die Option funktioniert auf VMs mit Win2k, WinXP, Win7 und Win10. Linux habe ich bisher nicht getestet.
Alternativ kann man manuell auf die dezidierte Grafikkarte umschalten: #1 "Die dGPU kann man unter Ventura permanent einschalten via "Systemeinstellungen/Batterie/Optionen/Automatischer Wechsel der Grafikmodi=aus".
Oder einfacher über die Menüleiste mit der App gfxCardStatus by Cody Krieger."
Ob das ein generelles Problem bei OCLP_Ventura und MacBooks mit dezidierter Grafikkarte oder nur ein Maschinen-spezifisches Problem ist, ist offen.
Irgendwo hakt jedenfalls in diesem Fall der Befehl von VMware Fusion13, dann OCPL_Ventura beim Start einer VM auf die dezidierte Grafikkarte umschalten soll.
Der individuelle Eintrag von mks.forceDiscreteGPU="TRUE" in die .vmx Datei aktiviert dann ggf. das Umschalten trotzdem.
 
Welchen Rechner spooft denn OCLP eigentlich bei deinem MBP?
Einen ohne 2 GPUs?
 
Hmm, sorry, die Frage habe ich nicht verstanden ...
OCLP täuscht doch einen anderen Mac vor, damit sich das System installieren lässt.
Ist das denm auch ein Laptop wo 2 Grafikkarteb inkl umschalten drin sind?
 
OCLP täuscht doch einen anderen Mac vor, damit sich das System installieren lässt.
Ist das denm auch ein Laptop wo 2 Grafikkarteb inkl umschalten drin sind?
Klar. MBP9,1
Mit der letzten OCPL nightly 0.6.2
 
So, wieder ein paar neue Erkenntnisse gesammelt (bezieht sich alles auf mid2012er nonRetina 15"MBP9,1/OCLP_Ventura):

Mein Hauptrechner läuft mit (offiziellem) Mojave. Daran ändert sich wohl erstmal auch nichts.
Da hat Fusion11 (letzte unterstützte Version) ein Problem mit den kext-Dateien und den Sicherheitseinstellungen von macOS. Einfachstes Workaroud ist SIP auszuschalten. Grundlegende Lösung hier #37
Problem wurde nicht von VMware gelöst. (PITA - aber immerhin funktioniert's irgendwie)
Interessant: die VMs unter Fusion11 laufen alle mit integrierter Grafik und brauchen keine Grafik-Umschaltung. (gfxCardStatus ist ein feines Helferlein, um das zu sehen)
...
Das Test-MBP9,1 mit OCLP_Ventura und Fusion13 fordert aber gnadenlos die dezidierte GPU an, allein die Grafik-Umschaltung funktioniert nicht, ausser in den Einstellungen der .vmx Datei ist explizit mks.forceDiscreteGPU="TRUE" vorgegeben oder man aktiviert per gfxCardStatus oder Systemeinstellungen "permanent" die dGPU.
Die Einstellung mks.forceDiscreteGPU="TRUE/FALSE" wird in keiner Fusion11-13 Versionen in der .vmx Datei gesetzt, sondern man muss die manuell einsetzen ... (habe immer noch nicht gesucht/gefunden, wo dieser Parameter dokumentiert ist)

Kann mir nicht helfen, aber habe irgendwie die Vision eines einsamen Programmierers (vllt.sind's auch zwei) in einer Großraumbüro-Kabine, der/die entrückt das Projekt "Fusion/Mac" vorantreiben.
 
Ja, hier leider nix kext-Dialog (weder gesehen noch übersehen) ...
Das kann man auch nachträglich über die Team ID erlauben, dafür hat VMware auch eine Anleitung.

An sich schlechtes Apple Design.
 
Zurück
Oben Unten