Beiträge von eldxmgw

Hab mir Heute mein erstes Auto mit Vollaustattung und zweiten LRS liefern lassen.

Mein Infrastruktur Cluster in Sinne seiner Hosts ist was das vSphere Paket für ESXi angeht vSphere 7 Enterprise Plus mit Add-on für Kubernetes lizensiert.

Für den Vorgang mit dem System wie unter #2 habe ich dieselbe genutzt.

ESXi hat jedoch eine 60 day full evaluation period time. Da ist erstmal keine Lizenz notwendig.

Soweit ich mich erinnere, und nicht komplett falsch liege, ist die "free Variante" mit keinem wirklichen Hindernis versehen, die das o.g. irgendwo hemmen würde.

Gut max. 8vCPUs in der free Variante, aber ist das wirklich ein Limit?

Alles andere in Gegensatz zu den paid Varianten ist für die meisten user und das Vorhaben eh unrelevant, da der Fokus da auf Infrastrukturelle Angelegenheiten liegt.

Evtl. hilft die Aufstellung ein wenig weiter: https://www.ubackup.com/enterp…sxi-free-limitations.html

*** 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. Und das gar mit obsolete Skylake Architektur, dank dem Hypervisor layer, wie immer ohne irgend etwas wie kexts, OC oder sonstwas hinzugefügt zu haben.

Die Prozedur war dieselbe wie bei Monterey.

Bilder als Proof anbei.

Könnte ich bitte nochmal einen Lückenfüller für den 3. Beitrag haben, dann bin ich fertig

Das HowTo richtet sich in erster Linie an diejenigen die zumindest grundlegende Erfahrungen mit Typ 1 Hypervisor haben.

Ich hoffe dass derjenige der sich dafür interessiert die Dimension erkennt die es mit der Vorgehensweise eröffnet.

Weitere Optimierungen oder Änderungen stehen ja jedem in der Entwicklung der Sache frei.

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.

Grundsätzlich empfehle ich den VMware Compability chart zu bemühen: https://www.vmware.com/resources/compatibility/search.php

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

Da es dass auch jetzt tut werde ich die OSX VM mit den nativen passthrough Geräte weiterhin wie gewohnt als NLE Workstation und Foto editing Box produktiv nutzen. Das System ist keine Spielwiese.

Exakt das.

Ich musste da schon im content tricksen.

Am Ende dachte ich mir dann der Übersicht halber besser 3 hintereinander folgende Beiträge zu machen, hatte aber das vorliegende Problem nicht bedacht.

Hm, scha.de, dann muss ich auf irgend eine Antwort hoffen damit ich weiter machen kann. Trotzdem danke für die Auskunft

Danke dir.

Noch eine Verständnisfrage...

... kann es sein, dass auf diesem board grundsätzlich es so ist, dass wenn ich der Letzte user war der einen Beitrag geschrieben hat, erst immer warten muss dass ein anderer user antwortet, bevor ich das kann?

Beispielsweise ist es mir jetzt nicht möglich eine Ergänzung als zweit-Beitrag im neuen thread des neuen Bereichs zu schalten.

Zitat von MPC561

Löse Dich bitte von dem Gedanken das nur dein Usecase der einzig Sinnvolle ist.

Es gibt klare Richtlinien wie so eine Topologie auszusehen hat. Das nun mal die consumer Schiene andere Wege geht und sich an die Zielgruppe orientiert, bedeutet noch lange nicht das es richtig ist.

Hier geht es viel weniger um das "wie", als viel mehr um das "was".

Habe ich über mich im Plural geschrieben? Nein! Lese den backlog bitte noch einmal.

Zitat von MPC561

Es kann schon Sinn machen auf einem NAS eine voll funktionsfähige VM zu haben

Natürlich, sehe ich auch so.

Hab vielen Dank!

Es scheint so zu sein, dass der neue Bereich nicht mit dem Dashboard verknüpft ist. Zumindest wird dort keinerlei Aktivität aus dem Bereich gelistet, bei "letzte Aktivitäten" jedoch schon.

Ich schreibe das hier als Beitragserneuerung, da ich höchstwahrscheinlich ein Moderator limiter auf meiner UID gesetzt bekommen habe, und es mir nicht möglich ist, nach einer Beitragserstellung weiter irgendwo zu kommentieren.

