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.
The documentation from MacSysAdmin 2016 is now available, with the session slides and videos being accessible from the link below:
The videos of my sessions are available for download from here:
- What’s new in File System: http://docs.macsysadmin.se/2016/video/Day2Session1.mp4
- Going from Physical to Virtual – Creating, hosting and managing OS X VMs with VMware Fusion and ESXi: http://docs.macsysadmin.se/2016/video/Day3Session6.mp4
For those who wanted a copy of my virtualization talk at MacSysAdmin 2016, here are links to the slides in PDF and Keynote format.
I do a lot of work with virtual machines running in VMware’s Fusion hypervisor software. As part of that work, I’ll occasionally run into the following issue:
1. I’m running an application inside a VM.
2. I’m done with whatever it is and want to quit out.
3. The focus of my keyboard is not inside the VM
4. I click the Command (⌘) and Q keys to quit the application running inside the VM.
5. Instead of the application inside of the VM quitting, I see this.
6. Then I say something like this.
As part of this, I’ve often wished for some way for Fusion to warn me when I’m about to accidentally quit Fusion instead of quitting an application inside a VM. That led to me making the following observation on Twitter:
I was quickly informed that Fusion in fact had exactly that.
For more information, see below the jump.
I’ll be speaking about virtualization, with a focus on VMware solutions, at MacSysAdmin 2016, which is being held from October 4th – 7th, 2016 in Göteborg, Sweden. For those interested, my talk will be on Thursday, October 6th.
For a description of what I’ll be talking about, please see the Thursday program page.
Starting with VMware Fusion 7.x Professional, it’s been possible to transfer virtual machines from VMware Fusion to VMware ESXi. This ability has been improved with VMware Fusion 8.x Professional, but there is a recurring issue with OS X VMs transferred from VMware Fusion to VMware ESXi 6.x. The symptoms normally look like this:
1. An OS X VM running OS X 10.10.x or 10.11.x is created in VMware Fusion 8.x Professional
2. The hardware version of the OS X VM is changed to Hardware Version 11, to allow compatibility with ESXi 6.x
3. The VM is transferred successfully to VMware Fusion 8.x Professional to the ESXi 6.x server
4. Following the transfer, the OS X VM is started but does not successfully complete the OS startup process.
The root cause is that there is some OS information which is not transferred successfully along with the VM, but it’s relatively straightforward to fix. For more details, see below the jump.