WilliamLam.com

Running ESXi 5.0 & 5.1 on 2012 Mac Mini 6,2

by // 59 Comments

If you recently purchased the new 2012 Apple Mac Mini 6,2 which was just released not too long ago and tried to install either ESXi 5.0 or 5.1, you probably noticed a PSOD (Pink/Purple Screen of Death) during the installation. This is currently a known issue and there is an extensive VMTN thread (9,300+ views) about this problem which also includes a fix through a collaboration between VMTN community user zer010gic and VMware Engineer dariusd. Even though the Apple Mac Mini is not an officially supported hardware platform for running ESXi, it is great to see VMware engineers going out their way and trying to help the VMware community find a solution as well as providing an "unofficial" fix in this case.

I would also like to point out that this issue only applies to the new 2012 Apple Mac Mini, for previous models such as the Apple Mac Mini 5,1 or 5,3 you can install ESXi 5.0 or 5.1 without any issues. For more details, please refer to the instructions in this blog post.

Disclaimer: The Apple Mac Mini is not officially supported by VMware. The only supported platform for ESXi 5.0 for Apple hardware is the Apple XServe 3,1 and for ESXi 5.1 is the Apple Mac Pro, which you can get more details here.

Before jumping into the solution, if you think VMware should support the Apple Mac Mini for running ESXi, please provide feedback to VMware by submitting a Feature Request. The more feedback that VMware receives from customers along with business justifications, the better our product management team can prioritize features that are most important to our customers.

Here are the current problem/solutions when trying to install on the new Mac Mini:

Problem: PSOD during ESXi 5.0 or 5.1 installation.
Solution: Add iovDisableIR=true to the kernel option before attempting installation. When you are asked to reboot, be prepared to enter iovDisableIR=true again (SHIFT+O) which is required to get ESXi to boot after installation. Once the system has booted up, go ahead and run "esxcli system settings kernel set -s iovDisableIR -v true" in the ESXi Shell to persist the kernel setting. This is a "temp" workaround while PSOD is being investigated.

Problem: Unable to install new OSX Server on a VM or power on existing OSX Server VMs.
Solution: There appears to be a significant change in Apple's SMC (System Management Controller) device in the newer models that prevents the Apple SMC VMkernel driver from properly loading. A tempoary fix was provided to zer010gic to create a custom ISO until the fix is integrated into a future release.

Note: There may be other minor/unconfirmed issues listed on the VMTN thread, but for basic ESXi installation/usage + OSX Server VM creation/installation, the above solutions should be sufficent.

Instead of having everyone walk through the process of creating a custom ESXi ISO which includes the two fixes mentioned above as well as the bundling the updated tg3 Broadcom network drivers for network connectivity, zer010gic has generously created and is hosting ESXi 5.1 ISOs for users to download and use. It contains some work that I have been doing with zer010gic to create an ESXi 5.1 ISO that does not require any manual intervention outside of the normal ESXi installation. I recently completed the rest of this work which is based off of the oriignal ISO that zer010gic has shared on the VMTN community (unfortunately I have not been able to get a hold of him to provide him with the necessary bits and I have decided to post a modified ISO).

Here is a step by step instruction for zer010gic ESXi 5.1 ISO

Step 1 - Download zer010gic ESXi-5.1-MacMini-SMC-6-2.iso.

Step 2 - Transfer ISO to either USB key or CD-ROM

Step 3 - Perform ESXi installation as you would, but when you get to the very last step prior to rebooting, be ready for some typing when the host boots back up (this is important else you will get a PSOD)

Step 4 - When ESXi starts to boot up, hit SHIFT+O which will allow you to add additional kernel boot option. Add the following text the bootUUID (remember to add a space first)

iovDisableIR=true

This step is required to ensure your ESXi boots up properly for the first time so you can permanently enable this kernel option using ESXCLI which will then persist this upon sub-sequent reboots.

Step 5 - Login to ESXi Shell (you may need to enable it first) and run the following ESXCLI command:

esxcli system settings kernel set -s iovDisableIR -v true

Once this is set, you no longer have to do this again. If you prefer not to go through these manual steps, please refer to the section below for a modified ESXi 5.1 ISO which automates all this for you.

Here is my modified ESXi 5.1 ISO which does not require any additional user intervention

Step 1 - Download my ESXi-5.1-MacMini-SMC-BOOT-FIX-6-2.iso

Step 2 - Transfer ISO to either USB key or CD-ROM

Step 3 - Go through normal ESXi install and enjoy

Note: For details on how I automated the kernel setting setting, take a look at the very end.

