"Der neue Weg" macOS zu nutzen oder "The new way of building a Hackintosh"

Zitat von eldxmgw

Denn wäre es anders, hätte es (um nur ein aktuelles Beispiel zu nennen) die Plandemie™ niemals gegeben.

Könntest Du das an dem genannten Beispiel näher erläutern?

Der Zusammenhang zwischen Hackintosh und Pandemie ist mir auch noch nicht klar geworden - obwohl ich beides aus erster Hand kenne.

Zitat von talkinghead

Könntest Du das an dem genannten Beispiel näher erläutern?

Ich drücke mich mal gezügelt aus: "Hier geht es nicht mehr um Medizin, sondern eine anerzogene Gläubigkeit." Da evidenzlos.

Man kann diesen Satz leider noch erweitern auf „Hier geht es nicht mehr um Erkenntnis, sondern eine anerzogene Gläubigkeit“, und mit dieser Gläubigkeit wird Schindluder getrieben, in der Medizin, in der Politik. Gerne wird Immanuel Kant in Anspruch genommen: „Aufklärung ist der Ausgang des Menschen aus seiner selbstverschuldeten Unmündigkeit. Unmündigkeit ist das Unvermögen, sich seines Verstandes ohne Leitung eines anderen zu bedienen“. Praktiziert wird das Gegenteil: wie die „Plandemie“ so deutlich gezeigt hat, wird „Gläubigkeit anerzogen“, zum Zwecke „Teile und herrsche!“ Und kassiere …

Gekaufte Medien in der Hand einiger weniger, sind nur ein anderer Aggregatzustand des Kapitals. Und so funktionieren sie auch.

Bei normalen Menschen ist Inkompetenz ein fristloser Kündigungsgrund. Bei manchen Menschen jedoch ist er ein fristloser Karrieregrund, siehe -> Staat/Wirtschaftsunionen oder deren Lobbyisten.

Bildung wurde schon lange durch ideologische Haltung ersetzt. Besonders in staatlichen, deutschen Schulen.

Nichts davon ist neu. Das Verhalten der Massen ist leider so!

Ausführlich kann man dies nachlesen bei:

Erich Fromm: Anatomie der menschlichen Destruktivität

Haben und Sein

Ihr werdet sein wie Gott

Sigmund Freud: Massenpsychologie

Franz Andreas Völgyesi : Menschen – und Tierhypnose

Psychologische Kriegsführung zum Beispiel basiert genau auf diesen Erkenntnissen.

Lt. Völgyesi gibt es grundsätzlich vier Nerventypologische Konstellationen:

1. Anlagemäßig und entwicklungsmäßig psychopassiv.

2. Anlagemäßig psychopassiv, aber entwicklungsmäßig psychoaktiv.

3. Anlagemäßig psychoaktiv, aber entwicklungsmäßig psychopassiv .

4. Anlagemäßig und entwicklungsmäßig psychoaktiv.

Die anlage- und entwicklungsmäßig Psychoaktiven verdanken es oft der Selbsthemmung und einem Übermaß an Selbstbeherrschung, daß ihre ärgerliche Nüchternheit selbst in den glücklichsten Momenten ihres Lebens sie nicht verläßt.

Meißt erkennen sie über sich keine Superiorität, keine fiktive Autorität an, selbst dann nicht, wenn sie aus Opportunismus vor ihr dienen. Sie sind misstrauisch gegen jedermann, auch gegen sich selbst und ihren Arzt.

Ihnen imponiert nur die intellektuelle, auf konkretem Wissen basierende Überlegenheit.

Die Psychoaktiven setzen sich nicht einfach auf den für sie bestimmten Stuhl, sondern drehen ihn um oder rücken ihn eingenmächtig weiter. Sie lassen sich nicht befehlen.

Die ersten drei Gruppen können bei den kulturell stark zurückgebliebenen, an Gehorsam gewöhnten, aber auch bei den disziplinierten Soldaten, Sportsleuten, Beamten bis zu 80- 95 % anwachsen.

