This is a slight side step from my ‘ESXi 5.5, VSAN, and Mac Mini series’, which I am still very much working on. I am presently testing a custom ISO I built that should replace the need for the work around outlined in William Lam’s post covering the Mac Mini Thunderbolt adapter caveat. The issue at its core is that the Thunderbolt Ethernet adapter device id is missing from the driver map file and as such is not loaded by the kernel at boot. The immediate work around can be run manually and/or added into an ESXi host’s /etc/rc.local.d/local.sh file to run automatically at startup.
The issue I have experienced with this workaround is that, when a host is rebooted, the existing binding for the thunderbolt adapter is lost and needs to be reconfigured. An additional reboot/reload of the vmkdevmgr is required to clear out the old adapter before it can be re-added.
This is not a show stopper, it simply adds the task of gracefully removing the adapter from its vSwitch/VDS prior to performing maintenance on a host. Which I have successfully done without impact to my VMs even when running on VSAN.
This is where the custom ESXi installation ISO I’m working on comes into play. It includes a modified driver map file with the device id for the Apple thunderbolt adapter by default. (I already covered some statements on supportability in my first entry on this topic, and this certainly falls into that category). I will include the ISO and the steps to build one yourself in part two as soon as I validate it! Until then, here is a little of what I have been doing with my home lab.
(Slightly off-topic and a bit dated at almost a year, but check out this post on a company who took it upon themselves to leverage 160 Mac Mini servers to replace Apple’s retired Xserve platform.)
I underestimated just how much I would nerd out after getting this lab running. In my nested environment I was constrained by resources and availability (too noisy to leave on), which prevented me from getting too carried away. That’s a bloated apology for taking my time with this second update, but as you’ll see in the screenshot to the right, I was far from idle.
Does standing up a virtual load balancer to test external NAT to my VPN and Ventrilo servers in the midst of other tasks qualify as a symtom of ADD?
To assist in benchmarking this new environment, I prioritized an evaluation version of vCenter Operations Manager. Establishing baselines and understanding workloads is the best way to maximize a home lab investment. You may have also noticed the ‘MacOSX’ VM, which plays host to my family’s Plex Media Server. This system has a stringent SLA agreement, that my wife often monitors, and I dare not risk breaching it. (She holds a large stake in the budgeting process).
Apart from playing with F5s BigIP LTM VE and the OpenVPN appliance, I have flashed my ASUS RT-N16 router firmware, replacing it with DD-WRT to test out the OpenVPN integration and other features. All of course with some future projects and home lab scenarios in mind.
In short, this lab is already paying dividends by providing a place for me to both learn, work, and play. The uptime of my first few VMs is nearing the two week mark, power outages and all. Check back soon or follow me on Twitter for more details about my next update.