Mehr als zwei macOS-VMs auf Apple Silicon: das Limit, die Mythen und was wirklich funktioniert

Wer auf einem Apple-Silicon-Mac ernsthaft mit virtuellen Maschinen arbeitet, stößt irgendwann an eine unsichtbare Wand: Die dritte macOS-VM startet nicht. Zwei laufen anstandslos parallel, bei der dritten bricht der Start mit einer Fehlermeldung ab. Das ist kein Bug und kein Ressourcenproblem. Es ist ein bewusst gesetztes Limit, und es sitzt an einer Stelle, an der die meisten es nicht vermuten.

Dieser Artikel erklärt, wo das Limit technisch wirklich verankert ist, warum die naheliegenden Umgehungsversuche allesamt scheitern, und welche zwei Wege tatsächlich funktionieren, wenn man mehr als zwei macOS-Gastsysteme gleichzeitig braucht. Einen für die eigene Maschine, einen für den produktiven Einsatz.

Was genau passiert, wenn die dritte VM startet

Der Start einer macOS-VM läuft über Apples Virtualization Framework. Beim Versuch, die dritte gleichzeitig laufende macOS-VM zu starten, wirft das Framework einen Fehler mit dem Code VZErrorVirtualMachineLimitExceeded (Domain VZErrorDomain, Code 6). Die Klartext-Meldung lautet schlicht: "The number of virtual machines exceeds the limit."

Wichtig ist die Formulierung: Es geht um gleichzeitig laufende macOS-Gäste, nicht um die Anzahl angelegter VMs. Man kann beliebig viele macOS-VMs auf der Platte haben und konfigurieren. Aber nur zwei dürfen gleichzeitig booten. Ebenso wichtig: Das Limit betrifft ausschließlich macOS-Gäste. Linux-Gastsysteme sind davon gar nicht erfasst. Von denen laufen so viele parallel, wie der Arbeitsspeicher hergibt.

Der entscheidende Punkt: Das Limit steckt im Kernel

Die intuitive Annahme lautet: Wenn das Virtualization Framework den Fehler wirft, dann sitzt die Zählung im Framework oder im zuständigen Systemdienst virtualizationd — also in Software, die man theoretisch umbiegen könnte. Diese Annahme ist falsch, und genau daran scheitern fast alle Umgehungsversuche.

Reverse-Engineering-Arbeiten (allen voran die detaillierte Analyse von Mykola Grymalyuk / khronokernel aus 2023) haben die tatsächliche Mechanik offengelegt. Das Limit ist eine globale Ganzzahl-Variable im geschlossenen XNU-Kernel:

• hv_apple_isa_vm_quota — der Zähler, Standardwert 2.
• hv_trap_vm_create() — der Hypercall, der beim VM-Start das Kontingent belegt.
• hv_vm_destroy_0() — gibt das Kontingent beim Stoppen wieder frei.

Weil dieser Zähler eine einzelne globale Kernel-Variable ist, die im Hypervisor-Hypercall selbst ausgewertet wird, gilt das Limit systemweit pro Host — nicht pro Prozess und nicht pro Benutzer. Zwei verschiedene Apps teilen sich denselben Zähler; auch schnelles Umschalten zwischen Benutzerkonten hilft nicht. Der Fehler VZErrorVirtualMachineLimitExceeded, den man auf App-Ebene sieht, ist nur der Bote. Die eigentliche Ablehnung passiert eine Ebene tiefer, im Hypervisor.

Der Grund für das Limit ist kein technischer, sondern ein lizenzrechtlicher: Apples Software License Agreement erlaubt den Betrieb von bis zu zwei zusätzlichen macOS-Instanzen in VMs auf Apple-Hardware. Der Kernel-Zähler ist die technische Durchsetzung genau dieser Klausel. Ein Mac Studio mit reichlich RAM könnte problemlos mehr macOS-VMs stemmen. Die Grenze ist eine Richtlinie, kein Hardware-Engpass.

Warum die naheliegenden Tricks nicht funktionieren

Sobald klar ist, dass die Durchsetzung im Kernel liegt, fällt eine ganze Klasse von Ideen in sich zusammen. Der Reihe nach:

Das Framework oder virtualizationd patchen

Die Idee, per Code-Injection den Fehler VZError Code 6 abzufangen oder die Zähllogik in der Framework-Bibliothek umzubiegen, geht am eigentlichen Problem vorbei. Man würde bestenfalls die Fehlermeldung unterdrücken — der darunterliegende Hypercall hv_trap_vm_create() gibt weiterhin einen Fehler zurück, und es entsteht keine dritte VM, sondern nur eine verschluckte Fehlermeldung ohne VM dahinter. Dazu kommt: Jede seriöse VM-App läuft mit Hardened Runtime und Library Validation, und System Integrity Protection (SIP) verbietet das Injizieren in Apple-Systemprozesse ohnehin. Gleiches gilt für virtualizationd: Der Dienst ist SIP-geschützt und hält den Zähler gar nicht selbst.

Ein Entitlement fälschen

Es existiert schlicht kein Entitlement, das das Kontingent anhebt. Das reale Virtualisierungs-Entitlement schaltet nur den Zugriff auf das Framework überhaupt frei, nicht die Anzahl. Ein "unlimitiertes" Entitlement zu erfinden und die App neu zu signieren, scheitert an der Notarisierung und an AMFI (Apple Mobile File Integrity) — es sei denn, man deaktiviert AMFI, was wiederum den ganzen Rechner in einen ungesicherten Zustand versetzt.

QEMU statt Virtualization Framework

QEMU nutzt die tieferliegende Hypervisor.framework-Schnittstelle und ist für Linux- und Windows-Gäste tatsächlich nicht limitiert. Für macOS-Gäste hilft es trotzdem nicht: QEMUs experimentelles vmapple-Maschinenmodell bootet nur macOS 12, erfordert aus dem Virtualization Framework extrahierte Apple-Firmware (rechtlich heikel) und stößt — weil die Kernel-Quota unterhalb beider Frameworks sitzt und am macOS-Gasttyp hängt — höchstwahrscheinlich auf dasselbe Limit. Ein moderner macOS-Gast auf QEMU ist heute keine praktikable Option.

Verschachtelte Virtualisierung

macOS 15 Sequoia hat auf M3-und-neuer verschachtelte Virtualisierung eingeführt. Das klingt verlockend — eine VM in der VM, jede mit eigenem Kontingent. In der Praxis ist das Feature aber für Linux-Gäste gedacht (ein Linux-Hypervisor in einer Linux-VM). macOS-in-macOS ist nicht freigegeben, und selbst wenn es liefe, würde es das Zwei-Gäste-Limit nicht legal anheben.

Was wirklich funktioniert — Weg 1: der Kernel-Weg

Es gibt genau eine Methode, die auf einer einzelnen Maschine tatsächlich mehr als zwei macOS-VMs laufen lässt: Man ändert die Quelle des Limits selbst, den Kernel. Weil hv_apple_isa_vm_quota eine Kernel-Variable ist, lässt sie sich über einen Boot-Parameter überschreiben — allerdings ist genau dieser Boot-Parameter auf Release-Kerneln hinter einer AppleInternal-Prüfung (CSR_ALLOW_APPLE_INTERNAL, ein SIP-Flag) gesperrt. Der dokumentierte Weg umgeht das, indem ein Entwicklungs-Kernel aus Apples Kernel Debug Kit (KDK) gebaut und gebootet wird, in dem diese Sperre nicht greift.

Zuerst wird auf dem laufenden System die zum eigenen Build passende Kernel-Variante ermittelt und daraus eine Entwicklungs-Kernel-Collection gebaut. Die KDK-Version und die T-Chip-Variante (z. B. t6020 für M2 Pro/Max) müssen exakt zum Host passen:

# Kernel-Variante des Hosts ermitteln
uname -v | awk -F '/' '{print $NF}' | awk -F '_' '{print $NF}'