Zerfällt ein Narrativ, wird auf das Nächste gesetzt. Beispiele dafür gab es kurz-, mittel, langfristig, aktuell, in der kürzeren Vergangenheit oder Historie, genügend. Man muss kein Historiker sein um das zu erkennen.

Es muss nur entgegen der auferlegten Konformitätszwänge, kritisch, authentisch und frei von jeglichen Hemmungen hinterfragt werden. Nur dazu ist die Mehrheit viel zu bequem.

Deshalb funktioniert und funktionierte es auch immer so gut. Jedoch nicht bei der wie unter Punkt 4 beschriebenen Kontrollgruppe die auch historisch gesehen immer das Narrativ zerfallen hat lassen.

Ich will hier nicht ins Plandemie Detail gehen da es nicht das richtige board dafür ist. Jedoch kann das auch andere aktuelle Agenden übertragen werden um die Masse zu beschäftigen und vom Kern der Materie abzulenken.

Wenn allerdings die tägliche Handschrift der angewandten Massenpsychologie gelesen werden kann, hilft es einem ungemein im Leben weiter Hintergründe bzw. Zusammenhänge besser für sich zu erkennen (Stichwort CBDCs).

Oder wie es schon Karl Marx beschrieb: "die Herrschenden Gedanken sind die Gedanken der herrschenden Klasse".

Zitat von MPC561

Dazu kommt noch das die Biester die OSX Installation verändern.

Machen Sie nicht, UNIB. erstellt einen kompletten Stick mit EFI, genauso wie wenn du es per Hand machen würdest, mit Clover.

MultiB. kann auch nur in der EFI und im L\E Ordner wirken, früher war es der S\L\E Ordner aber dieser wurde von Apple schreibgeschützt gemacht, das du keine Drittanbieter kexte mehr installieren kannst. Es gab damals noch andere ähnliche Tools, den Clover Configurator müsste man ja auch so einordnen.

Zitat von MPC561

Das ist rechtlich nicht legal während die OpenCore Konfiguration nur die EFI modifiziert und das ist legal oder zumindest legaler.

Nichts von dem ist Legal, Apple duldet es nur, solange bis Intel CPUs in macOS end of life sind.

Zitat von MPC561

Da niemand weiss was die Beaster tun kann auch niemand helfen wenn mal was nicht funktioniert.

Doch kann man, da sie nur noch in der EFI oder im L\E wirken können.

Zitat von Wolfe

Der Zusammenhang zwischen Hackintosh und Pandemie ist mir auch noch nicht klar geworden - obwohl ich beides aus erster Hand kenne.

Den gibt es auch nicht.

Damit war der kausale Zusammenhang zwischen Geschäftsmodell und hillfesuchenden gemeint (siehe backlog).

@eldxmgw https://www.hackintosh-forum.de/forenregeln-de/ Absatz 5.5

Bob-Schmu -> findet nicht statt.

Zitat von eldxmgw

Ich will hier nicht ins Plandemie Detail gehen

Danke, brauchst Du auch nicht, da:

Zitat von eldxmgw

Zerfällt ein Narrativ, wird auf das Nächste gesetzt

Und hier beenden wir die Schwurbelei bitte.

Sowas ist nicht erwünscht.

Diskutiert das bei 1-100 Bier mit anschließendem Ringelpietz oder so!

Zitat von kaneske

"Schwurbelei"

Das aufgesogen & falsche mainstream Pseudonym lässt tief blicken.

=> gerne!

Ich freue mich hier über Beiträge zu Hackintosh, da ich Fromm, Reich und Marx schon kenne. Coronaleugner dürfen gerne woanders ihre…Meinung…hinterlegen.

Zitat von Bob-Schmu

MultiB. kann auch nur in der EFI und im L\E Ordner wirken, früher war es der S\L\E Ordner aber dieser wurde von Apple schreibgeschützt gemacht, das du keine Drittanbieter kexte mehr installieren kannst. Es gab damals noch andere ähnliche Tools, den Clover Configurator müsste man ja auch so einordnen.

