Installer macOS sur VMware fascine beaucoup d’admins, de devs et de bidouilleurs de homelab. Entre la curiosité technique et les vrais besoins métier (tests Xcode, validation d’apps, support utilisateurs Apple), l’idée de faire tourner macOS dans des machines virtuelles sur un PC Windows ou un serveur ESXi revient souvent. La réalité est plus nuancée : sur le plan technique, VMware facilite la installation virtuelle de macOS, mais sur le plan juridique, la licence Apple encadre sévèrement ce que l’on a le droit de faire, surtout dès qu’on sort du matériel Apple.
Pour s’y retrouver, mieux vaut poser le décor calmement : quels prérequis macOS vérifier avant même de télécharger une image, quelle compatibilité matérielle viser pour éviter une VM qui rame ou qui plante, et surtout, dans quels cas l’usage de VMware pour macOS reste dans les clous. L’article suit un guide étape par étape, mais sans cacher les zones grises : patchs de type Unlocker, images récupérées ailleurs qu’Apple, mix ESXi/Workstation sur hôte non-Apple… tout cela fait partie des sujets qui fâchent sur le plan légal, même si c’est techniquement faisable.
Pour illustrer tout ça, un fil conducteur simple : une petite équipe de devs, chez une PME fictive baptisée « Studio Correzia », qui veut tester des applis macOS sans acheter une flotte complète de Mac. Elle dispose déjà d’un hôte VMware ESXi et d’un poste Windows équipé de VMware Workstation. Leur question est limpide : que peuvent-ils faire proprement, que doivent-ils éviter, et comment monter un environnement propre pour macOS sans transformer leur infra en zone grise permanente.
En bref
- macOS dans VMware est techniquement gérable, mais la licence Apple limite fortement les scénarios hors matériel Apple.
- Les prérequis macOS couvrent à la fois le matériel (CPU, RAM, stockage) et la conformité juridique (provenance de l’ISO, type d’hôte).
- VMware ESXi et VMware Workstation simplifient la configuration VMware, mais nécessitent parfois des patchs comme Unlocker pour voir macOS.
- Un guide étape par étape permet de créer une ISO amorçable macOS Ventura/Sonoma et de monter une VM fonctionnelle.
- Ignorer les limites légales (virtualisation sur PC non-Apple, images non officielles) expose à des risques contractuels, surtout en entreprise.
Prérequis pour installer macOS sur VMware : matériel, ISO et cadre légal
Avant même de cliquer sur « Créer une nouvelle VM », il faut regarder trois fronts en parallèle : le matériel qui héberge VMware, la source de l’image macOS et les conditions posées par la licence Apple. C’est souvent là que les projets comme celui de Studio Correzia se jouent, bien avant les questions de pilotes ou de snapshots.
Côté hôte, la compatibilité matérielle ne demande pas une bête de course, mais quelques seuils pratiques rendent l’installation virtuelle nettement plus confortable. Pour un macOS Ventura ou Sonoma en 64 bits, viser au moins un CPU récent avec support de la virtualisation matérielle (Intel VT-x / AMD-V, souvent actif dans le BIOS/UEFI), 16 Go de RAM sur l’hôte pour pouvoir dédier 4 à 8 Go à la VM, et un stockage SSD correct. En dessous, la VM macOS reste possible, mais les performances font vite regretter d’avoir lancé le projet.
Sur VMware ESXi, la mémoire côté hôte est encore plus sensible. Une PME qui mutualise Exchange, quelques Linux et une VM macOS sur le même cluster voit vite l’impact d’une VM gourmande. Dans les environnements vus chez des clients, macOS qui tourne sur 4 vCPU et 8 Go de RAM reste un compromis honnête pour du test applicatif. En dessous, certains outils de développement Apple deviennent pénibles à utiliser.
Deuxième bloc, l’image d’installation. Pour rester cohérent avec la licence Apple, l’ISO doit venir d’un Mac réel connecté à l’App Store. Les navigateurs Windows ou Linux n’exploitent pas les liens de téléchargement macOS de la même façon ; Apple pousse clairement à récupérer les installeurs depuis un environnement macOS natif. C’est exactement ce que fait Studio Correzia : un Mac Mini « maître » sert uniquement de point de téléchargement, puis de fabrication d’ISO pour leurs tests VMware.
La procédure classique consiste à récupérer, par exemple, « Installer macOS Ventura » ou « Installer macOS Sonoma » dans le dossier Applications, puis à en extraire le contenu avec « Afficher le contenu du paquet ». Dans le répertoire « Contenu/Support partagé », on retrouve InstallESD.dmg, qu’il faut transformer en ISO amorçable. Ce passage par le terminal Apple avec l’outil hdiutil n’est pas glamour, mais reste fiable et documenté.
Dernier bloc, probablement le plus négligé : la dimension juridique. La licence Apple autorise macOS à tourner sur du matériel Apple, avec une tolérance pour la virtualisation sur ce même matériel (typiquement, plusieurs VM macOS sur un Mac Pro ou un Mac Studio). Dès que macOS tourne sur un PC classique, même via VMware ESXi ou Workstation, on sort du cadre contractuel prévu. Studio Correzia le comprend vite : pour rester carré en production, la seule option propre consiste à héberger ESXi sur un Mac ou à utiliser un hyperviseur sur Mac (Fusion Pro, Proxmox sur Mac, etc.). Leur homelab sous Windows, lui, reste un terrain de jeu à risque sur le plan contractuel.
La synthèse est simple : tant que la provenance de l’image macOS est légitime, que le matériel respecte les minima de compatibilité matérielle, et que l’hôte est un Mac pour les environnements sérieux, la base est saine. C’est sur cette base que la suite du tutoriel prend tout son sens.
Créer une ISO macOS amorçable pour VMware : hdiutil, tailles et pièges fréquents
Pour installer macOS sur VMware ESXi ou Workstation, une ISO amorçable fiable change tout. Les images récupérées au hasard sur Internet génèrent des comportements étranges, parfois des kernel panic, parfois des soucis de mises à jour. Mieux vaut prendre une heure pour fabriquer un ISO d’installation macOS propre que perdre une journée à diagnostiquer une VM bancale.
Sur le Mac de Studio Correzia, la première étape consiste à ouvrir le Terminal et à basculer en root avec sudo -i. Puis vient la création d’un disque vide avec hdiutil, par exemple :
hdiutil create -o /tmp/Ventura -size 16384m -volname Ventura -layout SPUD -fs HFS+J
Cette commande prépare une image .dmg de 16 384 Mo, formatée en HFS+ journalisé et avec une table de partition adaptée à macOS. La taille n’a rien d’arbitraire : il faut couvrir confortablement l’ensemble des fichiers de l’installeur, surtout pour les versions récentes de macOS qui gonflent d’année en année. Chercher à gratter quelques centaines de Mo ici est une fausse bonne idée.
Une fois le .dmg créé, l’image est montée avec hdiutil attach, en fixant un point de montage clair, comme /Volumes/Ventura. À partir de là, l’outil clé devient createinstallmedia, accessible depuis l’app d’installation macOS :
/Applications/Install macOS Ventura.app/Contents/Resources/createinstallmedia –volume /Volumes/Ventura –nointeraction
Cette commande copie l’ensemble des fichiers nécessaires pour rendre le volume amorçable. Selon la machine, l’opération prend quelques minutes, sans retour très bavard dans le terminal. Une fois terminé, l’éjection se fait via hdiutil eject sur le volume d’installation, puis vient la conversion en fichier ISO utilisable par VMware :
hdiutil convert /tmp/Ventura.dmg -format UDTO -o ~/Desktop/Ventura.cdr
La seule subtilité ici, c’est l’extension. Apple sort un .cdr, qu’il suffit de renommer en .iso avec un simple mv. Les hyperviseurs, eux, ne se soucient pas du format interne, tant que l’en-tête reste cohérent avec les attentes d’un ISO hybride compatible EFI.
Pour Studio Correzia, ce processus est scripté une bonne fois pour toutes. Un script shell génère l’image, lance createinstallmedia, convertit en .iso, puis supprime le .dmg temporaire. Sur un parc où l’on veut tester plusieurs versions de macOS (Monterey, Ventura, Sonoma), disposer de plusieurs ISO propres, nommés clairement, évite les confusions. C’est d’autant plus pratique quand on jongle entre VMware Workstation et ESXi.
Un point que de nombreux tutos bâclent concerne la gestion de l’espace disque sur le Mac source. Une image de 16 Go, plus l’installeur téléchargé, plus les fichiers temporaires, finissent vite par remplir un SSD de 256 Go. Il devient judicieux de supprimer régulièrement les .dmg intermédiaires et les anciens installeurs, quitte à garder uniquement les ISO finaux synchronisés vers un NAS ou un datastore VMware.
Une fois l’ISO final disponible, la question suivante se pose immédiatement : où va-t-il vivre, et comment sera-t-il présenté à la future VM macOS dans VMware. C’est là qu’entre en jeu la distinction entre Workstation sur poste de travail et ESXi en environnement serveur.
Préparer un hôte VMware ESXi pour macOS : unlocker, datastore et SSH
Sur un serveur ESXi, installer macOS ne se résume pas à pointer l’ISO dans le lecteur virtuel. Par défaut, la liste des systèmes invités ne propose pas macOS, du moins sur un grand nombre de versions, surtout si l’hôte n’est pas un Mac. Pour contourner cette limitation, de nombreux admins utilisent un patch spécifique, souvent nommé Unlocker, qui modifie des fichiers VMware afin de faire apparaître macOS dans la liste des OS invités.
Studio Correzia, dans son homelab, teste justement Unlocker sur un ESXi dédié aux expérimentations, pas en production. La démarche suit un enchaînement précis : activer SSH sur l’hôte, pousser les fichiers de patch et l’ISO Ventura.iso vers un datastore, puis exécuter le script de patch. Sur le plan purement technique, la séquence ressemble à celle-ci :
- Connexion au client ESXi, activation du service SSH via le menu Actions / Services.
- Upload du fichier esxi-unlocker (archive zip) et de l’ISO macOS via le navigateur de datastore.
- Connexion SSH depuis un poste d’admin (PuTTY ou équivalent) vers l’hôte ESXi.
Une fois connecté en SSH, l’admin bascule dans le datastore où se trouve l’archive, décompresse le zip avec unzip, puis ajuste les droits d’exécution avec chmod 0775 -R esxi-unlocker-301/. Le script principal se lance ensuite via ./esxi-install.sh, qui patche les composants nécessaires. Pour vérifier le résultat, une petite commande de test, souvent ./esxi-smctest.sh, indique si le support SMC virtuel est actif.
Si le test retourne un smcPresent incohérent, le patch n’a pas été appliqué correctement, et il vaut mieux s’arrêter là avant de créer la moindre VM. En cas de succès, ESXi demande un redémarrage de l’hôte, ce qui implique l’arrêt de toutes les VM. En prod, cela impose une fenêtre de maintenance, dans un homelab comme celui de Studio Correzia, l’impact est plus facile à absorber.
Ce qui pose question, ici, n’est pas tant la complexité technique que la frontière avec les limites légales. Unlocker modifie le comportement d’ESXi pour accepter un OS invité que VMware ne liste pas forcément sur ce type de matériel. On revient donc à la même problématique que tout à l’heure : tant que l’hôte est un Mac et qu’on reste dans un cadre de test interne, certains accepteront ce compromis. Dès qu’on parle de plateforme de production, difficile de légitimer ce genre de manipulation vis-à-vis d’Apple et de l’éditeur de l’hyperviseur.
Sur le plan pratique, une fois Unlocker en place, le plus gros du travail se déplace vers la partie standard de VMware ESXi : gestion des datastores, création de VM, allocation des ressources. L’ISO Ventura ou Sonoma se retrouve dans le datastore choisi, accessible depuis le lecteur CD/DVD virtuel. La création de la VM suit les mêmes écrans que pour Windows ou Linux, à un détail près : la possibilité de sélectionner « Apple macOS 13.x (64 bits) » comme OS invité, ce qui active des réglages par défaut plus adaptés.
Pour Studio Correzia, ce type de configuration reste volontairement cantonné à un hôte de lab isolé, avec une documentation claire des modifications apportées. L’idée n’est pas d’encourager l’usage massif de ces patches, mais de reconnaître leur existence et de les évaluer lucidement, en pesant les avantages techniques face aux risques contractuels.
Une fois l’hôte ESXi prêt, ISO en place, Unlocker éventuellement appliqué, la prochaine étape consiste à détailler la création d’une VM macOS propre, en faisant de bons choix de ressources et de périphériques virtuels.
Créer et configurer une machine virtuelle macOS sur ESXi : allocations, ISO et bonnes pratiques
Dans l’interface ESXi, la création d’une VM macOS se fait via le menu « Créer/Enregistrer une machine virtuelle ». Cette partie ressemble beaucoup à ce que connaissent déjà les admins pour Windows ou Linux, mais quelques réglages méritent une attention particulière pour que macOS tourne correctement et reste gérable dans le temps.
Studio Correzia crée une nouvelle VM nommée « macOS-Dev-Ventura ». Dans l’assistant, le type de création reste « Créer une nouvelle machine virtuelle », puis la famille de système invité passe sur « Mac OS ». Dès que le patch Unlocker est en place, la version proposée devient « Apple macOS 13 (64 bits) » ou équivalent selon la version de l’ISO. Ce choix n’est pas décoratif : VMware ajuste automatiquement certains paramètres, notamment la compatibilité EFI et quelques options hardware.
Côté ressources, une VM macOS destinée à de la compilation Xcode ou des tests lourds mérite souvent 4 vCPU et 8 Go de RAM au minimum. Les développeurs de Studio Correzia, habitués à des MacBook avec 16 Go, savent qu’il ne sert à rien de surdimensionner sur ESXi si le cluster ne suit pas. Un stockage de 80 à 120 Go en disque virtuel se révèle cohérent pour un système, quelques outils, et des projets en cours. L’approche disque fin provisionné (thin) reste pertinente dans la plupart des contextes de lab.
Le branchement de l’ISO passe par l’onglet « Lecteur CD/DVD ». C’est ici qu’il faut sélectionner « Fichier ISO du datastore » puis pointer vers Ventura.iso. La case « Connecter à la mise sous tension » doit être cochée. Sans ce détail, la VM boote sur un disque virtuel vide et l’installateur macOS ne se lance pas, ce qui fait perdre un temps précieux lors du premier démarrage.
Pour comparer les scénarios et clarifier le positionnement d’ESXi par rapport à Workstation, un tableau synthétique aide bien les équipes :
| Critère | VMware ESXi | VMware Workstation |
|---|---|---|
| Type d’hyperviseur | Bare metal, serveur dédié | Hébergé, sur OS de bureau (Windows/Linux) |
| Usage ciblé | Homelab avancé, pré-prod, prod | Tests locaux, dev, maquettes rapides |
| Licence | Édition gratuite limitée + options payantes | Gratuit usage perso, licence pro pour un usage avancé |
| macOS invité | Nécessite patchs ou hôte Apple selon le contexte | Souvent unlocker + réglages manuels |
| Administration | Client web, API, intégration vCenter | Interface locale riche, moins d’API |
Une fois la VM créée, le démarrage initial déclenche l’installation de macOS, très proche de ce qui se passe sur un Mac physique : choix de la langue, partitionnement du disque via Utilitaire de disque, puis copie des fichiers système. Ce processus peut prendre de 20 à 40 minutes selon la rapidité du datastore et de l’hôte. Durant cette phase, surveiller la console VMware permet de repérer aussitôt les erreurs type « kernel panic » ou blocages liés aux pilotes vidéo.
Après l’installation, quelques bonnes pratiques simplifient la vie au quotidien : prendre un snapshot juste après la configuration initiale et les mises à jour, installer les VMware Tools pour macOS si Unlocker ou les outils fournis les rendent disponibles, et documenter les particularités de la VM dans la CMDB ou un simple wiki interne. Studio Correzia, par exemple, note systématiquement la version exacte de macOS, la taille du disque virtuel, et les projets qui reposent dessus.
Cette méthode n’empêche pas toutes les surprises, mais évite les mauvaises décisions de départ. Une VM macOS pensée dès le départ comme un environnement de dev bien cadré reste beaucoup plus simple à maintenir que ce que certains imaginent.
Installer macOS sur VMware Workstation depuis un PC Windows : quand et comment le faire
Beaucoup de lecteurs n’ont pas un ESXi sous la main, mais utilisent déjà VMware Workstation sur Windows pour leurs labos. C’est exactement la situation du développeur principal de Studio Correzia, qui veut lancer une VM macOS locale sur son portable Windows pour déboguer des soucis d’affichage dans une app multiplateforme.
Sur Workstation, la démarche ressemble à ESXi, mais tout se passe sur le poste lui-même. Une fois l’ISO Ventura.iso récupéré depuis le Mac de l’équipe, le fichier est transféré vers le PC Windows par réseau ou via un disque externe. L’utilisateur crée ensuite une nouvelle VM en choisissant un OS invité le plus proche de macOS, souvent une entrée générique, avant d’appliquer éventuellement un patch type Unlocker côté Workstation pour exposer explicitement macOS dans la liste.
La configuration matérielle classique sur un portable récent reste raisonnable : 4 vCPU si le CPU le permet, 8 Go de RAM attribués à la VM sur une machine équipée de 32 Go, et un disque virtuel sur SSD. Workstation s’en sort bien avec ce profil, surtout si aucun autre service lourd ne tourne en parallèle. À l’inverse, sur une machine avec 8 ou 12 Go de RAM total, une VM macOS devient vite un boulet, ce qui limite l’intérêt pour un usage quotidien.
La question de la licence Apple revient encore plus fort sur ce terrain. Un PC Windows qui héberge macOS dans Workstation n’entre pas dans les scénarios prévus par Apple. Pour un usage strictement personnel, en mode découverte technique ou apprentissage, chacun arbitrera le risque qu’il accepte. Pour une entreprise, en revanche, ce genre de configuration expose à une non-conformité évidente en cas d’audit ou de litige, même si la probabilité d’un contrôle reste faible.
Un autre point à ne pas négliger concerne les pilotes et l’intégration. Sur ESXi, les profils matériels de VM sont souvent plus « neutres ». Sur Workstation, l’affichage, la gestion du son et des périphériques USB peuvent donner des comportements étranges avec macOS, surtout pour des versions très récentes du système. Des développeurs rapportent par exemple des soucis de résolution d’écran, de glisser-déposer ou de presse-papiers partagé, qui nuisent à la productivité.
Chez Studio Correzia, la décision tombe rapidement : Workstation avec macOS sert uniquement pour de la reproduction de bug très ciblée, sur un nombre limité de postes, en complément de Mac physiques de référence. Le cœur de l’activité de test et de build reste sur des machines Apple, ce qui évite de transformer ce bricolage en dépendance structurante.
Ce compromis illustre bien l’usage raisonnable que l’on peut faire de macOS dans VMware Workstation. Intéressant pour apprendre, reproduire un problème, valider un script, beaucoup moins pertinent pour remplacer durablement un parc de Mac dans un environnement professionnel structuré.
Limites légales, bonnes pratiques et stratégies réalistes autour de macOS virtualisé
La dernière pièce du puzzle, souvent reléguée au second plan, concerne les limites légales et les stratégies pour rester raisonnable dans le cadre d’un SI. Le texte de la licence Apple pour macOS ne laisse pas beaucoup de place à l’interprétation : le système est pensé pour tourner sur du matériel Apple, point. La possibilité de lancer des machines virtuelles macOS est généralement réservée aux Mac eux-mêmes, souvent avec un nombre de VMs limité par licence.
La conséquence est assez directe : tous les scénarios de type « installer macOS sur VMware ESXi sur un serveur Dell ou HP », ou « lancer macOS dans VMware Workstation sur un PC Windows » restent en dehors du cadre contractuel. Dans un homelab privé, le risque se limite à un manquement à un contrat de licence, sans enjeu commercial. Dans une organisation, ce même écart peut devenir un sujet juridique en cas d’audit logiciel, ou lors d’un contentieux plus large où chaque irrégularité est passée au peigne fin.
Pour les structures qui veulent exploiter la virtualisation tout en restant dans un cadre plus aligné, plusieurs approches émergent en 2025 :
Pour certains, le plus raisonnable consiste à réserver l’usage de VMware avec macOS à des hôtes Apple, que ce soit via ESXi installé sur un Mac Pro ou via des solutions plus maison. D’autres choisissent des plateformes de virtualisation alternatives qui ciblent explicitement macOS sur matériel Apple. Enfin, pas mal de boîtes décident tout simplement de s’équiper d’une grappe de Mac mini ou Mac Studio, parfois orchestrés via des services de CI/CD, et laissent la virtualisation à d’autres systèmes.
Studio Correzia adopte une ligne claire : un petit cluster de Mac mini fait tourner les workloads macOS critiques, utilisés pour la build, les tests et la validation graphique. Les environnements VMware avec macOS restent confinés au lab, documentés comme tels, et jamais utilisés comme socle officiel pour les livraisons clients. Ce n’est pas parfait, mais c’est une façon honnête de tirer parti des qualités de VMware tout en reconnaissant les contraintes imposées par Apple.
Sur le plan purement technique, on peut aller très loin avec macOS dans VMware : snapshots, clones pour des campagnes de test, intégration à des pipelines d’intégration continue, etc. La vraie question devient alors moins « est-ce que c’est possible » que « dans quel cadre est-ce raisonnable de le faire ». Tant qu’on garde cette distinction en tête, les choix architecturaux gagnent en clarté.
Pour tout lecteur qui se retrouve dans la situation de Studio Correzia, une démarche simple aide à structurer la réflexion : recenser les besoins réels en macOS, cartographier les options conformes, garder les montages plus « créatifs » dans le périmètre du lab, bien documentés, avec un plan clair pour revenir sur des solutions totalement conformes si un jour le contexte l’exige.
Peut-on légalement installer macOS sur VMware sur un PC Windows classique ?
Sur le plan technique, installer macOS sur VMware Workstation ou ESXi hébergé sur un PC Windows fonctionne avec certains patchs et ISO adaptés. Sur le plan juridique, la licence Apple macOS prévoit une exécution sur du matériel Apple, avec une tolérance pour la virtualisation sur ces mêmes machines. Faire tourner macOS sur du matériel non-Apple reste en dehors du cadre du contrat de licence, surtout dans un contexte professionnel.
Quels sont les principaux prérequis matériels pour une VM macOS confortable dans VMware ?
Pour une VM macOS Ventura ou Sonoma usable, il est conseillé de prévoir au minimum 4 vCPU, 8 Go de RAM dédiés à la VM et un disque virtuel de 80 à 120 Go sur un stockage SSD. Côté hôte, 16 Go de RAM restent un minimum pratique, 32 Go offrant plus de marge, surtout si plusieurs VMs tournent en parallèle. Un processeur avec support VT-x ou AMD-V est indispensable.
Comment obtenir une ISO macOS fiable pour une installation virtuelle dans VMware ?
La méthode recommandée consiste à utiliser un Mac réel pour télécharger l’installeur macOS depuis l’App Store, puis à créer une image amorçable avec l’outil createinstallmedia et hdiutil. L’InstallESD.dmg contenu dans l’application d’installation est converti en .dmg amorçable, puis en .iso via hdiutil convert. Cela produit un ISO propre, compatible avec VMware ESXi et VMware Workstation, sans dépendre d’images d’origine incertaine.
Faut-il utiliser un patch Unlocker pour voir macOS dans la liste des OS invités VMware ?
Sur beaucoup de versions d’ESXi et de VMware Workstation, macOS n’apparaît pas par défaut dans la liste des systèmes invités, notamment sur matériel non-Apple. Des patchs de type Unlocker modifient les fichiers de configuration VMware pour ajouter ces entrées et activer certains composants comme le SMC virtuel. C’est une solution répandue en homelab, mais elle modifie le comportement prévu par l’éditeur et s’inscrit dans une zone grise sur le plan contractuel.
VMware ESXi ou VMware Workstation : quel choix privilégier pour tester macOS ?
Pour un usage structuré, avec plusieurs développeurs et une gestion centralisée des ressources, VMware ESXi installé sur du matériel Apple offre un cadre plus propre, proche d’une infra serveur classique. VMware Workstation Convient plutôt à des tests ponctuels sur poste local, pour de la reproduction de bug ou de la découverte. Dans les deux cas, la question de conformité à la licence Apple doit rester au centre de la décision, surtout pour un environnement d’entreprise.
