

This will make sure that the VM does not automatically boot when it’s fully created.
#Vmware on mac pro iso
iso instead of selecting the original installer:ĭo NOT click ‘Finish’, click ‘Customize Settings’ instead and save the VM where you want. Hdiutil convert /tmp/BigSur.dmg -format UDTO -o ~/Desktop/BigSur.cdr

=> Or force eject the mounted installer volume in Finder (Thanks Kevin for reminding me about the -force option) Sudo hdiutil detach /Volumes/Install\ macOS\ Big\ Sur -force Sudo /Applications/Install\ macOS\ Big\ Sur.app/Contents/Resources/createinstallmedia -volume /Volumes/BigSur -nointeraction Hdiutil attach /tmp/BigSur.dmg -noverify -mountpoint /Volumes/BigSur To work around this I had to create an ISO file from the installer and use that to create the VM in Fusion 12: hdiutil create -o /tmp/BigSur -size 17000m -volname BigSur -layout SPUD -fs HFS+J I’ve ran into this issue in the past, where are reboot of the host Mac fixed it, but not this time.

Except one glitch which I think VMWare is aware of: Fusion 12 fails to create the installation medium when you select the macOS Big Sur Installer: I basically followed the exact same workflow as my earlier post on VM’s and Automated Enrolment, which all seems to work fine. That said, I still wanted to test the creation of a Big Sur VM, and to do so I started with VMWare Fusion 12. As general advise I’d always crosscheck your testing on a physical machine before putting anything into production, especially when you see some weird behaviour. FileVault deferral issues like deferring the _mbsetupuserĭepending what you are testing, this may all be ignorable glitches, but still things to keep in mind.Enrolment customisation not passing user info correctly to Jamf Connect.
#Vmware on mac pro pro