Ja Multibeast legt oder legte kexts direkt in der OSX Installation ab. Keine Ahnung was das Tool noch macht. Ist es Opensource wie OpenCore? Mehr muss ich doch gar nicht sagen?

Zitat von MPC561

Ist es Opensource wie OpenCore? Mehr muss ich doch gar nicht sagen?

Ein bisschen lachen muss ich gerade schon.

Du vergleichst zwei Apps mit einem OpenCore Bootloader.

Mit Open-Source brauchst du eh nicht kommen, anscheinend weißt du noch nicht mal wie MultiBeast und UniBeast arbeiten, ist aber auch egal jetzt, sehr viele Leute hat es zu einem Hackintosh gebracht und das ist alles was zählt.

Ich kann mich noch gut an die Anfangszeiten mit Chameleon erinnern und später die ersten Clover Versionen. Da war es nicht so einfach einen Hackintosh aufzubauen wie jetzt und die Tools haben es Leuten einfacher gemacht.

OK, ganz kurz mal was von mir dazu.

Ich habe meinen ersten Hack mit Ivy Bridge (3770k) gebaut. Der Weg hat mich damals auch ins Tomatenforum gezogen, schien doch alles sehr komfortabel und einfach zu sein. Und in der Tat hatte ich in so kurzer Zeit macOS am Laufen, dass es mir schon suspekt vorkam.

Aber es gibt nun einmal Laufen und Laufen

Am ersten Problem, das ich hatte bin ich gleich gescheitert. Einmal weil ich natürlich dank der Komfort-Tools keinerlei Ahnung hatte, was ich da eigentlich treibe und andererseits weil im Forum aus demselben Grund die Kompetenz doch eher rar gesät war.

Zum Glück bin ich dann auf dieses Forum hier gestoßen (welches ich ehrlich gesagt schon vor Tony entdeckt, aber aufgrund der deutschen Sprache links liegen gelassen hatte, war ich damals doch der Meinung, dass sich die Kompetenz nur in englischen Foren tummeln kann...Asche auf mein Haupt!). Mit einer Kombination aus Fragen und trial and error kam ich dann zum Ziel.

Heutzutage arbeite ich zu 90% macOS exklusiv auf meinem Coffee Lake und weiß auch mehr oder minder wo ich Hand anlegen muss wenn es hängt. Ich maße mir nicht an mich mit den echten Cracks dieses Forums zu vergleichen und danke für jeden Tag, den ich hier Zugriff auf deren Hilfe habe, aber gelernt habe ich doch so einiges.

Nicht falsch verstehen:

Ich bin nicht der Meinung, dass alles schwer und kompliziert sein muss, damit man sich reinsteigern und seinen Doktor machen muss um das Thema zu meistern, aber zu einfach ist auch nichts und führt zu den vielen Neumitgliedern in diesem und anderen Foren, die immer nur fordern, meinen alles geliefert bekommen und herummeckern zu müssen wenn nicht alles so läuft wie sie es sich wünschen auf der einen und denen, die schon früh die Flinte ins Korn werfen, weil sie keine Lust haben Initiative und Einsatz zu zeigen auf der anderen Seite.
Ein Mittelweg wäre sicherlich die beste Lösung und Tools wie OCAT, mit dem jeder Noob OC Updates durchführen kann, sind tolle Entwicklungen.

Es ist ein wie bei Windows auch.
Als ich angefangen habe mich mit IT zu befassen hieß es noch nicht, dass ein Spiel welches die Menge X an RAM voraussetzt auch einfach so auf einem PC mit besagter Menge läuft. Da musste man noch wissen was eine config.sys und eine autoexec.bat sind, was highmem macht usw. Das war in der Tat übertrieben. Aber wenn ich mir anschaue, dass die "Digital natives", wie die aktuelle Generation fäschlicherweise benannt wird höchstens weiß wie man ein Gerät ein- und ausschaltet und bei der simpelsten Fragestellung guckt wie ein Auto, zeigt das, dass die Entwicklung in die andere Richtung fehlgelaufen ist.

