WilliamLam.com

w00t! VMware Tools for Nested ESXi!

by // 40 Comments

I have been working with Nested ESXi since it original inception and this technology has greatly benefited me and the entire VMware community, especially when it comes to learning about VMware software and being able to easily prototype something before installing it on actual hardware. However, one thing that I felt that has been missing for awhile now is the ability to run an instance of VMware Tools within a Nested ESXi VM. I have personally been asking for this feature for a couple of years and I know many in the VMware community have expressed interests as well.

I am super excited to announce that VMware has just released a new Fling that provides you with a VIB that you can install VMware Tools inside a Nested ESXi host. I originally showed a demo of this at VMworld Barcelona in my vBrownBag Tech Talk and as I mentioned we would be releasing this as a VMware Fling very soon. So here it is!

UPDATE (08/20/15) - An updated version of VMware Tools for Nested ESXi was just published, make sure to download latest version and you can find more details here.

Requirements:

  • Nested ESXi running 5.0, 5.1 or 5.5 

Installation:

To install the VIB, you simply just need to download it and upload the VIB it to your Nested ESXi datastore and then run the following commands:

esxcli system maintenanceMode set -e true
esxcli software vib install -v /vmfs/volumes/[VMFS-VOLUME-NAME]/esx-tools-for-esxi-9.7.0-0.0.00000.i386.vib -f
esxcli system shutdown reboot -r "Installed VMware Tools"

You can also install the VIB directly from VMware.com if you have direct or proxy internet connectivity from your ESXi host by running the following commands:

esxcli network firewall ruleset set -e true -r httpClient
esxcli software vib install -v http://download3.vmware.com/software/vmw-tools/esxi_tools_for_guests/esx-tools-for-esxi-9.7.0-0.0.00000.i386.vib -f

Once the VIB has been successfully installed, you will need to reboot the host for the changes to take effect. To verify, you can now login to either your vSphere Web/C# Client and you should now see the status for VMware Tools for your Nested ESXi host showing green and the IP Address of the Nested ESXi host should be displayed.

So why would you want to do this? Well, there’s a couple of reasons actually. The first one is pretty basic, which is when I need to reboot or shutdown a Nested ESXi VM, instead of having to jump into the VM console or SSH into ESXi host, I could just right click in the vSphere Web/C# Client and just say shutdown or reboot. I also tend to do all sorts of craziness in my lab (I’m sure this is an understatement for folks that know me) and may often break networking connectivity to my Nested ESXi VM. In vSphere 5.0, we introduced the Guest Operations API (formally known as VIX API) which is now part of the vSphere API. This API is actually quite handy as it allows you to perform guest operations within the VM without needing network connectivity as it relies on the fact that VMware Tools is running (pretty cool stuff!).

Here is a screenshot demonstrating the executing of vmkfstools through the Guest Operations API to one of my Nested ESXi VM:

A couple of things to note:

  • If you install VMware Tools on Nested ESXi VM, you will NOT be able to just right click in the UI and say install/upgrade
  • If you wish to integrate this into you ESXi image, you can take a look at a community tool  called ESXi-Customizer created by Andreas Peetz which I have used in the past and works great. Image Builder does not support raw VIBs, only zip files which may need to contain additional metadata information. If you want to create an offline bundle instead to then use Image Builder to create your custom ISO, Andreas has a new tool you can take a look at here.

Finally, if you have any feedback (likes/dis-likes), thanks, comments please head over to the VMware's Fling page for VMware Tools for Nested ESXi and leave a comment. I am sure the Jim Mattson the engineer who built this Fling would greatly appreciate any feedback you may have.

How to clear the ARP cache in ESXi prior to vSphere 5.5

by // 3 Comments

Yesterday, I wrote an article about a new ESXCLI command that will be available as part of the soon to be released vSphere 5.5 release which allows a user to clear the ARP cache on an ESXi 5.5 host. It was my understanding that with past releases of ESXi, that it is not possible to clear the ARP cache. While working on that article, I came across an internal thread and learned that it was possible to clear ARP entries prior to ESXi 5.5, however the method is not as ideal as using the new ESXCLI command.

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

In ESXi 5.1, you can list the current ARP entries for an ESXi host by running the following ESXCLI command:

esxcli network ip neighbor list

To clear a particular ARP entry, you will need to use the unsupported vsish interface. To delete a specific ARP entry, you will need to run the following command:

vsish -e set /net/tcpip/v4/neighbor del [IP-ADDRESS]

Here is a screenshot of listing the current ARP entries using ESXCLI and then deleting one of entries using vsish:

As mentioned in my previous article, I am glad we have made this into an official command in ESXCLI 5.5, but if you are in a crunch you can still clear an ARP entry if you are not running ESXi 5.5 using vsish.

vSphere Security Hardening Report Script Updated for vSphere 5.1

by // 10 Comments

A public draft of the vSphere Security Hardening Guide for vSphere 5.1 was released a few weeks back by my colleague Mike Foley. Since then I have been asked by several people if I had a chance to update my vSphere Security Hardening Report Script. The answer was unfortunately no due to other projects I had been working on and this script as well as others are maintained outside of my normal day job. I finally found some time this past weekend to go through the 5.1 revision of the hardening guide and make the necessary updates to my script which includes a few additional checks.

The script continues to provide backwards compatibility to previous releases of the vSphere Security Hardening Guide for vSphere 5.0, 4.1 and 4.0. Maintaining this compatibility is actually quite a challenge due to small minor changes in the hardening guide from previous versions, but I am please to say the latest 5.1 draft has now been implemented.

Disclaimer: This script is not officially supported by VMware, please test this in a development environment before using on production systems.  

Here is a sample output for the Security Hardening Report for a subset of my vSphere 5.1 home lab environment using "profile1" check:
vmwarevSphereSecurityHardeningReport-SAMPLE.html

For more details about the security hardening script, please refer to the documentation here.

If you have any feedback/questions on the vSphere Security Hardening Guide itself, make sure you to leave your comments and questions here. If you have any feedback/questions regarding the script, please join the vSphere Security Hardening Report VMTN Group for further discussions.