So if you are looking to refresh your home lab, you just may want to consider using the new Apple Mac Minis, especially with small form factor footprint 🙂

Note: A couple of users mentioned it took a bit of time to boot up, specifically when usbarbitrator module is being loaded. I noticed this too and it took quite a bit of time, probably 5-6 minutes. If you do not plan on any USB pass-through from the Mac Mini to your guestOSes, you can actually disable this service which should help speed the bootup. If you wish to disable usbarbitrator, run the following command:

chkconfig usbarbitrator stop

ESXi ISO Customization Details

If you take a look at the steps required to install the ISO provided by zer010gic, most of the heavy work has already been done for you. The only "manual" part that is required from the user is to enter a kernel option during the first boot and then run an ESXCLI command to persist this kernel setting which will prevent Mac Mini from PSODing. Removing these these manual steps is actually harder than it looks because of when you need to actually perform the changes. After much trial and error, I came up with the following script below (it's not the cleanest, but it works).

Basically the script is loaded from custom.tgz and executed before the installation begins and it generates a script stored in /tmp/customboot.sh which will look for the boot.cfg configuration file stored in the primary bootbank. This is where we insert the iovDisableIR=true parameter so the user is not required to do this after the first boot up. The challenge with this is the boot.cfg does not exists until after the installation has completed, so what I ended up doing was insert a command into /usr/lib/vmware/weasel/process_end.py which is part of the weasel installer for ESXi and is the very last script that is called when a user hits reboot. The command points back to the /tmp/customboot.sh which will perform the insert into boot.cfg right before rebooting. To automatically take care of the ESXCLI configuration, I added the ESXCLI command to /etc/rc.local.d/local.sh which will automatically run after all init scripts have executed. Then finally, I need to clean up local.sh since I only need that that run once which is handled by another script that is also created and stored in /etc/init.d/customcleanup which will just clean up local.sh file as well as delete itself. Simple right? 😉

Note: There is probably a more optimal way of doing this, probably using one of the weasel installer scripts and just set the boot.cfg option and then clean up with an init script, but I decided to leverage some of my earlier work for Disabling LUN Duringn ESXi Installation

Here is the script within the custom.tgz file:

#!/bin/ash

sed -i "s/time.sleep(4)/time.sleep(4)\n    util.execCommand('\/tmp\/customboot.sh')/g" /usr/lib/vmware/weasel/process_end

cat > /tmp/customboot.sh << __CUSTOM_BOOT__
#!/bin/ash

for BOOTCFG in \$(find / -iname boot.cfg);
do
        grep "no-auto-partition" \${BOOTCFG} > /dev/null 2>&1
        if [ \$? -eq 0 ];then
                sed -i 's/kernelopt.*/kernelopt=no-auto-partition iovDisableIR=true/g' \${BOOTCFG}
        fi
done
__CUSTOM_BOOT__
chmod +x /tmp/customboot.sh

sed -i 's/exit 0/localcli system settings kernel set -s iovDisableIR -v true\nexit 0/g' /etc/rc.local.d/local.sh

cat > /etc/init.d/customcleanup << __CUSTOM_CLEANUP__
sed -i 's/localcli.*//g' /etc/rc.local.d/local.sh
rm -f /etc/init.d/customcleanup
__CUSTOM_CLEANUP__

chmod +x /etc/init.d/customcleanup

VIN 2.0 Supports New Export to CSV & Maps Feature

by // 2 Comments

VMware just released the new vCenter Operations Management Suite 5.6 this evening which includes all new updates to the following products:

There are too many cool new features in each of these products to list them all out (I recommend you check out the release notes for each product). Though, two new features that I would like to point out is from latest vSphere Infrastructure Navigator 2.0 release (also known as VIN) which allows you to export the VIN data to CSV output as well as exporting the maps to PNG.

You have the option of exporting all virtual machines from a given vCenter Server or filter out a subset of the virtual machines by navigating to a specific object using the object navigator in the vSphere Web Client. In the screenshot below, I would like to export all virtual machines that VIN is collecting for a particular vSphere Cluster, so I select the Virtual Machines in that Cluster on the left and then select the Manage tab and then click on Application Services.

The export to CSV button is located right next to the filter box and this will export the entire table view that is seen to a CSV file which you can then save onto your local desktop. The filename will automatically be saved as vin-inventory.csv and here is a screenshot of the output file:

Note: If you filter the list of virtual machines using the Filter box, the export will still capture all virtual machines under this view. If you wish to capture a specific set of VMs, you will need to use the object navigator to filter out the specific objects before exporting.

To export the application dependency maps from VIN, you will need to be in the context of an individual virtual machine and again under Manage tab and then click on Application Services. The map export button is located right next to the zoom in/out option in the upper right corner as shown in the screenshot below.

I really like map export feature as you can sit back and let VIN do all the hard work of mapping out all the applications and VM dependencies for us in a graphical manner and then just export the picture which can then be used with documentation, CMDB diagrams, auditing, etc. These are just two out of the many new features found in the latest release of VIN 2.0. I highly recommend you give VIN a try if you are not already using it in your vSphere environment!

One additional note that I would like to point out, the data being exported to CSV does not capture all the application details such as the services, ports, processes, etc. that you might see from the VIN UI. If you wish to extract all this information from VIN for your own use, you can do so by taking a look at the following articles:

Getting Rid of the Inventory Tree in the New vSphere Web Client

by // 2 Comments

I don't know about you, but I really like using the new inventory list compared to the old inventory tree when I need to find something in new vSphere Web Client. The inventory list does not rely on the static and limited hierarchical tree view to display your vSphere objects. Instead, it groups common vSphere objects together (works across multiple vCenter Servers) along with links to other related objects. This allows you to quickly navigate to a particular vSphere object and with just a click away to other related objects for further inspection. Finally, you will no longer have to worry about the "white screen of death" which was a common problem when trying to display huge inventories and sometimes even smaller ones while using the tree view.

To be honest, I was not a fan of the inventory list at first, but after spending some time with it, I quickly realized the benefits of moving away from the old hierarchical tree view. I actually like the new inventory list so much, that I personally wanted like to get rid of the inventory tree view as it is an extra mouse movement to get to the inventory list. I sometimes even accidentally click on the inventory tree when browsing too quickly through the vSphere Web Client.

I thought it might be a long shot to see if it was possible to remove the inventory tree since I assumed it might be part of the compiled code. Surprisingly, I found out from one of the developers, there was actually a pretty simple way (aka "hack") of removing the inventory tree.

Disclaimer: This is probably not officially supported by VMware, please use at your own risk.

In the example below, I am using the VCSA (vCenter Server Appliance) which has the vSphere Web Client installed by default but this should also work for a Windows vCenter Server that has the vSphere Web Client Server installed.

Step 1 - We need to make a backup of the following file /usr/lib/vmware-vsphere-client/plugin-packages/vsphere-client/plugins/inventory-viewer-war-5.1.0.war which contains the file that we need to edit. The command below will just make a backup copy called inventory-viewer-war-5.1.0.war.BAK

cp /usr/lib/vmware-vsphere-client/plugin-packages/vsphere-client/plugins/inventory-viewer-war-5.1.0.war /usr/lib/vmware-vsphere-client/plugin-packages/vsphere-client/plugins/inventory-viewer-war-5.1.0.war.BAK

Step 2 - Next, we will go ahead and extract the contents of the WAR file which is basically a zip archive in our home directory so that we can edit a file. Run the following command which will extract the contents into a directory called TEMP under /root.

unzip /usr/lib/vmware-vsphere-client/plugin-packages/vsphere-client/plugins/inventory-viewer-war-5.1.0.war -d ~/TEMP

Step 3 - Change into the ~/TEMP directory and you should see a file called plugin.xml which we will be editing. Use an editor such as vi and locate the following section and comment it all out using the notation as shown below
Step 4 - Once you have finished editing the plugin.xml file, go ahead and save the file. Now we will need to re-create the inventory-viewer-war-5.1.0.war file and to do so, inside the TEMP directory, run the following command:

zip -r inventory-viewer-war-5.1.0.war *

Step 5 - We now need to copy the modified inventory-viewer-war-5.1.0.war back into the vSphere Client Plugins directory. Run the following command to copy the WAR file into plugins directory:

cp inventory-viewer-war-5.1.0.war /usr/lib/vmware-vsphere-client/plugin-packages/vsphere-client/plugins/inventory-viewer-war-5.1.0.war

Step 6- Finally, for the changes to go into effect, we just need to restart the vSphere Web Client service by running the following command:

/etc/init.d/vsphere-client restart

If everything was successful, then you should be able to login to the vSphere Web Client and when you click on the main vCenter home on the left, you should no longer see the inventory tree view, just the inventory lists.

Even though we removed the inventory tree from the object navigator, you can still access the four tree views using the shortcuts found on the home page:

If you really want to disable those as well, you can comment out the following four sections:
OR better yet, re-link them to the main vCenter home view by adjusting the targetViewUid to point to vsphere.core.viHome.domainView