Zitat von Bob-Schmu

Ein bisschen lachen muss ich gerade schon.

Du vergleichst zwei Apps mit einem OpenCore Bootloader.

Bitte im Kontext lesen. Ich vergleiche eine App, Multibeast mit Opencore. Das was Multibeast macht mache ich mit Opencore und ich habe mit OpenCore Vorteile die ich bei Multibeast nicht sehe (zumindest basierend darauf was ich über das Tool weiss).

Die Informationen was Multibeast macht sind recht spärlich. Also erzähl mir bitte was Multibeast macht?

Meine Infos wie von hier zum Beispiel:

Klick

besagen das Multibeast Kexts in Lib/Ext der OSX Installation installiert. Von meinem Standpunkt her ist das nicht zu präferieren verglichen mit einer Installation der Kexte/Configs in der UEFI Partition. Deswegen, da bei jedem OS Update die Kexts gelöscht, geupdatet oder was auch immer werden können und so mein System ggf. nicht mehr bootet. Was mach ich dann?

Zitat von Bob-Schmu

Mit Open-Source brauchst du eh nicht kommen

Warum? Soweit ich weiss ist OpenCore Opensource? Ist Multibeast das auch? Was ist in Multibeast enthalten? Installiert es mir den NSA Trojaner? Woher weiss ich das?

Zitat von Bob-Schmu

Ein bisschen lachen muss ich gerade schon. ...anscheinend weißt du noch nicht mal wie MultiBeast und UniBeast arbeiten

Ein bisschen mehr Höflichkeit würde Dir gut stehen. Nochmal, Unibeast interessiert nicht. Meine Infos oben sagen das Multibeast so arbeitet wie ich beschrieb bzw. mal so arbeitete.

Nochmal die bitte mir zu erklären wie es jetzt arbeitet.

Gruss,

Joerg

Opensource ist niemals ein Garant für nicht kontaminierte assets gewesen.

Selbst wenn das ignoriert wird, allerspätestens dann, um bei dem board Beispiel zu bleiben, wenn ein kommerzielles Software Eco System wie OSX genutzt wird, ist der Sachverhalt eh obsolete.

Das Thema ist nicht ancient Uni- bzw. Multibeast. Die Kernthematik um die es in diesem thread u.a. ging, war OSX in Verbindung mit einem Typ 1 Hypervisor aufzusetzen.

Zitat von eldxmgw

Opensource ist niemals ein Garant für nicht kontaminierte assets gewesen.

Ein Garant sicher nicht, aber die Wahrscheinlichkeit OpenSource zu kontaminieren ist wesentlich geringer und der Aufwand Closed Source, als der Supplier der Closed Source SW, zu kontaminieren ist wesentlich geringer.

Zitat von eldxmgw

wenn ein kommerzielles Software Eco System wie OSX genutzt wird, ist der Sachverhalt eh obsolete.

Zu allgemein. Wir reden von Multibeast, also einem 2. Anbieter/Zulieferer parallel zu Apple. Apple hat/weiss eh alles, aber ich würde es vermeiden wollen das auch noch Hinz und Kunz alles weiss, um es mal einfach zu formulieren.

Ich möchte Euch alle dringend Ersuchen diesen Dialog im vernünftigen Rahmen zu halten und nicht einen knapp ein Jahr alten Thread mit scharfen Worten und unangemessener Ausdrucksweise zu vergiften!

Hallo,

Ich verstehe nicht, warum du dich über die Beaster so aufregst, di sind doch ehe Geschichte und werden nicht weiter entwickelt.

Das eigentliche Thema hier hab ich allerdings auch nicht kapiert.

Egal,

Schönen Abend

Ich kann vermelden, dass ich die Monterey VM in ESXi 7.0U3g-20328353 nun vollkommen lauffähig eingerichtet bekommen habe.

