Installer macOS dans une machine virtuelle VMware reste un moyen très efficace de tester des applications, valider des scripts ou documenter des procédures sans monopoliser un Mac physique. Entre les contraintes de licence, la compatibilité matérielle et les différences entre ESXi, Workstation et Fusion, le sujet demande pourtant un minimum de méthode. Cet article propose un mode d’emploi complet et réaliste pour installer macOS sur VMware, en couvrant plusieurs macOS versions (de High Sierra à Tahoe) et plusieurs systèmes d’exploitation hôtes, qu’ils tournent sous Windows ou Linux. L’objectif n’est pas de courir après la moindre astuce de forum, mais d’aligner une procédure reproductible, avec des réglages clairs et des points de contrôle à chaque étape.
Pour garder le fil, on suivra le parcours d’une PME de développement logiciel, baptisée ici NeoSoft, qui doit valider ses binaires macOS sans investir tout de suite dans un parc de Mac mini. Son équipe IT doit jongler entre un cluster ESXi déjà en place, quelques postes Windows costauds pour le test et des contraintes de sécurité classiques : pas de bricolage non maîtrisé dans le datacenter, pas d’images douteuses récupérées au hasard des moteurs de recherche. Cette histoire sert de fil rouge : à chaque étape, les choix techniques seront expliqués en fonction de vraies contraintes (RAM, stockage, réseau, légalité, support). L’idée est simple : après lecture, un administrateur ou un développeur doit pouvoir décider rapidement s’il installe macOS sur VMware ESXi, sur Workstation Pro, ou s’il vaut mieux basculer vers une autre solution de virtualisation plus adaptée.
En bref
- Installer macOS sur VMware nécessite une ISO propre issue d’un installateur Apple, et non un fichier récupéré au hasard.
- Pour ESXi comme pour Workstation, un unlocker est indispensable afin de débloquer l’option macOS dans la configuration VMware.
- Un hôte avec au moins 8 Go de RAM et 80 Go libres reste un minimum réaliste pour une machine virtuelle macOS exploitable.
- Les réglages du fichier .vmx (SMC, carte réseau vmxnet3, éventuel CPU AMD) font souvent la différence entre un boot en boucle et un système stable.
- Installer VMware Tools pour macOS (darwin.iso) change complètement l’expérience : résolution, fluidité, intégration.
- Sur un socle plus large de virtualisation, comparer aussi Proxmox et VMware reste pertinent, par exemple avec ce type de guide : migration ou coexistence Proxmox / VMware.
Préparer l’environnement VMware avant d’installer macOS
Avant toute chose, NeoSoft a dû clarifier un point que beaucoup repoussent : où va tourner macOS exactement, et pour quoi faire. Pour quelques développeurs front, VMware Workstation Pro gratuit pour un usage non commercial suffit largement. Pour intégrer des runners de CI macOS, ESXi sur le cluster de préproduction devient plus logique. Dans les deux cas, la même règle s’applique : pas de VM macOS sans ressources dédiées, sinon l’équipe passe plus de temps à regarder des barres de progression qu’à coder.
Sur les postes Windows, la marche à suivre est limpide. On installe Workstation Pro, on s’assure d’avoir 16 Go de RAM, un SSD correct et au moins 80 Go libres pour la VM. Côté datacenter, ESXi doit être déjà en place, avec un datastore suffisamment dimensionné et des sauvegardes au niveau hyperviseur. L’avantage d’un environnement déjà structuré, c’est qu’on peut appliquer à ces VMs macOS les mêmes standards que pour les VMs Linux ou Windows : snapshots, sauvegarde image-based, monitoring, tout ce qu’il faut pour éviter les mauvaises surprises.
Créer ou récupérer une ISO macOS exploitable pour VMware
C’est le premier vrai sujet de ce tutoriel macOS. Les fichiers ISO macOS qui traînent sur le web sont tentants, mais l’expérience montre qu’ils posent plus de problèmes qu’ils n’en résolvent : installations qui plantent à mi-chemin, mises à jour impossibles, installeur modifié de façon opaque. NeoSoft a tranché : ISO uniquement générée à partir d’un installateur Apple, téléchargé sur un Mac existant.
Sur ce Mac, l’équipe ouvre le Mac App Store, récupère par exemple macOS Ventura ou Sonoma, puis utilise la ligne de commande pour fabriquer une ISO propre. Le schéma est toujours le même : création d’un disque temporaire avec hdiutil, exécution de la commande createinstallmedia fournie par Apple, conversion du .dmg en .iso, puis nettoyage. Pour Ventura, le type de séquence ressemble à ceci, adaptée au compte utilisateur et à la version choisie :
Exemple de chaîne de commandes (modèle à adapter)
1) Création d’une image vide de 16 Go dans /tmp, format HFS+ journalisé
2) Montage sous /Volumes/Ventura
3) Exécution de createinstallmedia depuis /Applications/Install macOS Ventura.app
4) Conversion de /tmp/Ventura.dmg vers un .cdr puis renommage en .iso sur le bureau
5) Suppression de l’image temporaire .dmg
Ce modèle s’applique aux autres macOS versions : Monterey, Sonoma, Tahoe, etc. À partir de là, NeoSoft dispose d’ISO maîtrisées, stockées sur un partage de fichiers interne, versionnées et documentées, ce qui évite de répéter ce travail à chaque nouvelle intégration.
Installer macOS sur VMware ESXi, du patch au premier démarrage
Dans le cluster de NeoSoft, ESXi 7 tourne déjà pour les VMs Linux métier. Installer macOS impose un détour : par défaut, ESXi ne propose pas la famille d’OS Apple dans l’assistant de création de VM. Sans unlocker, impossible de sélectionner « Mac OS » en tant que système invité. C’est un choix assumé par VMware, et tout le monde ne sera pas à l’aise avec ce patch, surtout côté conformité et licence. Là encore, mieux vaut décider en connaissance de cause.
Concrètement, l’équipe active d’abord l’accès SSH sur l’hôte ESXi, soit via le client HTML, soit via l’interface DCUI locale. Ensuite, elle télécharge la version adaptée d’esxi-unlocker depuis GitHub, la copie sur un datastore, puis l’installe en ligne de commande. Le script se charge d’ajouter les profils macOS, de préparer les VMX et d’exposer les VMware Tools adaptés. Un redémarrage de l’hyperviseur est ensuite indispensable, d’où l’importance de programmer l’opération en fenêtre de maintenance.
Création de la machine virtuelle macOS sur ESXi
Une fois l’unlocker appliqué, la création de la machine virtuelle suit une logique classique, avec quelques points d’attention. NeoSoft crée une VM baptisée par exemple « macOS-Ventura-Dev », choisit la compatibilité ESXi 7, et définit la famille d’OS sur Mac OS, version Apple macOS 12 ou équivalente, même si l’ISO exacte est plus récente. Ce n’est pas un drame : le but principal est que l’hyperviseur choisisse des valeurs par défaut cohérentes.
Côté ressources, la configuration de départ est la suivante : 2 vCPU, 8 Go de RAM, 40 Go de disque en thin provisionning, et un lecteur CD/DVD virtuel pointant sur l’ISO Ventura stockée dans le datastore. Le choix du datastore pour le disque système fait partie de l’équation : NeoSoft garde les fichiers ISO sur un stockage secondaire et les VMs macOS sur un datastore plus rapide déjà en production. Dernière action avant le premier boot : cocher les cases « Connecter » et « Connecter au démarrage » sur le périphérique CD virtuel, pour s’assurer que la VM boote bien sur l’installateur et non sur un disque vierge.
Ajuster le fichier .vmx : SMC, carte réseau, AMD
Deux écueils reviennent régulièrement en test : une VM qui tourne en boucle au démarrage, et un crash systématique à l’étape de configuration réseau dans l’installateur macOS. Dans les deux cas, le correctif se trouve presque toujours dans le fichier .vmx de la VM. NeoSoft a verrouillé une liste minimale de lignes à vérifier dès la création :
- smc.version = « 0 » pour activer une émulation SMC compatible macOS.
- ethernet0.virtualDev = « vmxnet3 » au lieu de e1000e, qui provoque souvent un redémarrage en boucle à l’étape réseau.
- Sur hôtes AMD, ajout de masques cpuid.*, d’un modèle de Mac (hw.model) et d’un board-id cohérents pour limiter les incompatibilités.
Une fois ces paramètres posés, NeoSoft lance l’installateur. L’équipe formate le disque avec APFS et schéma GUID, puis lance l’installation proprement dite. Le premier démarrage reste parfois long, surtout sur des stockages partagés un peu chargés, mais tant que la barre de progression avance régulièrement, inutile de paniquer. À la fin, la VM affiche l’assistant de configuration classique : pays, langue, réseau, compte utilisateur, services optionnels. À ce stade, l’organisation garde un principe : le minimum de services Apple activés, pas d’Apple ID en dur sur une VM de développement, et pas de données personnelles synchronisées.
Installer macOS sur VMware Workstation Pro sous Windows
Pour les postes de développement Windows chez NeoSoft, le pattern est légèrement différent, mais l’esprit reste le même. On installe d’abord VMware Workstation Pro, aujourd’hui accessible gratuitement pour les usages non commerciaux, ce qui ouvre la voie à des environnements de test complets sur chaque machine. L’étape suivante consiste à appliquer le VMware Unblocker, qui joue le même rôle que sur ESXi : déverrouiller macOS dans la liste des systèmes invités.
Sur un PC Windows avec 32 Go de RAM et un SSD NVMe, la configuration de base d’une VM Sonoma ou Tahoe devient plus confortable : 4 vCPU, 8 à 12 Go de RAM, 60 à 80 Go de disque. Avant de se lancer, l’équipe IT passe un coup de balai avec un outil de type nettoyeur de disque pour libérer de l’espace, histoire de ne pas planter une installation à 90 % faute de place. C’est un détail, mais on a déjà vu des postes saturés par des projets Docker ou des images de test anciennes.
Étapes clés pour Installer macOS sur Workstation
Sur le plan pratique, le chemin suivi par NeoSoft ressemble à une check-list. Après installation de Workstation Pro et du débloqueur, un nouvel assistant de VM permet de sélectionner « Mac OS X » comme type d’OS invité, de pointer vers le fichier ISO Ventura, Sonoma ou autre, puis d’ajuster le matériel virtuel. Une fois la VM créée, un premier démarrage déclenche l’installateur macOS, qui se comporte presque comme sur une machine physique.
Les étapes dans l’interface macOS sont similaires à celles décrites côté ESXi : formatage du disque virtuel via l’Utilitaire de disque, choix d’APFS, lancement de l’installation, puis premier boot et configuration (langue, clavier, compte utilisateur, etc.). Une différence concrète pour les développeurs : sur Workstation, l’intégration clavier/souris et la gestion de l’affichage sont immédiatement perceptibles, surtout après installation de VMware Tools. NeoSoft en profite pour packager un modèle de VM macOS « de base », avec Xcode, les SDK nécessaires et quelques utilitaires, qui pourra servir de template pour les nouveaux arrivants.
Tableau récapitulatif : ESXi ou Workstation pour macOS
Comme les arbitrages se jouent souvent sur quelques critères, NeoSoft a synthétisé les points clés dans un tableau de comparaison. L’idée est simple : aider l’équipe à décider où déployer une nouvelle VM macOS selon l’usage visé.
| Critère | VMware ESXi | VMware Workstation Pro |
|---|---|---|
| Cas d’usage principal | Intégration continue, environnements partagés, préproduction | Postes de dev individuels, tests ponctuels, maquettage |
| Ressources nécessaires | Hôte dédié, datastore, sauvegarde centralisée | PC Windows ou Linux puissant avec SSD et 16 Go+ de RAM |
| Complexité de mise en place | Plus élevée (SSH, unlocker ESXi, gestion cluster) | Plus simple (installateur Windows, unblocker, assistant |
| Performance moyenne | Très stable si stockage et CPU dimensionnés | Variable selon charge du poste et autres VMs locales |
| Intégration outils de sauvegarde | Native via sauvegarde image-based au niveau hyperviseur | Snapshots locaux, sauvegarde machine hôte |
| Évolutivité | Ajout de VMs macOS dans un cluster existant | Limitée à la puissance du poste individuel |
Installer VMware Tools et corriger la résolution macOS
Une fois la VM macOS en service, le pas suivant chez NeoSoft est systématique : installation de VMware Tools pour macOS, parfois désignés sous le nom de darwin.iso. Sans ces outils, la VM reste coincée en 1024×768, sans intégration propre de la souris, ni glisser-déposer, ni synchronisation d’horloge fiable. Pour un développeur qui jongle entre fenêtres, c’est très vite pénible.
Sur ESXi, l’équipe charge d’abord le fichier darwin.iso sur un datastore, exactement comme l’ISO d’installation macOS. Le fichier est ensuite monté sur le lecteur CD virtuel de la VM macOS, puis lancé depuis le bureau sous forme de paquet d’installation. L’assistant affiche plusieurs avertissements de sécurité : extensions système bloquées, demande de droits d’administration, nécessité d’autoriser VMware dans « Confidentialité et sécurité ». Tant que ces étapes ne sont pas validées, les outils ne seront pas pleinement fonctionnels.
Réglages d’affichage et ergonomie dans la machine virtuelle
Après un redémarrage, NeoSoft vérifie la version des VMware Tools avec la commande vmware-tools-cli -v. C’est un réflexe utile pour garder la main sur les mises à jour. Reste un détail très concret : la résolution. Dans certains cas, le panneau « Moniteurs » de macOS n’affiche qu’un seul mode, 1024×768, même après installation des outils. L’équipe a fini par automatiser deux approches complémentaires.
Sur Workstation Pro ou Fusion, le passage en plein écran force souvent un ajustement automatique : si l’écran physique est en 1920×1080, la VM se cale sur cette résolution. Sur ESXi, où l’accès se fait plutôt via un client distant, NeoSoft utilise directement la commande vmware-resolutionSet fournie avec les outils, par exemple en 1920×1080. La résolution ainsi définie reste en place après redémarrage de la VM, ce qui évite de la régler à chaque session. Pour les postes très denses, un script shell permet d’appliquer la résolution souhaitée à chaque ouverture de session utilisateur.
Optimiser la machine virtuelle macOS pour un usage quotidien
Une VM qui fonctionne ne suffit pas : pour une équipe de développement comme NeoSoft, la différence entre un labo et un environnement productif se joue sur des détails. Les écrans de veille, par exemple, finissent par consommer des cycles CPU inutiles lorsqu’une VM reste allumée en fond de tâche. De même, la mise en veille automatique d’un macOS virtuel peut casser une pipeline CI ou interrompre une copie de gros volumes de données.
L’équipe désactive donc systématiquement l’économiseur d’écran et la mise en veille automatique sur ces VMs spécifiques. Côté interface, cela passe par les réglages de « Verrouillage de l’écran » et « Économiseur d’énergie », avec des valeurs à « Jamais » sur les VMs utilisées pour des scripts ou des builds. En complément, une commande systemsetup -setcomputersleep 0 en terminal verrouille le comportement côté système. C’est moins glamour que d’installer un thème sombre, mais le retour sur investissement, lui, est immédiat : moins de jobs bloqués, moins de sessions perdues.
Choisir la bonne version de macOS selon les usages
Installer macOS juste pour le plaisir de voir un fond d’écran Sonoma ne fait pas beaucoup de sens. NeoSoft a défini une politique par usage. Pour les développements ciblant les dernières API, les VMs tournent sur macOS Tahoe ou Sonoma. Pour des environnements plus conservateurs, notamment pour des applications qui doivent rester compatibles avec des clients encore sur Catalina ou Big Sur, les VMs reprennent ces versions plus anciennes.
Dans les faits, cela donne plusieurs modèles de VMs macOS, chacune construite à partir de l’ISO correspondante et documentée. L’équipe garde la trace des problèmes propres à chaque version : par exemple, certaines combinaisons de vmxnet3 et de pilotes audio se comportent différemment selon la version. Ce retour d’expérience est noté, versionné, et intégré aux futures installations pour éviter de tourner en rond. Pour tout ce qui touche aux arbitrages entre hyperviseurs, NeoSoft garde aussi un œil sur les alternatives, notamment Proxmox, en s’appuyant sur des guides comme les comparaisons entre Proxmox et VMware pour ne pas enfermer l’architecture dans un seul choix technique.
Peut-on installer n’importe quelle version de macOS sur VMware ?
En pratique, il est possible d’installer de nombreuses versions, de macOS High Sierra jusqu’aux versions récentes comme Sonoma ou Tahoe, dès lors qu’on dispose de l’installateur complet depuis Apple et qu’on génère une ISO propre. Le point d’attention principal reste la compatibilité entre la version de macOS, la version de VMware (ESXi ou Workstation) et le patch unlocker utilisé. Certaines combinaisons récentes peuvent nécessiter un ajustement du fichier .vmx ou une version d’unlocker plus à jour.
Faut-il un Mac pour préparer l’ISO macOS destinée à VMware ?
Pour rester sur une base fiable, mieux vaut oui. La méthode la plus propre consiste à télécharger l’installateur depuis le Mac App Store sur une machine macOS, puis à générer l’ISO à l’aide de hdiutil et de la commande createinstallmedia. On obtient ainsi une image cohérente, que ce soit pour Ventura, Sonoma ou d’autres versions, et on évite les ISO modifiées ou incomplètes qu’on trouve parfois sur le web.
Pourquoi l’option macOS n’apparaît-elle pas dans VMware lors de la création de la VM ?
Par défaut, VMware ESXi comme VMware Workstation ne proposent pas macOS comme système invité sur du matériel non Apple. C’est pour cela que des outils d’unlock sont utilisés : ils ajoutent la famille d’OS Mac OS X dans l’assistant de création de VM et ajustent certains paramètres internes. Sans ce patch, on peut toujours tenter une installation via un autre type d’OS, mais l’expérience montre que la stabilité et les performances en pâtissent nettement.
Comment corriger une machine virtuelle macOS qui boucle au démarrage ?
Deux vérifications reviennent souvent utiles. D’abord, contrôler que le fichier .vmx contient bien la ligne smc.version =
VMware Tools pour macOS sont-ils indispensables ?
Pour un usage sérieux, oui. Sans VMware Tools (darwin.iso), la VM reste limitée en résolution, la souris n’est pas intégrée correctement, la synchronisation d’heure est approximative et certaines opérations comme le glisser-déposer ou le plein écran fonctionnent mal ou pas du tout. Une fois les outils installés et autorisés dans les réglages de sécurité macOS, la VM se comporte bien mieux et devient réellement utilisable pour du développement ou des tests prolongés.