vSphere 6.0 – Page 14

Quick Tip - iPerf now available on ESXi

03.15.2016 by William Lam // 25 Comments

The other day I was looking to get a baseline of the built-in ethernet adapter of my recently upgraded vSphere home lab running on the Intel NUC. I decided to use iPerf for my testing which is a commonly used command-line tool to help measure network performance. I also found a couple of articles from well known VMware community members: Erik Bussink and Raphael Schitz on this topic as well which were quite helpful. Erik's article here outlines how to run the iPerf Client/Server using a pair of Virtual Machines running on top of two ESXi hosts. Although the overhead of the VMs should be negligible, I was looking for a way to benchmark the ESXi hosts directly. Raphael's article here looked promising as he found a way to create a custom iPerf VIB which can run directly on ESXi.

I was about to download the custom VIB and I had just remembered that the VSAN Health Check plugin in the vSphere Web Client also provides some proactive network performance tests to be run on your environment. I was curious on what tool was being leveraged for this capability and in doing a quick search on the ESXi filesystem, I found that it was actually iPerf. The iPerf binary is located in /usr/lib/vmware/vsan/bin/iperf and looks to have been bundled as part of ESXi starting with the vSphere 6.0 release from what I can tell.

UPDATE (10/19/23) - As of ESXi 8.x, you may run into following error when attempting to start running iperf:

iperf3: running in appDom(30): ipAddr = ::, port = 5201: Access denied by vmkernel access control policy

To workaround this, you can run the following command:

esxcli system secpolicy domain set -n appDom -l disabled

and re-enable (use "enforcing" as the value) once you have completed your iperf test both on the server and client ESXi host.

UPDATE (09/20/22) - As of ESXi 7.0 Update 3 20036589 (possibly earlier) and later, you no longer need to make a copy of the iperf3 utility. You can simply run it from /usr/lib/vmware/vsan/bin/iperf3 and you also do NOT have to lower the security by changing ESXi Advanced Setting execInstalledOnly to FALSE

UPDATE (10/02/18) - It looks like iPerf3 is now back in both ESXi 6.5 Update 2 as well as the upcoming ESXi 6.7 Update 1 release. You can find the iPerf binary under /usr/lib/vmware/vsan/bin/iperf3

One interesting thing that I found when trying to run iPerf in "server" mode is that you would always get the following error:

bind failed: Operation not permitted

The only way I found to fix this issue was to basically copy the iPerf binary to another file like iperf3.copy which it would then allow me to start iPerf in "server" mode. You can do so by running the following command on the ESXi Shell:

cp /usr/lib/vmware/vsan/bin/iperf3 /usr/lib/vmware/vsan/bin/iperf3.copy

Running iPerf in "Client" mode works as expected and the copy is only needed when running in "server" mode. To perform the test, I used both my Apple Mac Mini and the Intel NUC which had ESXi running with no VMs.

I ran the iPerf "Server" on the Intel NUC by running the following command:

/usr/lib/vmware/vsan/bin/iperf3.copy -s -B [IPERF-SERVER-IP]

Note: If you have multiple network interfaces, you can specify which interface to use with the -B option and passing the IP Address of that interface.

I ran the iPerf "Client" on the Mac Mini by running the following command and specifying the address of the iPerf "Server":

/usr/lib/vmware/vsan/bin/iperf3 -n 800M -c [IPERF-SERVER]

I also disabled the ESXi firewall before running the test, which you can do by running the following command:

esxcli network firewall set --enabled false

Here is a screenshot of my iPerf test running between my Mac Mini and Intel NUC. Hopefully this will come in handy for anyone needing to run some basic network performance tests between two ESXi hosts without having to setup additional VMs.

vSphere 6.0 Update 2 hints at Nested ESXi support for Paravirtual SCSI (PVSCSI) in the future

03.14.2016 by William Lam // 6 Comments

Although Nested ESXi (running ESXi in a Virtual Machine) is not officially supported today, VMware Engineering continues to enhance this widely used feature by making it faster, more reliable and easier to consume for our customers. I still remember that it was not too long ago that if you wanted to run Nested ESXi, several non-trivial and manual tweaks to the VM's VMX file were required. This made the process of consuming Nested ESXi potentially very error prone and provide a less than ideal user experience.

Things have definitely been improved since the early days and here are just some of the visible improvements over the last few years:

Prior to vSphere 5.1, enabling Virtual Hardware Assisted Virtualization (VHV) required manual edits to the VMX file and even earlier versions required several VMX entries. VHV can now be easily enabled using either the vSphere Web Client or the vSphere API.
Prior to vSphere 5.1, only the e1000{e} networking driver was supported with Nested ESXi VMs and although it was functional, it also limited the types of use cases you might have for Nested ESXi. A Native Driver for VMXNET3 was added in vSphere 5.1 which not only increased the performance that came with using the optimized VMXNET3 driver but it also enabled new use cases such testing SMP-FT as it was now possible to get 10Gbe interface to Nested ESXi VM versus the traditional 1GBe with e1000{e} driver.
Prior to vSphere 6.0, selection of ESXi GuestOS was not available in the "Create VM" wizard which meant you had to resort to re-editing the VM after initial creation or using the vSphere API. You can now select the specific ESXi GuestOS type directly in the vSphere Web/C# Client.
Prior to vSphere 6.0, the only way to cleanly shutdown or power cycle a Nested ESXi VM was to perform the operation from within the system as there was no VMware Tools support. This changed with the development of a VMware Tools daemon specifically for Nested ESXi which started out as a VMware Fling. With vSphere 6.0, the VMware Tools for Nested ESXi was pre-installed by default and would automatically startup when it detected that it ran as a VM. In addition to power operations provided by VMware Tools, it also enabled the use of the Guest Operations API which was quite popular from an Automation standpoint.