• RX480 passthrough via HDMI wird nativ erkannt und ist voll Metal unterstützt. Es hängt mit nativer Auflösung und 60Hz an einem 34" 21:9 Monitor.
• VMware default VGA device habe ich im VMKernel lahm gelegt, die dann zwar die herkömmliche Bedienung der DCUI deaktiviert. Das ist aber nach initialer Einrichtung eh hinfällig, und wenn absolut notwendig schnell wieder Rückgängig zu machen.
• Zwei RX480 passthrough configuration flags, insb. das für den path des VBIOS dumps habe ich der vmx hinzugefügt.
• RX480 HDMI sound passthrough funktioniert auch problemlos.
• Apple Keyboard (USB) und MX Master 3 Maus (USB Receiver) habe ich ebenso via passthrough über die vendor und device ID quirks in der boot.cfg, vmware config file und in der vmx eingetragen und der VM Konfiguration lauffähig hinzugefügt (btw. beide input devices hängen gar an einem manuellen USB Hub).
• USB 3.1 passthrough funktioniert auch anstandslos.
• Snapshots funktionieren entgegen so mancher Hinweise mit Passthrough VMs einwandfrei

Das Ganze ohne irgendwelche OC, extra kext oder sonstige OSX verarztungen. Vorhin habe ich auch das letzt aktuelle Overlay auf 12.6.2 drüber gebügelt. Die VM habe ich mir so eingerichtet dass ich sie direkt am Monitor über die Infrastruktur nutzen kann, oder via ARD. ESXi via WebUI. oder zentralisiert über das vCenter.

*** VENTURA UPDATE ***, auch die neue Ventura VM läuft, wie zuvor die Monterey VM samt allen passthrough Geräte anstandslos. GPU mit Metal Unterstützung, USB 3.1, HDMI Audio, Maus + Keyboard passthrough alles out of the Box. An OSX wurde wie immer nach der Installation nichts verändert. Jetzt muss mal jemand erklären weshalb man sich noch mit OC & Co herumschlagen muss wenn das gar mit obsolete Skylake Architekturen klappt? Bilder als Proof -> siehe Bild 15 und 16.

Abschließend werde ich mir noch überlegen das Ganze mittels ESXi 8.0-20513097 nachzubauen. Ich bin mir im klaren darüber das hier seitens VMware in Gegensatz zu 7.x einige Hürden eingebaut wurden die MacOS erschweren generell laufen zu lassen, aber nicht unmöglich machen. Erfolg hatte ich schon, allerdings habe ich den ganzen Passthrough Umfang nicht aufgesetzt.

Jetzt könnte man noch darüber nachdenken den Hypervisor anzuweisen die OSX VM nach Systemstart -> Hypervisor wird initialisiert -> VM wird initialisiert -> passthrough ist aktiv - automagisch starten zu lassen, um dem Nutzer den Eindruck einer physischen Workstation mit single major release zu vermitteln. Was n den layern drum herum läuft bekäme der in der Blase nicht mit. Im Prinzip wäre dass das wie es der Hackintosh klassisch vermittelte. Das ist ist alles in der ESXi bzw. VM Verwaltung einfach einzurichten. Man müsse sich nur die administrative Umsetzung durch den Kopf gehen lassen wie der Hypervisor reagiert, würde der Nutzer die OSX VM ausschalten und erwarten, dass die Workstation (eigentlich Host) sich ebenso wie traditionelles Blech verhält und sich ebenso ausschaltet. Ich denke das müsste per script geregelt werden (wenn man das will).

Im Prinzip sind die Schritte schnell und einfach zu erledigen.

(wer kein Passthrough anwenden will ist schon nach Punkt 7 fertig)