Ich kann vermelden, dass ich die Monterey VM in ESXi 7.0U3g-20328353 nun vollkommen lauffähig eingerichtet bekommen habe. (Siehe Bilder 1, 5, 10, 10.5, 11, 12, 13, 14)

• 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 steuere ich via WebUI, oder zentralisiert über das vCenter.

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 in den layern drum herum läuft, bekäme derjenige 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 ein fat-client verhält und sich ebenso ausschaltet.

Da der Host vor dem Herunterfahren in den Wartungsmodus geschaltet werden sollte, müsste das 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 (getestet habe ich dies mit 7.0U3g-20328353 und 8.0-20513097. Bilder zeigen 7.0U3g).
2. Passenden ESXi unlocker für die ESXi Version besorgen und anwenden (frei Verfügbar in David Parsons GitHub repository https://github.com/DrDonk/esxi-unlocker).
3. Gezogenes OSX Major release in ISO konvertieren (hier eine nette Anleitung für Monterey, gilt aber auch modeliert für Ventura https://nishtahir.com/how-to-create-a-macos-iso).
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 für OSX manuell ziehen, und unter OSX installieren.
7. ARD übers LAN auf der VM 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. (siehe Bild 2).
9. VMKernel VGA Treiber via ESXCLI command lahmlegen, damit die passthrough GPU devices nicht nach jedem Neustart wieder manuell aktiviert werden müssen. Via SSH auf dem Host folgende 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 (siehe Bild 3).
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. (siehe Bild 4).
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, aber genau auf die Spezifikation achten. Beispiel hier: https://www.techpowerup.com/vg…ercolor-rx480-8192-160923).
14. VBIOS dump am besten direkt ohne großartige Verzeichnis Verschachtelungen auf dem VM Storage ablegen.
15. Neuen Parameter pciPassthru0.opromEnabled in der vmx auf TRUE setzen (siehe Bild 9)
16. Neuen Parameter pciPassthru0.filename in der vmx mit dem richtigen Pfad zum VBIOS dump auf dem VM Storage setzen. Beispiel: ../Powercolor.RX480.8192.160923.rom (siehe Bild 9).
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. HDMI funktioniert bei mir mit einem 7m Kabel.
18. Ggf. weitere PCIe passthrough Geräte wie beispeilsweise HDMI sound oder USB 3.1 (falls vorhanden) in der VM Konfiguration als PCIe device hinzufügen. Welche Geräte vom Gesamtsystem überhaupt passthrough fähig und unterstützt sind, sieht man in der ESXi Geräte Verwaltung. (siehe Bild 3).

Das wärs eigentlich. Wer jetzt noch gewisse HID USB Geräte wie Maus und Tastatur (bei mir Apple USB Kabel und Logitech MX Master 3 USB Receiver) via passthrough 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). (siehe Bild 6).

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... (siehe Bild 8).

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. (siehe Bild 7).

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 in der erweiterten Konfiguration der VM, 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)/..... (siehe Bild 9 und **ANMERKUNG** unten).

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. (siehe Bild 4).

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.

Zitat von atl

Ja, das hat mir auch weh getan und ich habe lange überlegt. Aber um auf dem Dachboden zu vergammeln, war er mir einfach zu schade. Denn effektiv machen konnte man leider damit nichts mehr. Und jetzt lebt er fort mit einem neuen Innenleben und ich kann mich weiterhin an dem schönen Design erfreuen!

Kommen wir zum von dir propagierten "Tellerrand": Unraid ist nicht nur eine Storage-Lösung https://unraid.net/blog/7-game…1-tower-behind-the-scenes .

Nostalgie ist doch was schönes. Ich finde es nicht ineffektiv sich auf den Funktionsumfang zu besinnen, den es damalig zu der Zeit mit eben sagen wir mal der Software hatte.

Habe selbsst noch zwei funktionsfähige Dual PMG5 im Keller. Einer davon für alle Fälle als Ersatzteilspender. Oder noch älter eine funktionierende Silicon Graphics O2 und Octane2.

Hin und wieder im Jahr find ich es recht angenehm, sich auf die Zeit mit dem wie sie war, zu besinnen.

Das ist mir bekannt. Es ist wie bei so vielen die eine ganz bestimmte Zielgruppe ansprechen soll. Und da trennt sich auch der Spreu vom Weizen.

Ob das Sinn macht entscheidet die Klientel und der vorgesetzte Absatzmarkt. Das sieht man auch sehr an solchen embedded consumer Lösungen wie QNAP, Synology oder ähnlich.