# Entwicklungs-Kernel-Collection bauen (KDK-Version + T-Variante anpassen)
sudo kmutil create \
  --arch arm64e \
  --no-authorization \
  --variant-suffix development \
  --new boot \
  --boot-path VirtualMachine.kc \
  --kernel /Library/Developer/KDKs/KDK_14.0_23A5301h.kdk/System/Library/Kernels/kernel.development.t6020 \
  --repository /Library/Developer/KDKs/KDK_14.0_23A5301h.kdk/System/Library/Extensions \
  --repository /System/Library/Extensions \
  --repository /System/Library/DriverExtensions \
  --explicit-only $(kmutil inspect -V release --no-header | grep -v "SEPHiber" | awk '{print " -b "$1; }')

Anschließend wird in der Recovery-Umgebung die Sicherheit abgesenkt, die gebaute Collection als Boot-Kernel gesetzt und der Boot-Parameter geschrieben, der das Kontingent anhebt:

# In der recoveryOS ausfuehren
csrutil disable
bputil --disable-boot-args-restriction
kmutil configure-boot \
  --volume /Volumes/Macintosh\ HD \
  --custom-boot-object /Volumes/Macintosh\ HD/Users/*/VirtualMachine.kc

# Kontingent auf 255 anheben (Maximum ist 0x7FFFFFFF)
nvram 40A0DDD2-77F8-4392-B4A3-1E7304206516:boot-args='kcsuffix=development hypervisor=0x1 hv_apple_isa_vm_quota=0xFF'

Die drei Boot-Parameter bedeuten: kcsuffix=development wählt die Entwicklungs-Kernel-Variante, hypervisor=0x1 schaltet die erweiterten Virtualisierungs-Funktionen frei, und hv_apple_isa_vm_quota=0xFF setzt das Kontingent auf 255. Nach dem Neustart läuft der Rechner mit dem angehobenen Limit. In der ursprünglichen Demonstration liefen so neun macOS-VMs gleichzeitig auf einem M2 Pro (mit dem Nebeneffekt, dass zum ersten Mal der Lüfter ansprang).

Vor einem macOS-Update sollte man auf den Standard-Kernel zurücksetzen, sonst schlägt das Update fehl:

# In der recoveryOS: volle Sicherheit wiederherstellen
bputil --full-security

Die genauen Befehle und aktuelle Feinheiten dokumentiert der Original-Beitrag von khronokernel — die maßgebliche Quelle zu diesem Thema. Da Apple KDKs und Kernel mit jeder Version ändert, lohnt vor jedem Versuch ein Abgleich mit dem dortigen Stand.

Der Clou: Nemeton und andere VM-Apps ziehen automatisch mit

Ein oft übersehener Punkt: Das Limit war nie in der VM-App. Nemeton etwa ruft nur den Standard-Startaufruf des Virtualization Frameworks auf. Bislang warf dieser Aufruf bei der dritten VM den Kernel-Fehler; auf einem Kernel mit angehobenem hv_apple_isa_vm_quota gibt derselbe Aufruf einfach "in Ordnung" zurück. Die App braucht dafür keine einzige Codeänderung — sie startet ganz von selbst die dritte, vierte, fünfte VM, weil im Code gar keine Zählsperre existiert. Das Limit lag immer nur im Kernel darunter.

Real begrenzen dann nur noch die Hardware (jede macOS-VM will mehrere Gigabyte RAM) und ein bekannter Nebenaspekt: Der Zähler leakt gelegentlich. Fährt ein Gast unsauber herunter oder stürzt ab, wird der belegte Slot manchmal nicht freigegeben — dann scheitert sogar der nächste reguläre Start, bis man sich ab- und wieder anmeldet oder neu startet. Gut zu wissen, wenn plötzlich schon die zweite VM streikt.

Was wirklich funktioniert — Weg 2: horizontal skalieren

Der Kernel-Weg ist mächtig, aber er passt nur auf die eigene Werkbank: SIP aus, Neubau bei jedem Update, kein Ausrollen an Dritte. Für den produktiven, wartbaren Einsatz gibt es einen zweiten Weg, der Apples Durchsetzung nicht bekämpft, sondern respektiert — und trotzdem beliebig skaliert: mehrere Macs, je zwei VMs, gesteuert aus einer Oberfläche.

Zwei macOS-VMs pro physischem Apple-Silicon-Host sind vollständig innerhalb der Lizenz (für Entwicklung, Test und CI). Kapazität fügt man hinzu, indem man Hosts hinzufügt: Fünf Mac minis ergeben zehn parallele macOS-VMs, zehn Hosts zwanzig. Eine zentrale Steuerungsebene übernimmt Platzierung, Bereitstellung, Lebenszyklus und Verteilung der VM-Images über die Flotte. Genau dieses Muster betreiben spezialisierte Mac-Cloud-Anbieter seit Jahren produktiv.

Der Charme dieses Wegs: keine abgesenkte Sicherheit, kein Custom-Kernel, kein Bruch bei macOS-Updates, signiert und notarisiert. Es ist normale verteilte-Systeme-Arbeit statt fragiler Kernel-Bastelei — und damit der einzige Weg, der sich sauber über die eigene Werkbank hinaus tragen lässt.

Häufige Fragen

Wie viele macOS-VMs kann ich gleichzeitig auf Apple Silicon laufen lassen?
Standardmäßig zwei. Apples Virtualization Framework erlaubt maximal zwei gleichzeitig laufende macOS-Gastsysteme pro Mac. Angelegte VMs darf es beliebig viele geben — nur die Zahl der gleichzeitig gestarteten ist auf zwei begrenzt. Linux-Gäste sind von diesem Limit nicht betroffen.

Warum startet meine dritte macOS-VM nicht?
Weil das Zwei-VM-Limit erreicht ist. Der Start bricht mit dem Fehler VZErrorVirtualMachineLimitExceeded (VZErrorDomain, Code 6) ab: "The number of virtual machines exceeds the limit." Das ist kein Bug und kein Ressourcenproblem, sondern ein bewusst gesetztes Limit im macOS-Kernel.

Gilt das Limit auch für Linux-VMs?
Nein. Das Limit betrifft ausschließlich macOS-Gastsysteme. Linux-VMs können so viele parallel laufen, wie Arbeitsspeicher und CPU hergeben.

Lässt sich das Zwei-VM-Limit umgehen?
Nur auf zwei Wegen. Reine Software-Tricks auf App- oder Framework-Ebene scheitern, weil das Limit im XNU-Kernel sitzt (Variable hv_apple_isa_vm_quota). Tatsächlich funktionieren nur ein Custom-Entwicklungs-Kernel mit angehobenem Kontingent (nur auf eigener Hardware, mit deaktiviertem SIP, bricht bei jedem Update) oder horizontale Skalierung über mehrere Macs mit je zwei VMs.

Betrifft das Limit auch UTM, Parallels oder QEMU?
Für macOS-Gäste ja. UTM und Parallels nutzen für macOS-VMs Apples Virtualization Framework und stoßen auf dasselbe kernelseitige Limit. QEMU ist nur für Linux- und Windows-Gäste unbegrenzt; ein moderner macOS-Gast auf QEMU ist derzeit keine praktikable Option.

Fazit

Das Zwei-VM-Limit auf Apple Silicon ist real, es sitzt im Kernel, und keine reine Software-Umgehung auf App- oder Framework-Ebene kann es aushebeln — wer den Fehler nur unterdrückt, bekommt keine dritte VM, sondern gar keine. Wer mehr braucht, hat zwei ehrliche Optionen: den Kernel-Weg für die eigene Maschine (mächtig, aber SIP-los und update-fragil) oder horizontale Skalierung über mehrere Hosts (robust, wartbar, lizenzkonform für Dev und Test). Welcher der richtige ist, entscheidet der Einsatzzweck — nicht ein Trick, der Apple überlistet.

Wer macOS- und Linux-VMs ohnehin nativ über Apples Virtualization Framework verwalten will — mit Snapshots, REST-API und Automatisierung, als Einmalkauf statt Abo — findet in Nemeton die passende App. Auf einem quota-angehobenen Kernel startet sie mehr als zwei VMs ohne jede Anpassung; für den Flottenbetrieb bringt sie mit VM-Migration zwischen Hosts bereits die Bausteine mit.