1. ESXi installieren und grundlegend einrichten
2. Passenden unlocker für die ESXi Version besorgen und anwenden (frei Verfügbar)
3. Gezogenes OSX Major release in ISO konvertieren
4. VMware Storage einrichten
5. VM erstellen und grundlegend einrichten. Nicht vergessen den NIC der VM als Adaptertyp mit VMXNET 3 zu versehen.
6. OSX Image ausrollen und grundlegend einrichten, und aktuelle VMware Tools manuell ziehen und unter OSX installieren.
7. ARD übers LAN aktivieren
8. Ich empfehle präventiv über Verwalten -> System -> Erweiterte Einstellungen über die Suche pcie zu bemühen und den Schlüssel VMkernel.Boot.disableACSCheck auf true zu setzen um die PCIe Funktionsprüfung bei Systemstart außer Kraft zu setzen. (Bild hängt anbei)
9. VMKernel VGA Treiber via ESXCLI command lahmlegen, damit die passthrough GPU devices nicht nach jedem Neustart wieder manuell aktiviert werden müssen Syntax: esxcli system settings kernel set -s vga -v FALSE (Vorsicht, ab dem Punkt quittiert die DCUI mit einem black screen s.o.) -> Neustart
10. Überprüfen ob in der Hypervisor Geräte Verwaltung die gewünschten passthrough Geräte aktiv sind, falls nicht manuell setzen -> Neustart
11. In der VM Konfiguration die PCIe passthrough GPU als PCIe device hinzufügen. Nicht die dynamische PCIe Variante nutzen. Dies hat zumindest direkt über den Hypervisor nicht funktioniert.
12. **ANMERKUNG: SIEHE UNTEN** svga.present in der vmx auf FALSE setzen (Vorsicht, ab hier funktioniert die VM Webkonsole nicht mehr. Ist aber auch nicht wichtig da ARD aktiv ist, und zusätzlich passthrough eingerichtet wird)
13. Passenden VBIOS dump besorgen oder eigenen auslesen. Hier gibts passende, genau auf Spezifikation achten. Beispiel hier: https://www.techpowerup.com/vg…ercolor-rx480-8192-160923
14. VBIOS dump am besten direkt auf dem VM Storage ablegen.
15. Neuen flag pciPassthru0.opromEnabled in der vmx auf TRUE setzen
16. Neuen flag pciPassthru0.filename in der vmx mit dem richtigen Pfad zum VBIOS dump auf dem VM Storage setzen. Beispiel: ../Powercolor.RX480.8192.160923.rom
17. VM Starten, PCIe passthrough sollte nun funktionieren nachdem der Monitor auf den richtigen Port gesetzt wurde. Ich will es nur erwähnen, ich habe gelesen dass PCIe GPU passthrough angeblich nur via HDMI und nicht via DP möglich ist. Ich kann das aktuell nicht überprüfen.
18. Ggf. weitere PCIe passthrough Geräte wie HDMI sound oder USB 3.1 (falls vorhanden) in der VM Konfiguration als PCIe device hinzufügen.

Das wärs eigentlich. Wer jetzt noch gewisse HID USB Geräte durschleifen will macht hier weiter....

• Via SSH auf den Hypervisor einloggen und mittels lsusb -v | grep -E '(^Bus|HID)' die vendor und device ID für die gewünschten HID passthrough USB Geräte ermitteln. Bei der Lesart sind die Werte nach der ID entscheidend (vendorID:deviceID)

Beispiel:

Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub

• Wichtig: im folgenden bekommen die Werte ein 0x vorgeschoben. Z.B. 0xXXXX = vendorId und 0xYYYY = deviceId.
• /etc/vmware/config mit vi konfigurieren und die eigenen ermittelte Werte nach folgenden Schema eintragen und speichern...

Beispiel:

usb.quirks.device0 = "0x05ac:0x0250 allow"

usb.quirks.device1 = "0x046d:0xc52b allow"

• Nun muss dem VMKernel mitgeteilt werden nicht ständig die USB Eingabegeräte für sich zu proklamieren. Dazu wird ein vi auf /bootbank/boot.cfg gemacht und die kernelopt Zeile anvisiert.

Beispiel:

kernelopt=autoPartition=FALSE

Dort wird direkt dahinter mit einem space mit der eigenen ermittelten vendor und device ID folgende Lesart hinterlegt vendorID:deviceID:minRevision:maxRevision:quirkName

Beispiel für ein Gerät:

CONFIG./USB/quirks=0x05ac:0x0250:0x0000:0xffff:UQ_KBD_IGNORE