Und es scheint zu funktionieren, die Klientel nimmt es dankend an. Das gilt auch für Software Eco Systeme wie Unraid.

Ist es von der Topologie richtig ein NAS als Plexing-, Gaming, IOT..... was auch immer, Ding vollzustopfen?

Sicherlich nicht, aber die Masse will es so, es funktioniert, darum ist es ein Absatzmarkt und es hat seine Daseinsberechtigung.

Ich bin kein Fan von solchen Dingen.

Zitat von atl

eldxmgw, somit hast du selber die Antwort gegeben auf deine Frage, warum sich noch jemand mit OC & Co rum schlagen muss: Weil halt viele Endnutzer Notebooks nutzen, keine Ahnung von Infrastrukturen haben, einfach nur einen „günstigen“ Mac / Rechner haben wollen, um das Apple Universum zu nutzen… Und wenn du länger in diesem Forum mitliest, dann stellst du schnell fest, dass hier viele User unterwegs sind, die mit dem Hack Musik oder Videoschnitt machen. Denen geht es um maximsle Kompaibilität bei maximaler Leistung passend zu ihrem Budget. Die wenigsten befassen sich mit Infrastrukturen in deinem Sinne.

Und nein, einen VMware ESXi aufsetzen, um macOS als Desktop darin auszuführen würde auch ich nicht tun. Und dass obwohl ich es kenne und den Virtualisierungs-Ansatz mit durchgereichter Hardware sehr spannend finde und auch selber schon probiert habe. 🙂

Mein umgebauter Power Mac G5 soll aussehen wie ein echter Mac und sich anfüllen / verhalten wie ein echter Mac! Und das tut er nicht unter Proxmox, ESXi oder Unraid… nein nur mit Opencore samt Startton und Apfelbootscreen… und dank Microcontroller auch mit pulsierender Power-LED im Sleep. 😉

Nun, ich hege keinen Anspruch den Messias für irgendwelche Nutzer zu propagieren.

Mir musst du auch nichts über die Apple Klientel erzählen, ich habe mal über eine halbe Dekade für den Hersteller zertifiziert gearbeitet, und kenne die historisch bedingt bestens.

Nichts anderes wird oder wurde mit der Workstation je getan. Dieses ding war schon immer, und wird auch weiter unter Verwendung des Hypervisors eine produktive NLE und Foto editing Box sein.

Das war auch der Grundgedanke des HowTos. Denn so ist es geschrieben. Nicht für den DAU, aber schon low level mit Zielsetzung "Funktion" für den zuvor genannten Einsatzzweck. Von Infrastrukturen muss dabei niemand Ahnung haben.

Er sollte allerdings Ahnung, oder besser gesagt, mit den Grundzügen der Virtualisierung vertraut sein, um zumindest das Potential zu erkennen, was ihm dort in die Hand gegeben wird.

Und das ist der alleinige Knackpunkkt an der Sache. Mir ist bewusst, dass es widersprüchlich in der Natur des Menschen liegt, grundsätzlich den inneren Antrieb zu haben neugierig zu sein.

Sobald es aber, und das ist leider ein Zeichen unser Zeit, zur mentalen Eigeninitiative kommen müsste, wird mehr Energie darin verschwendet dagegen zu arbeiten, anstatt seine eigenen Defizite durch Aneignung von frei verfügbaren Wissen auszumerzen.

Könnte ich das HowTo einem DAU geben und sage "mach fertig"? Ja

Würde derjenige das Potentital für sich erkennen, nutzen und ausbauen können ohne die grundlegenden Kenntnisse der Virtualisierung verinnerlicht zu haben? Nein.

Das Denken muss derjenige schon selbst hinbekommen.

Gott sei Dank filtert sich die anvisierte Zielgruppe selbst.

Diejenigen die im Thema sind werden über eine bisher gefehlte Zusammenfassung in ihren Details dankbar sein. Recherchier einfach im Netz mit Foren oder Plattformökonomie Einträge der letzten 3-4 Jahre und Du wirst erkennen wie viele sich damit schon befasst haben.

Diejenigen die es nicht sind, aber den Mut haben über den Tellerrand zu schauen werden es mit der Zeit erkennen und wohlmöglich für sich optimieren.

Diejenigen die es nicht sind, aber auch nicht wollen, sollen bitte ihr gemachtes Refugium weiter benutzen und alles ist fein.

