mac

How to Netboot install ESXi onto Apple Mac Hardware?

01.13.2017 by William Lam // 13 Comments

The ability to perform an ESXi Scripted Installation over the network has been a basic capability for non-Apple hardware customers since the initial release of classic ESX. However, for customers who run ESXi on Apple Mac Hardware (first introduced in vSphere 5.0), being able to remotely boot and install ESXi over the network has not been possible and customers could only dream of this capability which many of us have probably taken for granted.

Unlike traditional scripted network installations which commonly uses Preboot eXecution Environment (PXE), Apple Mac Hardware actually uses its own developed Boot Service Discover Protocol (BSDP) which ESXi and other OSses do not support. In addition, there are very few DHCP servers that even support BSDP (at least this may have been true 4 years ago when I had initially inquired about this topic). It was expected that if you were going to Netboot (equivalent of PXE/Kickstart in the Apple world) a server that you would be running a Mac OS X system. Even if you had set this up, a Netboot installation was wildly different from a traditional PXE installation and it would be pretty difficult to near impossible to get it working with an ESXi image. With no real viable solution over the years, it was believed that a Netboot installation of ESXi onto Mac Hardware just may not be possible.

tl;dr - If you are interested in the background to the eventual solution, continue reading. If not and you just want the goods, jump down a bit further. Though, I do think it is pretty interesting and worth getting the full context 🙂

[Read more...]

Heads up: ESXi 5.x & 6.0 unable to detect newer Apple Mac Pro 6,1 local SSD Device

07.27.2015 by William Lam // 12 Comments

Over the last couple of weeks there have been several reports coming in from customers that the local SSD device found in newer Apple Mac Pro 6,1 were no longer being detected by ESXi. Starting with ESXi 5.5 Patch03 and ESXi 6.0, the Apple Mac Pro 6,1 was officially supported but it looks like the latest versions of the Mac Pro 6,1 that are being shipped contain a slightly different local SSD device which is not recognized by ESXi.

This was not the first time that this has happened, when the 2014 Mac Mini were first released, they too had a similar issue in which a custom VIB was required to get the internal device to get recognized by ESXi. There is an internal bug (PR 1487494) that is currently tracking the issue and if you are also experiencing this problem, please file an SR and have the GSS Engineer attach your case to this bug.

In the meantime, there is an unofficial workaround which was discovered by one of my readers (Mr. Spock) that by installing the community SATA-XACHI VIB over on Andreas Peetz VIB Depot site, both ESXi 5.5 and ESXi 6.0 will then recognize the local SSD Device. You will need to either use VMware Image Builder or Andreas ESXi Customizer tool to create a custom image if you decide to install ESXi directly on the local SSD device. I personally would recommend installing ESXi on USB device, this would allow you to install the VIB as a post-installation and not requiring a custom ESXi image.

Quick Tip - Cloning Mac OS X VMs with unique serial numbers in vCloud Director

04.24.2015 by William Lam // 2 Comments

This week I learned about a really cool use case from one of our customers who is using vCloud Director to provision Mac OS X virtual machines to their end users both from a development standpoint but also for troubleshooting and demo purposes for their field and QA organizations. Instead of having to manage hardware assignment across large user base, they have built a completely self-service environment for requesting access to Mac OS X VMs, which I thought was pretty neat.

One issue that they were running into was that when they deployed a Mac OS X VM from their vCD Catalog which is a clone operation, they found that the cloned instances contained the exact same serial number as the source VM and that was giving them some problems. I had pinged a few of our engineers to see if they had any ideas and it turns out that the Mac OS X serial number is generated based off of the uuid.bios property of a VM.

Once I found this out, I knew the exact problem because this was something I had seen before when I had worked with vCD. When deploying a vApp from a Catalog in vCD, the bios.uuid property of the VMs are all kept identical and this would explain why the serial number was the same. This behavior is documented in this VMware KB 2002506 and it also includes a solution to the problem. Once the customer made the change, they were now able to deploy new Mac OS X instances with uniquely generated serial numbers. For regular vSphere or Fusion environments, when cloning a Mac OS X VM, the serial number should always be unique as this problem is only specific to vCD. I should also note that once the serial number has been generated, changing the existing bios.uuid will not force the serial number to change.