Beispiel für zwei Geräte:

CONFIG./USB/quirks=0x05ac:0x0250:0x0000:0xffff:UQ_KBD_IGNORE:0x046d:0xc52b:0x0000:0xffff:UQ_KBD_IGNORE

Beispiel der ganzen kernelopt Zeile anhand zwei Geräte:

kernelopt=autoPartition=FALSE CONFIG./USB/quirks=0x05ac:0x0250:0x0000:0xffff:UQ_KBD_IGNORE:0x046d:0xc52b:0x0000:0xffff:UQ_KBD_IGNORE

• Der VM muss das passthrough der USB HID Geräte ebenso anhand der vendor und device ID mitgeteilt werden. Dies kann via ESXi WebUI oder shell gemacht werden. Hier können die Werte wie zuvor in der /etc/vmware/config eingetragen übernommen werden. Die vmx findet man in der shell unter /vmfs/volumes/VM Storage (share)/.....

Beispiel Auszug der vmx mit den neu eingetragenen Werte in der shell:

usb.generic.allowHID = "TRUE"

usb.quirks.device0 = "0x05ac:0x0250 allow"

usb.quirks.device1 = "0x046d:0xc52b allow"

• Hypervisor Neustart
• Zuletzt muss der VM Konfiguration noch die neuen USB HID Geräte in der ESXi WebUI hinzugefügt werden. Danach ist alles erledigt und sollte den ganz oben genannten Stand mit allen PCIe + USB HID passthrough Geräte entsprechen.

**ANMERKUNG**

Ab Punkt 11 erwähne ich stets die vmx. Damit ist u.a. die Konfiguration der VM gemeint. Es gibt prinzipiell zwei Vorgehensweisen diese zu editieren. Über die ESXi WebUI in der GUI -> VM -> bearbeiten -> VM Optionen -> Erweitert -> Konfigurationsparameter -> Konfiguration bearbeiten.

Oder in der shell im Verzeichnis der VM selber /vmfs/volumes/VM Storage (share)/...../ .... .vmx

Wichtig hierbei sind zwei Dinge. Egal ob in der GUI oder in der shell -> es sollte penibel auf die Syntax geachtet werden. Ein space zu viel, ein Schreibfehler ist schnell gemacht, man sieht den Wald vor lauter Bäumen nicht - es funktioniert nicht, oder die VM startet nicht oder verhält sich komisch. Auch sollte klar sein, dass wie die Parameter eingetragen werden sich von der GUI zur shell und anders herum, unterscheiden. Dass obwohl sie beide in der vmx landen.

Es gibt hier nicht "den richtigen Weg". Je nach situation ist mal der Eine, oder der Andere Weg besser.

Beispiel mit selben Parameter...

über die WebUI:

pciPassthru0.opromEnabled TRUE

pciPassthru0.filename ../Powercolor.RX480.8192.160923.rom

über die shell in der .vmx:

pciPassthru0.opromEnabled = "TRUE"

pciPassthru0.filename = "../Powercolor.RX480.8192.160923.rom"

Ich hoffe das hilft jemanden weiter. Und immer schön den Hypervisor in den Wartungsmodus setzen bevor Neu gestartet oder heruntergefahren wird!

Bilder zum HowTo hängen anbei.

Bottom Line:

Das mittlerweile 5 Jahre alte Hackintosh System, nun Hypervisor Host basiert auf folgenden:

• GA-Z170X-Gaming 3
• Intel Skylake i7 4GHz 6700K
• 32GB RAM
• PowerColor Red Devil RX480 8GB VRAM
• diverser SSD und HDD Storage

Zuletzt wurde noch für 9€ und für die ESXi 7 und 8 Kompatibilität ein PCIe I210-T1 GbE NIC gekauft. Der on board NIC wurde disabled.

Das damalige System wurde angelehnt an einen iMac 17,1 aufgebaut und funktionierte auf herkömmlicher Hackintosh Art bis Mojave wie ich es vor ESXi verwendet habe größtenteils out of the box.