As part of my testing workflow, I’ve been using VMs running on a ESXi server running ESXi 6.5. To help me quickly build those VMs, I have been using a script named esxi_macos_vm_creation.sh for building VMs. This script is forked from Tamas Piros’s auto-create script for standing up Linux VMs on free ESXi:
My fork of the auto-create script is designed to create and configure virtual machines with Apple operating systems as the guest OS, hosted on a VMware ESXi server running on Apple hardware. The script assumes that the virtual machines are built using copied VMDK disk files, where the VMDK files are generated by AutoDMG and vfuse. For more details, see below the jump.
As part of working on a project recently, I ran into an unexpected problem with ESXi-hosted Mac VMs. For these VMs, I was creating VMDK files from AutoDMG-generated disk images, using vfuse to convert the disk image into a VM with ESXi-compatible VMDK disk image files.
My workflow looked like this:
1. Create disk image using AutoDMG.
2. Use vfuse to create VMDK files using a command similar to the one shown below:
sudo vfuse -i /path/to/autodmg_created_disk_image_here --esx
3. Upload the VMDK files to a convenient location on my ESXi server
4. Set up a new VM, using copies of uploaded VMDK files for the VM boot disk.
5. Resize the new VM to the desired size using VMware’s vmkfstools utility.
6. Start up the VM.
After logging in, I ran the following command to enable macOS to recognize and use the unallocated space from the VM resizing:
diskutil resizeVolume / R
Normally, this command is able to do a live re-sizing of the boot partition to use all available unallocated space. However, this time the re-sizing process failed and the following error was displayed:
How to fix this? For more details, see below the jump.
I’ve had a tool available for a while named create_vmware_osx_install_dmg, but it looks like it has reached the end of the road with macOS 10.12.3. The reason for this is because macOS 10.12.4 has introduced a change that prevents the addition of third-party packages to the OS installer. create_vmware_osx_install_dmg uses the addition of a third-party installer package, so unfortunately this tool cannot be used to generate 10.12.4 or later OS installers.
That said, I still want to be able to create macOS installer disk images for VMware Fusion and ESXi, so I’ve forked create_vmware_osx_install_dmg into a new script named create_macos_vm_install_dmg. create_macos_vm_install_dmg will generate stock OS installer disk images for the following OS versions:
- Mac OS X 10.7.x
- OS X 10.8.x
- OS X 10.9.x
- OS X 10.10.x
- OS X 10.11.x
- OS X 10.12.x
This script does not use a third-party package, so it is able to build a macOS 10.12.4 installer disk image. For more details, see below the jump.
Every so often, it’s necessary to resize the boot drive of an existing virtual machine. The process of resizing the VM’s boot disk from outside the VM is usually pretty straightforward:
1. Shut down the VM
2. Go into the VM’s drive settings
3. Resize it to the desired size
4. Power on the VM.
However, when the VM boots up, the disk space used by the OS won’t have changed.
However, the OS can detect that there is available unallocated disk space that it isn’t using.
Fortunately, this is a correctable condition and the fix can be applied without needing to shut down the VM or boot from another drive. For more details, see below the jump.
A lot of Mac admins need to test software in their environment against both the shipping version of macOS and older versions of OS X. However, getting older OS installers from the Mac App Store (MAS) can be problematic if the Mac you’re using isn’t able to run the older OS as its own operating system. If the Mac you’re using isn’t itself able to run the older OS, a request to download the OS installer from the MAS will result in an error message like the one shown below.
If you’re in this situation, but also have VMware Fusion or a similar virtualization solution available, there is a way to download the desired older OS installer using a VM running the shipping version of macOS. For more details, see below the jump.
In the wake of VMware’s release of ESXi 6.5, I was able to upgrade my ESXi 6.0 Update 2 server to ESXi 6.5 using SSH and esxcli. For those interested in doing likewise, please see below the jump for the details of the process I used.
When building virtual machines for testing, my preferred method is to leverage VMware Fusion’s NetBoot support to NetBoot to a DeployStudio server and run workflows. The process to build a NetBoot-ready VM through VMware Fusion looks like this:
1. Open VMware Fusion
2. In the Select the Installation Method window, choose Create a custom virtual machine and then click the Continue button.
3. In the Choose Operating System window, set OS as appropriate then click the Continue button.
4. In the Finish window, select Customize Settings.
5. Save the VM file in a convenient location.
6. In your VM settings, select Network Adapter.
7. In the Network Adapter settings, select Autodetect under Bridged Networking.
At that point, you can also adjust your RAM and processor settings but that’s up to you.
The VM is now configured to be NetBoot-ready, where it’s set up to run a particular macOS version but has a formatted and completely empty boot drive.
This setup process has been a largely manual process involving a lot of clicking in the VMware Fusion user interface and I’ve wanted to automate this for a while. Thanks to some recent changes which my colleague Joe Chilcote made to his vfuse VM creation tool, it’s now possible to automate the setup of a NetBoot-ready VM in Fusion with the following configurable options:
- OS version
- VM boot drive size
For more details, see below the jump.