Mir schmerzt alleine schon die Vorstellung wie Du den PPC seziert hast, das würde ich meinen G5 niemals antun.

Nun, funktionieren und anfühlen tut er sich so auch. Wie gesagt bei Proxmox kann ich nicht mitreden, bei ESXi schon.

Apfelboot screen hatte der schon von Sekunde 1, wie gesagt alles ohne OC. Sleep Funktion aus OSX heraus ist auch problemlos möglich.

Dank passthrough starte ich den ganzen Host, und Du wirst nichts vom Hypervisor mitbekommen, da nach gewisser Zeit dein anvisierter Apfelboot screen kommt und du im gewohnten login screen von OSX landest.

Das ist einfach nur ein autostart flag der einmalig gesetzt werden muss wenn man so operieren möchte.

Was Unraid als Storage Lösung nun damit zutun haben soll verstehe ich nicht so ganz. Wenn dass allerdings auf Basis deines Proxmox Versuchs ein NFSv4 oder iSCSI Storage mountpoint war, ist das nichts was dem im Weg stehen sollte.

Für meinen Cluster nutze ich auf Basis von NFSv4 auf zwei physikalische TrueNas Scale Server so den Storage. Das würde auch mit dem Beispiel des hier besprochenen ESXi möglich sein. Ich habe mich, um es Simpel zu halten allerdings auf local storage einer SSD beschränkt.

Ich habe einfach nur den Eindruck dass bei manchen die Dimension noch nicht wirklich erkannt wurde.

MacPeet

Bitte komm von den Irrglauben ab, dass Menschen für dich das Denken übernehmen. Die Leistung musst Du schon selbst übernehmen.

Bitte vermeide möglichst auch über dich im Plural zu "schreiben", oder Schubladendenken für deine Defizite als mentale Rückversicherung zu instrumentalisieren.

Schließe bitte auch nicht von dir auf die Masse. Die Realität da draußen, außerhalb deines gemachten Refugiums zeigt seit 3-4 Jahre nachrecherchierbar in dem Segment definitiv was anderes.

Weiter bitte ich dich dringenst, mit der Materie, zumindest mit der der "Virtualisierung" in seinen Grundzügen vertraut zu machen die schon seit mind. zwei Dekaden Status Quo ist, bevor Du weiter über Sachverhalte schwardronierst und prekäre Schlussfolgerungen auf Basis von Unwissenheit für die Masse ziehst.

Wenn auch das lesen für dich zu viel ist, bin ich bei dir. Deine Selbstmotivation überhaupt Eigeninitiative zu zeigen ist selbst mit einem Kochrezept, isf. es nicht noch jemand für dich vorkaut auch nicht vorhanden.

Somit Bitte ich dich dort zu mit dem zu verweilen was Du auch schon immer getan hast.

Ich denke, dass Du "jetzt" nicht die richtige Zielgruppe bist, isf. bei dir zwecks Eigeninititative nicht ein fundamentaler Sinneswandel eintritt.

Bitte wirf keine Nebelkerzen. Das ist weder (ich liebe dieses Pseudo mainstream Wort) ein "Projekt", noch ist es eine sog. "Test"-Umgebung.

Zitat von MacPeet

Kann man sicher so machen, wenn man Bock drauf hat und Erfahrung damit hat, aber so ganz ohne zutun ist dies ja nun wirklich auch nicht, wie ich sehe

Erfahrung brauchst du mit dem HowTo keine wirkliche. Anders wäre es hätte ich nur die Info gegeben setz ESXi auf und sieh zu.

All das was dort beschrieben ist, ist natürlich nicht für den DAU als Zielgruppe gedacht, jedoch ist das schon recht low level geschrieben.

Aufwändig ist das wirklich nicht. Das ließt sich nur so. Machst du das 1-2x wirst Du feststellen, dass angefangen vom leeren System, über die Hypervisor & VM Einrichtung, OSX installation, passthrough, bis schlussendlich zum funktionierenden Gesamtsystem max. 1,5h vergangen sind.

Zitat von MacPeet

Sorry, ich sehe da leider noch nicht den Vorteil oder Nutzen in irgendeiner Form, im Vergleich zu dem kleinen OC-Bootloader, wo mehrere Systeme dann nebeneinander nativ booten, sofern die Einstellungen passen.

