UTM - Virtuelle Maschinen für iOS und macOS

 (github.com/utmapp)
3 Punkte von GN⁺ 2023-09-02 | 1 Kommentare | Auf WhatsApp teilen
  • UTM ist ein Systememulator und Host für virtuelle Maschinen, der auf iOS und macOS läuft und auf QEMU basiert. Damit lassen sich Windows, Linux und mehr auf Mac, iPhone und iPad ausführen.
  • Mit vollständiger Systememulation auf Basis von QEMU werden MMU und Geräte abgebildet; unterstützt werden mehr als 30 Prozessoren, darunter x86_64, ARM64 und RISC-V.
  • Der VGA-Grafikmodus verwendet SPICE und QXL; unterstützt werden außerdem Textterminal-Modus, USB-Geräte und JIT-Beschleunigung auf Basis von QEMU TCG.
  • Als Frontend für macOS 11 und iOS 11+ können auf dem Gerät VMs erstellt, verwaltet und ausgeführt werden.
  • Unter macOS wird hardwarebeschleunigte Virtualisierung mit Hypervisor.framework und QEMU unterstützt; unter macOS 12+ können mit Virtualization.framework macOS-Gäste gebootet werden.
  • UTM SE ist die „slow edition“, die sich unter iOS wie eine normale App ohne Jailbreak oder JIT-Umgehung sideloaden lässt, und verwendet einen threaded interpreter, der schneller als ein traditioneller Interpreter, aber langsamer als JIT ist.
    • UTM/QEMU benötigt für maximale Leistung dynamische Codegenerierung (JIT), und auf iOS-Geräten erfordert JIT einen Jailbreak oder spezielle Umgehungsmethoden für bestimmte iOS-Versionen.
    • UTM SE enthält zur Optimierung von Größe und Build-Zeit nur die Architekturen ARM, PPC, RISC-V und x86, jeweils in 32-Bit- und 64-Bit-Varianten.
  • Installationshinweise für UTM und UTM SE unter iOS gibt es unter https://getutm.app/install/ , UTM für macOS gibt es unter https://mac.getutm.app/.
  • Die Distribution erfolgt unter der Apache-2.0-Lizenz, verwendet aber verschiedene (L)GPL-Komponenten; bei einer Weiterverbreitung ist zu beachten, dass gstreamer-Plugins statisch gelinkt sind und Teile des Codes aus qemu übernommen wurden.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-02
