WilliamLam.com

VMXNET3 driver now included in Mac OS X 10.11 (El Capitan)+

by // 15 Comments

Yesterday I received a pretty interesting comment from one of my Twitter followers @NTmatter who wrote:

This is a pretty neat find because currently today, the only network adapter that is functional with an Apple Mac OS X guest running on either VMware vSphere or Fusion is the e1000{e} driver. This update was definitely news to me and after sharing it internally to see if I could find some more details, it turns out this news also came as surprise to the folks internally. Darius, one of the Engineers who I frequently reach out to on Apple related topics did some digging and found out that Apple started to bundle this VMXNET3 driver starting with Mac OS X 10.11 (El Capitan) release. You can find the driver located in /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleVmxnet3Ethernet.kext

Disclaimer: Given that this VMXNET3 Mac OS X driver was not developed by VMware nor has it been tested by VMware, it currently would not be officially supported by VMware.

If you wish to try out the VMXNET3 driver, you will need to install Mac OS X 10.11 or newer on a VM running on vSphere or Fusion. By default, the only available network adapter type is e1000{e}. To add a VMXNET3 network adapter, you can either manually tweak the .VMX file or you can easily add it by using either the vSphere Web/C# Client or ESXi Embedded Host Client. Below are the instructions on configuring the VMXNET3 network adapter for your Mac OS X guests.

Step 1 - Remove the existing network adapter and then temporarily change the GuestOS type to "Other" (no need to save setting, just update it in VM reconfigure wizard) so that you will be allowed to add a VMXNET3 network adapter. Once you have added it to the VM reconfigure wizard, go ahead and toggle back the GuestOS type to Mac OS X 10.10 and then save the settings as shown in the screenshots below.

mac-os-x-el-capitan-10-11-vmxnet3-driver-0
mac-os-x-el-capitan-10-11-vmxnet3-driver-1
Step 2 - Open a terminal inside of the Mac OS X guest and run the following command to load the VMXNET3 driver:

sudo kextload /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleVmxnet3Ethernet.kext

Step 3 - You can verify that the VMXNET3 driver was successfully loaded by running the following command:

kextstat | grep -i vmxnet3

mac-os-x-el-capitan-10-11-vmxnet3-driver-2
Once the driver has been loaded, you should now have networking connectivity to your Mac OS X VM using the VMXNET3 network adapter. Below is a screenshot of the system info showing the VMXNET3 network adapter.

mac-os-x-el-capitan-10-11-vmxnet3-driver-3
In addition to having an optimized networking when using the VMXNET3 driver, the other benefit is being able to get a link speed of 10GbE which is something customers have been inquiring about when virtualizing Mac OS X guests. Below is a screenshot of the media link shown in this Mac OS X 10.11 guests.

mac-os-x-el-capitan-10-11-vmxnet3-driver-4
Although this a great development for Apple customers who uses VMware vSphere and Fusion, it also does raise an interesting question on whether Apple would be officially supporting this VMXNET3 driver going forward? If I do receive any more details on this, I will update the article. Until then, you can play with this new capability if you are running Mac OS X 10.11 or greater on VMware. Big thanks to Thomas for this great find and sharing it with the VMware Community!

Using PowerCLI to invoke Guest Operations API to a Nested ESXi VM

by // 1 Comment

In my opinion, the Guest Operations API in vSphere is still one of the most powerful Virtual Machine capabilities that is available to vSphere Administrators and anyone else who integrates with the vSphere Platform. The Guest Operations API allows users to perform guest operations (running commands, transferring files, etc) directly within the guestOS as if you were logged in. Valid guest credentials are still required and once authenticated, the operations are then proxied through VMware Tools. Networking is not even required which makes this a handy feature for troubleshooting and can even extend into application level provisioning through a single API.

Obviously, I am a huge fan of this capability and have used it myself on more than one occasion. However, one limitation that I discovered awhile back when using the Guest Operations API with Nested ESXi VMs is that it threw some very strange memory related errors. It was only recently did I find out that there was a known issue with the VMware Tools for Nested ESXi, both the installable VIB and the pre-installed version in ESXi 6.0 on how the guest operations are executed. The good news is that for now, there is a simple workaround that can be applied when using the Guest Operations API.

You will need to add the following option, which runs the command under a specific resource group in the ESXi Shell:

'++group=host/vim/tmp'

Here is an example if I were to run the 'echo' command:

/bin/echo '++group=host/vim/tmp' "hello world"

A more interesting example would be to issue ESXCLI commands using the Guest Operations API, perhaps configuring the welcome message?

/bin/python '++group=host/vim/tmp' '/bin/esxcli.py system welcomemsg set -m "vGhetto Was Here"'

Notice, we need to pass in the resource group command to the "python" binary versus ESXCLI binary. The reason for this is that /bin/esxcli is really just a symlink to /bin/esxcli.py which is just a Python wrapper. The actual command being launched is the python interpreter and the arguments to the command is /bin/esxcli.py and the ESXCLI arguments itself.

For those who prefer to consume the Guest Operations API without having to directly use the vSphere API, you can use PowerCLI and use the Invoke-VMScript cmdlet. The problem with that is due to the way the cmdlet has been abstracted, the necessary underlying API details can not be accessed due to certain assumed defaults which can not be overridden or extended. This is a general problem that I have seen in more than one occasion where the abstraction is to make the consumption of the API simpler but in certain cases, it can also inhibit the use of the underlying API feature.

