WilliamLam.com

Running ESXi 5.5/5.5u1 on Apple Mac Mini + Thunderbolt Ethernet Adapter Caveat

by // 160 Comments

I just upgraded my Apple Mac Mini 5,3 this morning from ESXi 5.1 Update 1 to the latest ESXi 5.5 release and I am very happy to report the upgrade worked flawlessly! When ESXi 5.5 is generally available, you will be able to just download the ISO and install or upgrade your existing Mac Mini without requiring additional drivers for the on-board network adapter to function correctly. If you have a Mac Mini 6,2 the old SMC issue has been resolved, but the PSOD issue is still occurring. As promised to some folks on Twitter, here is a custom ESXi 5.5 ISO for Mini 6,2 that you can just download and install without any manual intervention:

The only issue that I found is if you are using the Apple Thunderbolt Ethernet Adapter, you will find that after the install/upgrade, the network adapter no longer shows up. Looking into this issue, it looks like with the release of ESXi 5.5 and the introduction of the new Native Driver architecture, it had a slight impact to the Thunderbolt Ethernet Adapter. Having said that, the Apple Thunderbolt Ethernet Adapter and Mac Mini was never officially supported, so we were actually lucky that it had worked in the first place.

The reason the Thunderbolt Ethernet Adapter is not being recognized is that its device ID (14e4:1682) is not in tg3 (Broadcom) map file /etc/vmware/driver.map.d/tg3.map. If the device was officially supported, then it would have been automatically claimed by the vmkdevmgr which handles both vmklinux and Native Driver devices. The fix is actually quite simple and I have created a custom VIB called vghetto-apple-thunderbolder-ethernet.vib which will add the appriorpiate device ID to a new custom map file called /etc/vmware/driver.map.d/apple.map which will not collide with the existing tg3.map file. The reason for needing a custom VIB versus appending the device ID to something like /etc/rc.local.d/local.sh is that when the script runs it is too late from a networking stack point of view.

To install the custom VIB, you will need to upload it to your ESXi datastore and run the following command:

esxcli software vib install -v /vmfs/volumes/[DATASTORE]/vghetto-apple-thunderbolder-ethernet.vib -f

Now you can either use the vSphere Web/C# Client to verify the Thunderbolt Ethernet Adapter is showing up or you can run esxcli network nic list.

How to quickly setup and test VMware VSAN (Virtual SAN) using Nested ESXi

by // 48 Comments

Last week at VMworld 2013, VMware announced the release of vSphere 5.5 which includes a variety of exciting new features.  One of the most anticipated feature introduced in this release is VMware Virtual SAN (VSAN) which will be available initially as a public beta. One question that I heard repeatedly throughout the VMworld conference was whether it would be possible to test VSAN in a nested ESXi environment? The answer is absolutely! This is a great way to learn about VSAN and how works from a functional perspective before procuring the necessary hardware.

Disclaimer: Running VSAN in a nested ESXi environment is not officially supported nor is it a replacement for actual testing on actual physical hardware.

Before getting started, I would highly recommend you check out the following resources from my good friend Cormac Hogan which includes a detailed VSAN walk through as well what looks to be an awesome series of articles on how VSAN works:

Requirements:

  • Environment running either vSphere 5.1 or 5.5 and access to the vSphere Web Client.

Configuration:

Nested ESXi VM configured with the minimal resources:

  • 2 vCPU
  • 5GB Memory (ESXi 5.5 now requires a minimum of 4GB vs 2GB as with previous releases but VSAN requires minimum of 5 with recommended 6)
  • 2GB Disk for ESXi 5.5 installation
  • 4GB Disk for an "Emulated" SSD
  • 8GB Disk for HDD

Easy Method:

Instead of having you go through the process of building a Nested ESXi VM with all the prerequisites that includes steps from here and here. I have pre-built a VSAN Nested ESXi VM template (217Kb) that you can just download and import into your environment and being the installation process.

Download either:

and connect to your vCenter Server 5.1 or 5.5 using the vSphere Web Client and import the OVF into your environment (do not use the vSphere C# Client as the import does not persist VHV configuration). Once you have imported the VM, you can then mount the ESXi 5.5 ISO and begin the installation. All three VMDKs have been thin provisioned and you can change the capacity during deployment.

Slightly Harder Method:

If you wish to build the Nested ESXi VM yourself, then you can follow these instructions:

Step 1 - Create a new VM and when you get to the compatibility screen, select either "ESXi 5.1 or greater" or "ESXi 5.5 or greater" depending on the version of vSphere you are running

Step 2 - For the GuestOS select "Other" and "Other (64-bit)"

Step 3 - We will need to customize the following virtual hardware configuration:

  • Change vCPU to 2
  • Click on CPU drop down and enable "Expose hardware assisted virtualization to the guest OS"
  • Change Memory to 4GB
  • Change the initial VMDK to 2GB or whatever value you wish to use for ESXi installation
  • Add second VMDK with 4GB or whatever value you wish to use for "emulated" SSD
  • Add third VMDK with 8GB of whatever value you wish to use for the HDD
  • Click on the VM Options tab at the top and select the "Advanced" drop down box. We will need to add the following entry scsi0:1.virtualSSD = 1 For more details please refer to this article

Step 4 - Click okay to provision the VM and once it has been deployed you will need to re-configure the guestOS to "VMware ESXi 5.x" using the vSphere C# Client for vSphere 5.1 or vSphere Web Client for vSphere 5.5. At this point, you will have the same VM image as in the Easy Method and you are now ready to install ESXi 5.5

When you install ESXi 5.5, you should see the following three disks as shown in the screenshot below, ensure you install ESXi on the 2GB disk:

Prior to enabling VSAN on the particular vSphere Cluster, make sure you enable the new VSAN traffic type on one of your VMkernel interfaces for each of your ESXi hosts, this is required for VSAN communication.

If all the prerequisites have been met, you can now easily enable VSAN by simply checking the VSAN box when editing the vSphere Cluster. In just a few minutes you should see diskgroups automatically created (assuming you selected Automatic mode) consuming both the emulated SSD and HDD and the creation of the vsanDatastore which will be available on all ESXi hosts within that vSphere Cluster.

You can also use the same method for emulating an SSD running in a Nested ESXi to functional test the new VMware Flash Read Cache (vFRC) feature.

VMware Labs releases Proactive DRS Fling from last years Fling Contest

by // 1 Comment

Last year, the VMware Labs team ran an Open Innovation contest where users could submit ideas for Flings that they would like to see get built. In addition to that, one lucky winner will be selected and their idea will actually be sponsored internally within VMware R&D and VMware Engineers would then implement that idea. The winner of that contest was Mike Preston on an idea called Proactive DRS:

“What I would like to see is some sort of appliance/script that can hook into both the vCenter Operations API’s as well as the vSphere APIs and merge these two technologies together. By interpreting vCenter Operations predictions for what is going to happen within your environment and then leveraging vMotion/DRS/DPM to prepare for this before it happens we could be left with a more proactive approach. (I.E. Historically VM1 will utilize 100% CPU at 4am in the morning, let’s be sure these resources are available on the host at 3:45 by migrating other VMs off, rather than waiting for DRS to kick in at 4:05 – At 6am everyday my workload normally increases to the point where DPM kicks in and turns on some hosts, let’s turn these on at based on the vCenter Operations stats rather than having to manually configure a setting to do so).”

Today at the VMware R&D Innovation booth at VMworld, the VMware Labs team has just announced that they will be releasing the Proactive DRS Fling (download coming very soon!). I think this is pretty awesome, I mean how cool is that, an idea that you came up with was implemented by a group of VMware Engineers? Congrats on the awesome idea Mike!

Here is a bit more details on how Proactive DRS works:  

It is a way for DRS to react to changes in the virtual cluster, and to act on predicted changes in resource demands before hosts become stressed. For example, if you have a VM that historically uses 100% CPU at 8am every morning, ProactiveDRS  makes  sure that the CPU resources will be available for that VM before 8am. These actions ensure that your cluster runs smoother and reduces the amount of reactive VM rebalances that occur.

Features

  • Given an advance forecast/prediction of each VM’s resource demands, e.g., CPU and Memory, ProactiveDRS seeks to reorganize the placement of VMs to best balance the current resource demands while taking early actions to accommodate the future/predicted resource demands.
  • Sample actions include, but are not limited to, proactive vMotions (migrations) and proactively powering on a new physical host to accept VMs whose resource demands are expected to spike beyond the available resources of their current physical host.

The VMware Labs folks did not stop there, they are also running a new 2013 Fling Contest and if you are at VMworld, you can drop by the VMware R&D Innovation booth which is behind the main VMware booth to submit your ideas. Another lucky winner will be selected and their idea will also be built by VMware Engineers which includes a free ticket to VMworld 2014. I recommend you either drop by the booth if you are at VMworld or go online to submit an idea and you could be the next person with their very own Fling!