Meinungen auf Hacker News

  • Vor ein paar Wochen habe ich versucht, auf einem neuen M2 mit macOS Ventura Windows 11 ARM mit UTM zu installieren, um Fusion zu ersetzen, und war enttäuscht.
    Integrationswerkzeuge wie Kopieren/Einfügen oder File Sharing zwischen virtueller Maschine und Host funktionierten nicht, und die Grafik war ständig fehlerhaft und wechselte häufig zu einem grauen Bildschirm.
    Es schien keine Möglichkeit zur Wiederherstellung zu geben, sodass ich die virtuelle Maschine hart neu starten musste, und die Treiber/Hilfswerkzeuge waren ebenfalls auf 2012 datiert.
    Da es ein kostenloses Produkt ist, hat man keinen Anspruch auf Erwartungen, und ich bin tatsächlich zu Fusion zurückgekehrt. Aber aus der Perspektive von jemandem, der gehofft hatte, eine kommerzielle Virtualisierungslösung durch Open Source zu ersetzen, ist es dafür meiner Meinung nach noch schwierig.

    • Kopieren/Einfügen funktioniert definitiv. Ich nutze es den ganzen Tag hin und her. Man sollte prüfen, ob die SPICE Tools installiert sind.
      https://docs.getutm.app/guest-support/windows/#windows-xp-an...
      Grafikfehler habe ich auch noch nicht gesehen, aber ich versuche nicht zu spielen und nutze nur einfache Desktop-Apps.
    • Ich nutze UTM als ziemlich guten QEMU-Wrapper, und wenn man es so behandelt, ist es großartig.
    • Ich frage mich, ob Kopieren/Einfügen und Shared Folders in Fusion mit einer Windows-ARM-VM funktionieren. Als ich zuletzt nachgesehen habe, unterstützten die VMware Tools diese Funktionen noch nicht.
      Korrektur: Fusion 2023 Tech Preview [1] installiert die vollständigen VMware Tools und unterstützt Kopieren/Einfügen.
      1. https://customerconnect.vmware.com/downloads/get-download?do...
    • Nicht überraschend. Denn OpenGL funktioniert nicht. Wenn man bedenkt, wie viele Apps heutzutage OpenGL verwenden, macht das es ziemlich wenig brauchbar.
    • Eine Verbindung über das MS-RDP-Tool könnte sich besser anfühlen.

  • UTM ist hervorragend, und wenn eine Snapshot-Funktion hinzukommt [1], würde ich es wohl zur Standardempfehlung machen. Bis dahin werde ich weiter Parallels nutzen.
    Zur Info: Es gibt einen inoffiziellen Snapshot-Manager [2].
    1: https://github.com/utmapp/UTM/issues/5484
    2: https://github.com/Metamogul/UTM-Snapshot-Manager

    • Ich habe mir angewöhnt, in einer virtuellen Maschine statt auf dem eigentlichen System zu entwickeln, und habe UTM lange genutzt, um auf einem M1 MacBook Pro eine ARM64-Linux-VM laufen zu lassen, aber File-Sharing-Probleme haben mich ständig geplagt.
      Das häufigste Problem war, dass der Shared Folder in der Gast-VM plötzlich verschwand und ich häufig Workarounds nutzen musste, um ihn zurückzubringen.
      Danach hatte VMware Fusion dasselbe Problem, und Parallels wirkte zu teuer, also bin ich zu Lima gewechselt.
      Ich bin froh, Lima entdeckt zu haben. Es basiert ebenfalls auf QEMU, macht das Starten von Linux-VMs einfach und bringt Network Sharing standardmäßig mit.
      Jetzt erledige ich die gesamte Entwicklung in Lima-VMs und hatte keine Probleme. Falls nötig, könnte ich wohl auch Bildschirmausgabe weiterleiten, aber dank VSCode reicht mir derzeit eine Headless-Instanz.
    • APFS unterstützt bereits Copy-on-Write-Snapshots für alle Dateitypen. Die Snapshot-Funktion von UTM dürfte vermutlich eine Hülle um diese Funktion sein.
      Es könnte so einfach sein wie cp -c.
      Allerdings denke ich auch: Wenn es wirklich so wäre, wäre es wohl schon implementiert.
    • Ich wollte gerade sagen, dass ich mit clonefile erfolgreich eine eingeschränkte Form von Snapshots nachgebildet habe, aber die laufende Implementierung verwendet offenbar genau diesen Ansatz.
    • Ich frage mich, ob TPM-Emulation sowie ansible/vagrabt unterstützt werden.

  • Das größte Problem von UTM ist, dass es bei manchen Leuten sehr gut funktioniert und bei anderen furchtbar.
    Wenn man sich die Threads auf dieser Seite von oben bis unten ansieht, gibt es gleichzeitig viele Aussagen wie „Ich würde UTM gern nutzen, aber es funktioniert nicht oder ist unbrauchbar langsam“ und Antworten wie „Komisch, bei mir läuft es“.
    In meinem Fall hat UTM buchstäblich kein einziges Mal richtig funktioniert. Ich habe versucht, auf einem M1-Mac von 2021 eine standardmäßige Ubuntu-ARM-Installation nach der Anleitung unter https://docs.getutm.app/guides/ubuntu/ durchzuführen, aber es ist fehlgeschlagen, und jetzt sehe ich nur einen schwarzen Bildschirm mit blinkendem Cursor.
    Leider können die Leute, bei denen es funktioniert, denen, bei denen es nicht funktioniert, kaum echte technische Unterstützung geben.
    Ich habe im Mac App Store sogar 10 Dollar für UTM bezahlt, aber der einzige Support-Kanal ist Discord, und dort gab es viele Reaktionen wie „lol, bei mir geht’s, Skill Issue“.
    Als Empfehlung: UTM ist einen Versuch wert. Wenn es dir gefällt, kannst du viel Geld sparen; wenn es wie bei mir überhaupt nicht funktioniert, musst du am Ende Parallels für 100 Dollar pro Jahr bezahlen. Parallels wird wahrscheinlich einfach funktionieren.
    Wenn Parallels nicht funktioniert, kannst du direkt mit einem Unternehmen sprechen, das einen Anreiz hat, dich zur Verlängerung der Lizenz zu bewegen, und motiviert ist, dir zum Erfolg zu verhelfen.

    • Ich habe das aktuelle Debian von der Website ausprobiert, und bis auf ein seltsames Problem gab es keine Schwierigkeiten.
      Wenn man die Boot-VM-Disk über eine bestimmte Größe hinaus festlegt — ich glaube, es war nicht einmal sehr groß, etwa 30 GB bis 100 GB —, wird der Start der VM sehr langsam.
      Wenn man sie groß genug anlegt, bootet sie überhaupt nicht. Das Hinzufügen eines zweiten Laufwerks beliebiger Größe löst diesen Bug nicht aus.
    • Es gibt auch VirtualBox.

  • Ich habe von der Firma ein M1 MacBook Pro bekommen, entwickle aber alles unter Linux. Seit Ende der 90er war Linux meine bevorzugte Umgebung.
    Die Hardware des MacBook Pro ist gut, aber macOS wirkt träge und einengend, wodurch meine Produktivität deutlich sinkt.
    Deshalb lasse ich in UTM Fedora aarch64 im Vollbild laufen. Das funktioniert ziemlich gut, und ich vergesse oft, dass es auf einem Mac läuft.
    Ich wünschte nur, macOS würde nicht dazwischenfunken und mich nicht gelegentlich aus dem Vollbildmodus werfen.

    • Fedora Asahi Linux werde ich sicher im Auge behalten.
    • Der Wechsel von Linux zu macOS läuft am Ende darauf hinaus, sich mit den Problemen von macOS abzufinden und anzupassen oder sie mit Drittanbieter-Lösungen erträglicher zu machen. Man macht auch von beidem ein bisschen.
      Ich habe mich angepasst, weil ich die verlässliche Akkulaufzeit nicht missen wollte.
      Irgendwo gibt es vielleicht eine Lösung, die den Vollbildmodus beibehält.
    • Mich würde interessieren, was genau die Produktivität senkt. Wenn ich auf dem Mac ein bash-Terminal öffne und nutze, fühlt es sich fast wie Linux an.
      Gelegentlich unterstützt ein Utility vertraute Kommandozeilenargumente nicht, aber das ist eher ein Versionsunterschied als ein Mac/Linux-Problem, und ich habe das auch schon mehrfach erlebt, wenn ich innerhalb der Firma auf andere Geräte gewechselt bin.
      Der größte Ärger, auch wenn er nicht riesig ist, ist der Unterschied zwischen ARM und x86. Ab und zu stößt man auf Pakete, die auf ARM nicht unterstützt werden, aber das wird immer seltener.
    • Mich würde interessieren, wie hoch der Leistungsverlust bei dieser Nutzung ausfällt. Wenn er nicht groß ist, wirkt das wie eine gute Lösung.
    • Asahi Fedora soll in ein paar Tagen erscheinen. Es gibt Hoffnung.

  • UTM war in den letzten zwei Jahren für mich ein stabiler Hypervisor und hat in dieser Zeit auch mehrere gute Funktionsverbesserungen erhalten.
    Was mir an UTM aber am besten gefällt, ist, dass es für Universal Turing Machine steht. Als Name für ein Virtualisierungsprodukt ist das meiner Meinung nach fast unschlagbar.

  • Was ich an Parallels und VMWare nicht mag, ist, dass sie die Integration zwischen Betriebssystemen zu stark forcieren. Zum Beispiel Windows-Fenster unter macOS zu öffnen oder macOS-Dokumente direkt in Windows zu öffnen.
    Ich bevorzuge es, wenn eine virtuelle Maschine vom primären macOS isoliert ist. Deshalb muss ich mich immer durch die Einstellungen wühlen und herausfinden, was ich abschalten muss.

    • In Parallels gibt es im Tab für Sicherheitseinstellungen eine einzelne Option namens „Isolate VM from macOS“. Sie deaktiviert alle gegenseitigen Integrationen.
    • Ich erinnere mich daran, als ich Parallels installiert hatte. Jedes Mal, wenn ich auf eine Datei doppelklickte, versuchte es ständig, sie mit Notepad unter Windows zu öffnen.

  • Ich weiß, dass in der GitHub-Projektbeschreibung „for iOS“ steht, halte das aber für eine ziemlich irreführende Formulierung.
    Die Installationsoptionen für iOS bedeuten im Wesentlichen entweder Jailbreak, eine Methode, die auf aktuellen CPU-/iOS-Versionen nicht möglich ist, oder man muss die App in einem semi-tethered Zustand alle paar Tage erneut laden/signieren.
    https://docs.getutm.app/installation/ios/#summary

    • Wenn man ein Apple-Developer-Konto hat, kann man eine App sideloaden, die ein Jahr lang gültig bleibt. Ich nutze es so.
    • Früher habe ich eine App namens reprosion ausprobiert; damit kann man die Signierung auf dem iOS-Gerät erledigen und sogar automatisieren. Ich habe sie genutzt, als ich einen semi-tethered Jailbreak aufgespielt habe, und die Grenze liegt bei 7 Tagen.
      Die App selbst muss man nicht neu installieren, nur das Signaturzertifikat erneuern.
      Ich freue mich darauf, dass es deutlich einfacher wird, wenn Sideloading im EWR umgesetzt wird.
    • Wenn man bedenkt, dass „Jailbreak in aktuellen Umgebungen nicht möglich ist“, ist das beeindruckend.
      Apple hat erfolgreich Hardware gebaut, die an über eine Milliarde Menschen ausgeliefert werden kann, und obwohl viele davon durch Jailbreak etwas gewinnen würden, hat es niemand geschafft.
    • Wenn das Ziel nur App-Sideloading ist, kann man die semi-tethered Methode sogar als weniger dubios ansehen als einen Jailbreak.
      Es funktioniert zwar auch ohne diese Methode, ist aber von den drei Ausführungsarten die langsamste.
    • Ich will schnell sehen, wie EU-Sideloading funktionieren wird. Hoffentlich wird es richtig umgesetzt.

  • Wenn man auf dem Mac eine virtuelle Maschine für eine Entwicklungsumgebung betreibt, ist OrbStack das, was man will: https://orbstack.dev/

    • Nach Ende der Beta soll es für kommerzielle Nutzung 8 US-Dollar pro Entwickler und Monat kosten.
    • Für die meisten Anwendungsfälle dürften Lima und Colima ausreichen.
      https://lima-vm.io/
      https://github.com/abiosoft/colima
    • Für ein Tool, das seine Vorteile mit Formulierungen wie der folgenden herausstellt, fällt die fehlende vagrant-Unterstützung auf:

      Für jeden Anwendungsfall bietet OrbStack Funktionen, die Ihren Workflow vereinfachen und Ihnen helfen, schneller voranzukommen

    • Ich frage mich, ob man damit komplexe Netzwerkkonfigurationen erstellen kann. Mein größter Kritikpunkt an UTM ist, dass man einer virtuellen Maschine nur ein einziges Netzwerkinterface geben kann.

  • Mir wurde Lima empfohlen; es ist ein wenig wie WSL2 für macOS: https://lima-vm.io
    Ich weiß nicht genau, was es intern verwendet, aber bei mir hat es sehr gut funktioniert.

    • Beim Erstellen einer virtuellen Maschine kann man zwischen QEMU und Virtualization.framework wählen.
      colima ist eine Schicht auf Lima, die im Stil von docker-machine/boot2docker virtuelle Maschinen einfach einrichtet.

  • UTM ist für grundlegende Zwecke großartig, aber die Performance war so schlecht, dass es für den Alltagseinsatz als Hauptwerkzeug nicht wirklich realistisch war.
    Auf dem Mac kommt nichts an Parallels heran, und es ist sein Geld absolut wert.

    • Wenn man auf Apple Silicon eine x86-VM betreibt, stimme ich zu, dass die Performance miserabel ist. Ich bin ziemlich sicher, dass das weniger UTM anzulasten ist, sondern eher ein QEMU-Problem ist.
      Wenn die virtuelle Maschine aarch64 ist, ist die Performance überraschend gut, und ich kann UTM sehr empfehlen.