Hier werden Abhängigkeiten zum Bootloader angesprochen, wobei die Abhängigkeit zur VM-Soft nix anderes ist.

Ich verstehe die Analogie nicht.

Zu nah möchte ich dir nicht treten, denn ich bin mir unsicher wo ich bei dir andocken kann. Isf. bin ich mir unsicher ob Du den Sinn und Zweck einer virtualisierten Umgebung verinnerlicht hast?

Ein Bootloader mit einem Hypervisor zu vergleichen ist nicht sinnvoll

Auch gibt es viele Unterschiede zwischen Typ1 oder eher im consumer Segment beheimateten Typ2 Hypervisor.

Evtl. würde der sinnvollere Weg sein, falls von nöten, in die Welt der virtualisierten Infrastrukturen einzutauchen, Lösungsansätze anzuschauen und zu überlegen welche Möglichkeiten sich historisch gewachsenen fat client handling eröffnen.

Erst dann, runtergebrochen auf die eigenen Bedürfnisse, glaube ich, realisiert man die wirklichen Vorteile dieses handlings.

Hier würde ich dich auf das Netz verweisen, ich kann diese grundlegende Arbeit leider nicht übernehmen.

Zitat von MacPeet

Wenn Du so ganz ohne extra Kext's auskommen willst, wie verhält es sich dann mit spezieller Hardware, wie z.B. Onboard-Audio, was ja bekanntlich nicht nativ zu macOS ist? Welche Device-ID wird hier in der VM übergeben, damit es gehen soll?

Ferner, was ist mit WLAN/BT-Lösungen, sofern nicht gerade Apple-nativ verbaut ist? In beiden Fällen sehe ich leider nichts dazu auf den Bildern, bzw. in der Anleitung.

Kann ich jegliche Hardware mittels Device-ID an VM mit Deiner Lösung fit für macOS machen? In Deiner Anleitung klingt das alles so easy.

Ich hindere niemanden daran mit kext files zu operieren. Was ich erwähnte ist, dass es im Vergleich zu herrkömmlichen Prozedur, nicht notwendig ist um ein voll funktionsfähiges System anhand meines Beispiels hinzubekommen.

Natürlich ist das kein Rezept das für jede Art von Materie gilt. Ich denke dass sollte selbstverständlich sein, wie auch die Tatsache dass jeder der einen Hackintosh seitens der Hardware aufbaut sich aus Eigenantieb zuvor auch informiert,

welche Harware Komponente mehr oder minder kompatibel ist. Idealerweise um es sich nicht selbst unnötig schwer zu machen, baut man solche Systeme (isf. modular) meist eh nah am Apple Äquivalent.

So auch vor 5 Jahre mit meinem System geschehen. Das habe ich dort auch so erwähnt. Wie es sich jetzt für jemanden darstellt der mit irgend einer Nvidia irgendwas Karte daher kommt und passthrough betreiben will, nun da muss er

mal den VMware compatibility chart und OSX native Ausführungsschicht bemühen um zu erfahren ob das so funktioniert. Aber nichts anderes passiert bei jedem der sich auf die Thematik "Hackintosh" einlässt, täglich auch.

Für sich sollte man erstmal klären wozu brauche ich passthrough, wie will ich das Ganze einsetzen und welche Komponenten (falls möglich) konfiguriere ich so, und welche überlasse ich als virtuelle Komponente dem handling der VM?

Du darfst nicht missverstehen, ein Hypervisor egal welcher Typ ist Wunderkugel wo alle consumer Komponenten aufgefangen und nutzbar sind. Die Zielgruppe insb. bei Typ 1 sind eher Server in Infrastrukturen.

Mit on-board Audio oder BT wirst du da keinen Host finden. Ein ESXi kann auf Consumer Hardware laufen gelassen werden. dass bedeutet aber noch lange nicht das alles was verbaut ist, auch nutzbar ist.

Zwecks Kompabilität gibt es eine nette Datenbank von VMware: https://www.vmware.com/resources/compatibility/search.php

Die Device IDs haben erstmal damit gar nichts zutun. Wie aus meinem Dokument hervor geht ist das nur eine Methode um ESXi in Sinne der HID die Hoheit zu entreissen, und sie fürs passthrough nutzbar zu machen.

Denn ein Hypervisor sieht i.d.R. nicht vor, ein passthrough für HID wie Maus und Tastatur, oder beispielsweise CCID wie Chipkartenleser USB Geräte zu erlauben.