Yesterday while working in my new vSphere 6.0 Update 2 home lab, I needed to create a new Nested ESXi VM and noticed something really interesting. I used the vSphere Web Client like I normally would and when I went to select the GuestOS type, I discovered an interesting new option which you can see from the screenshot below.

It is not uncommon to see VMware to add experimental support for potentially new Guest Operating Systems in vSphere. Of course, there are no guarantees that these OSes would ever be supported or even released for that matter.

What I found that was even more interesting was that when select this new ESXi GuestOS type (vmkernel65) is what was recommended as the default virtual hardware configuration for the VM. For the network adapter, it looks like the VMXNET3 driver is now recommended over the e1000e and for the storage adapter the VMware Paravirtual (PVSCSI) adapter is now recommended over the LSI Logic Parallel type. This is really interesting as it is currently not possible today to get the optimized and low overhead of the PVSCSI adapter working with Nested ESXi and this seems to indicate that PVSCSI might actually be possible in the future! 🙂

I of course tried to install the latest ESXi 6.0 Update 2 (not yet GA'ed) using this new ESXi GuestOS type and to no surprise, the ESXi installer was not able to detect any storage devices. I guess for now, we will just have to wait and see ...

Adding custom VSAN BIOS splash screen to the Intel NUC

03.06.2016 by William Lam // 5 Comments

One of the last things I wanted to look into after setting up my new VSAN 6.2 home lab on the new 6th Gen Intel NUC was to add a custom BIOS splash screen giving my system a personal touch. Updating the BIOS splash screen would require flashing the BIOS itself which gave me some concerns after hearing about the BIOS v33 issue in which the M.2 slot would no longer be detected after the update. Although there was a simple workaround after the update, I still wanted to be cautious. Over the weekend I had noticed that Intel had released BIOS v36 for the Intel NUC which resolved the M.2 issue among a few others. I decided to give it a shot and hope that I that I do not brick my NUC.

I am happy to say that I was successful in updating to the latest Intel NUC BIOS and as you can see from the screenshot below, I was also able to replace the default Intel BIOS splash screen with a Captain VSAN BIOS splash screen (TV is 46" for those wondering) 🙂

The process for building and customizing your Intel NUC BIOS is relatively straight forward but because I waited until after I had everything installed, it ended up being a bit more work than I had hoped. To customize your BIOS, Intel provides a Microsoft Windows only utility called Intel Integrator Toolkit. The easiest way to build and update your BIOS is to initially start off by installing Microsoft Windows on the Intel NUC itself which then allows you to easily flash the BIOS using the executable that is generated from the toolkit. Since I had already consumed both of my SSDs for VMware VSAN and Microsoft Windows does not allow you to install its OS directly onto a USB device, I had to use this method here to install a bootable version of Microsoft Windows onto the USB device since I did not want to blow away my VSAN setup.

OK, so now onto the cool stuff. Below are the instructions on how to build and customize your BIOS for the Intel NUC. If you would like to use the exact same BIOS splash screen as well as update to the latest BIOS v36 and do not want to go through the hassle, I have made my custom VSAN BIOS image available here. You just need to download the executable and run it on the Intel NUC itself which must be running Microsoft Windows (I used 8.1) and then follow the screens on flashing your BIOS.

Step 1 - Download the following two packages and transfer them to Microsoft Windows image running on your NUC:

Step 2 - Install the Intel Integrator Toolkit and then start the program

Step 3 - Select the "Customize a BIOS file" option and load either the custom VSAN BIOS image which I have made available here OR load the NUC BIOS v36 file you had downloaded earlier.

Step 4 - In the lower left hand corner, browse for the graphic image that you wish to use for your BIOS splash screen (images with black background works the best). For those interested, you can find the Captain VSAN image that I had used here. The tool actually supports several image formats in addition to the default BMP such as JPEG and PNG, you just need to change the extension type. There is a size limitation, but the nice thing about the tool is that there is an option to compress the image when it detects it is too large. Make sure to change the image for the four different options by clicking on the drop down wizard. I thought I only had to replace the first image but it looks like other versions of the splash screen is also used and it is best to just replace them all. You also have the option of changing other default settings in the BIOS, feel free to click on the tooltip for details on each of the options.

Step 5 - Once you are done customizing your BIOS, you will then save your changes and the tool will produce a single Windows executable (SY0036.exe) which you will run on the NUC itself to flash the BIOS. You will be prompted with a couple of questions and once the process begins, it will restart and you will need to confirm one more time before the imaging process starts. If everything was successful, you should now see a new BIOS splash screen replacing the default Intel image. There is a good chance you may go through this process a few times depending if you are happy with the splash screen display. I think it took me about three tries. Hope this helps anyone looking to add that personal touch to their home lab!