In this case, we will actually need to call into the vSphere API and using PowerCLI as an example, I have created a script called runGuestOpsInNestedESXiVM.ps1 which implements the specific Guest Operations APIs to issue commands to a Nested ESXi VM.

Here is an example of running the script and configuring the welcome message using ESXCLI:

guest_operations_api_nested_esxi

Automating installation of VMware Tools for Mac OS X

by // 1 Comment

After publishing my recent article on automating the silent installation of VMware Tools for Linux guestOSes, I received a similar question regarding Mac OS X guests and whether the existing script would also apply. The answer is no since Mac OS X packages differ from the Linux installres, but it is possible to automate the installation of VMware Tools for Mac OS X guests.

After quickly looking into this, I realized there are actually several options that are available to customers and it would depend on how you would like to install VMware Tools and what platform you are running your Mac OS X guests on. I will share a couple of options which also includes existing solutions that have already been developed. At the end of the day, the choice will ultimately be up to the administrator on how he/she would like to proceed.

Option 1 - If you are a vSphere/ESXi customer running Mac OS X, you will probably want to mount the VMware Tools installer and then initiate an installation within the Guest. You can actually perform the entire operation within a single context by leveraging our vSphere API to issue the VMware Tools installer and then using the Guest Operations API to perform the installation.

Option 2 - Similar to the above option, if you do not wish to use the vSphere API, you can simply copy the darwin.iso (VMware Tools) image onto your Mac OS X guests and then perform the automated install. This would be the most simplistic option and would apply to running Mac OS X guests on either vSphere/ESXi or Fusion.

Option 3 - You can also download VMware Tools using VMware's online repository (thanks to Rich Trouton for sharing this tidbit) and then performing the installation which is very similar to Option 2. The only downside is if you are running Mac OS X on vSphere/ESXi, the status of VMware Tools will show "unsupported" as the version will differ from version distributed with vSphere/ESXi. In fact, Rich Trouton has an existing solution that he has published here which you can read more about.

If you are already familiar with using the vSphere API and are using vSphere/ESXi, I personally would go with Option 1 just because you can stay within a single context from an automation standpoint and not have to jump between different interfaces. If you not comfortable, want a quick solution or running just Fusion, then Option 2 and 3 would be ideal. Below is an example Gist demonstrating a simple shell script which implements Option 2 and Option 3 with a slight twist from what Rich has done which does not require Git.

Here's an example of running the script using Option 2:

automate-vmware-tools-mac-os-x
I am sure there are probably other methods out there, but the great news is that it is indeed possible to automate VMware Tools for Mac OS X guests 🙂


#!/bin/bash
# 1 = VMware Tools ISO is mounted from vSphere
# 2 = Download VMware Tools (assumes you can connect to internet)
INSTALL_METHOD=2
# Thanks to Rich Trouton for tip on Tools being available online
VMWARE_TOOLS_DOWNLOAD_URL=http://softwareupdate.vmware.com/cds/vmw-desktop/fusion/7.1.2/2779224/packages/com.vmware.fusion.tools.darwin.zip.tar
# DO NOT MODIFY BEYOND HERE #
VMWARE_TOOLS_INSTALLER_DIR="/Volumes/VMware Tools/Install VMware Tools.app/Contents/Resources"
VMWARE_TOOLS_INSTALLER_FILE="VMware Tools.pkg"
if [ $EUID -ne 0 ]; then
echo "Please run the script with sudo ..."
exit 1
fi
if [ ${INSTALL_METHOD} == "1" ]; then
if [ -d "${VMWARE_TOOLS_INSTALLER_DIR}" ]; then
/usr/sbin/installer -pkg "${VMWARE_TOOLS_INSTALLER_DIR}/${VMWARE_TOOLS_INSTALLER_FILE}" -target /
echo "Please reboot the system for the installation to complete ..."
fi
elif [ ${INSTALL_METHOD} == "2" ]; then
TMP_DIR=/tmp/osx-vmware-tools
mkdir -p "${TMP_DIR}"
VMWARE_TOOLS_TAR_FILE=com.vmware.fusion.tools.darwin.zip.tar
VMWARE_TOOLS_ZIP_FILE=com.vmware.fusion.tools.darwin.zip
VMWARE_TOOLS_ISO_FILE="payload/darwin.iso"
cd ${TMP_DIR}
# Download VMware Tools from online repo
curl -O "${VMWARE_TOOLS_DOWNLOAD_URL}"
# Extract the VMware Tools tar file
tar -xf "${VMWARE_TOOLS_TAR_FILE}"
# Unzip the VMware Tools zip file
unzip "${VMWARE_TOOLS_ZIP_FILE}"
# Mount VMware Tools ISO (similiar to vSphere/ESXi)
hdiutil attach "${VMWARE_TOOLS_ISO_FILE}"
# Perform installation
/usr/sbin/installer -pkg "${VMWARE_TOOLS_INSTALLER_DIR}/${VMWARE_TOOLS_INSTALLER_FILE}" -target /
# Detach mount & clean up
hdiutil detach '/Volumes/VMware Tools'
rm -rf "${TMP_DIR}"
echo "Please reboot the system for the installation to complete ..."
else
echo "Invalid Selection"
fi

view raw

gistfile1.sh

hosted with ❤ by GitHub