Zitat von MacPeet

LAN deaktivieren und passende Karte einbauen hilft ja auch nicht jedem User, der diese Anleitung mit anderer Hardware nutzen möchte, denke ich.

Auch hier verweise ich gerne nochmal auf den VMware link. Das war bei mir wie beschrieben notwendig, da der on-board NIC nicht unterstützt wurde und somit verhindert hätte eine ESXi Installation vorzunehmen.

Ein funktionierender NIC ist das mindeste. Normalerweise werden in Infrastrukturen dutzende physikalische pro Host genutzt und dann noch virtualisiert (NSX).

Ein anderen Nutzer empfehle ich entweder sich vorher mit der Datenbank zwecks Kompabilität vertraut zu machen oder auf blöd einfach eine installation zu wagen um spät. dann einen Hauch von Antwort zu bekommen.

Zitat von MacPeet

Ich will die Anleitung gar nicht kritisieren, falls es so verstanden wird, ich frage mich nur, ob ein anderer User, mit z.B. einem Laptop, auch diese Sache voll nutzen kann, auch wenn nicht alle Hardware speziell austauschbar ist.

Alles gut.

Ich denke ein Notebook ist wohl auch irgendwie damit zu bespaßen, nur ist es Zielführend -> sicherlich nicht. Hier sehe ich noch nicht mal den Ansatz auf einer Spielwiese in Homelab Umgebungen.

Mind ein Desktop mit ordentlich Bums sollte es schon sein. Nochmal, eigentlich ist es für Server Infrastrukturen gedacht. Evtl. hilft dir der oder weiterführende Anlaufpunkte irgendwie weiter: https://www.vmware.com/de/products/esxi-and-esx.html

Zitat von MacPeet

Diesen Umstand finde ich ziemlich umständlich, nativ ist anders.

Hier geht es nicht um consumer satisfaction oder user experience, sondern das ist best practice um dem Server ein Wartungszyklus in Sinne eines nicht üblichen power cycles zu ermöglichen.

Solche Systeme laufen i.d.R. 24/7/365. Ich glaube du siehst das alles zu sehr aus der Brille des Endkunden und fat-client Nutzer.

Sicherlich ist das bestimmt auch via script für div. Szenarien irgendwie automatisierbar, nur ob manuell oder automatisiert, obsolete wird es dadurch nicht.

Im Forum gibt es viele Bereiche (Grau) und Subthema.

Runtergebrochen auf die Umsetzung von OSX bezieht sich bisher alles auf fat-clients.

Was hier fehlt ist ein gänzllich neuer Bereich "OSX in virtualisierten Umgebungen bzw. Infrastrukturen"

Ich habe ein umfangreiches HowTo zu Aufbau eines Typ 1 Hypervisors (ESXi) samt passthrough aufgesetzt.

M.M. erfordert dieses zunehmende Thema ein eigenen Bereich in der knowledgebase (Forum), so dass dort threads erstellt und gefunden werden können, die ansonsten in anderen Bereiche untergehen, bzw. deplatziert wären.

Danke!

Gut, jedem das Seine. Proxmox stellt für mich keine wirkliche Alternative zu ESXi dar. Zudem meine komplette Infrastruktur bis auf die Storage Systeme aufs VMware Ecosystem aufbauen, und es auch grundsätzliche Überschneidungen in Sinne der Arbeit gibt.

Deshalb passthrough.

Kann sein, muss aber nicht. Runtergebrochen auf einen herrkömmlichen fat-client eröffnet eine Typ 1 Virtualisierung mehr parallele Flexibilität sowie Sicherungs- & Rolloutdynamik in einer Topologie die nicht hops geht, wenn das guest OS (in dem Fall OSX) die Grätsche macht.

Da bin ich sofort bei dir.

Ich habe mir mal das board angeschaut, aber finde keine wirklich treffende Ecke.

Meiner Meinung fehlt im Forum ein ganz neuer Bereich für "OSX in virtualisierte Umgebungen bzw. Infrastrukturen".

Ansonsten würde das irgendwo verbuddelt wo das niemand mehr finden wird, wie etwa hier.

Und das ist nicht Sinn einer knowledgebase.

Wenn wer so einen neuen Bereich erstellen könnte, würde ich dort einen eigenen thread eröffnen so dass der hier ruhen gelassen werden kann.

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.

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 kaneske

"Schwurbelei"

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

=> gerne!