WilliamLam.com

w00t! VMware Tools for Nested ESXi!

by // 42 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.

ESXi Simple Web (aka less ghetto webAccess)

by // 10 Comments

Do you remember webAccess for those of you who were fortunate enough to have worked with classic ESX? I do and I personally have found that feature in the past to be very useful especially when you need to perform a quick VM power operation and you just have access to a web browser. Recently, one of my readers, Wei Kin Huang left a comment on my blog about a very cool solution that he built called ESXi Simple Web which is based off of some earlier work I did with a VMware Fling called Ops Panel for ESX for which I created a Ghetto webAccess for ESXi.

In his own words, ESXi Simple Web provides the following:

Basic controls straight from the esxi host in the browser

This allows you to run basic operations against the ESXi MOB api from a simple web interface straight from the ESXi host without the need for the vCenter web client.

Inspired by virtuallyGhetto's Ghetto webAccess for ESXi

Wei's ESXi Simple Web definitely looks prettier and from what I can tell, it looks to be using Bootstrap, a popular web front-end framework for the UI. The web interface talks to the vSphere MOB which basically communicates to the vSphere API for providing the summary details and basic VM operations.

You can try out ESXi Simple Web by downloading the latest version over on his Github repo. Once downloaded, you just need to extract the content and SCP the "web" directory over to the ESXi host under /usr/lib/vmware/hostd/docroot

Here are a couple more screenshots of ESXi Simple Web running on my Apple Mac Mini with ESXi 5.5:

There is a Virtual Machines tab that you can drill down and get some information about your VMs and perform basic power on/off operations.

You can also drill down into an individual VM and get a nice thumbnail of the VM console as well as additional configurations for that VM.

If you are interested in adding additional functionality, you can contribute by sending a pull requests to esxi-simple-web Github project.

Quick Tip - Marking an HDD as SSD or SSD as HDD in ESXi

by // 9 Comments

This was a neat little trick that I picked up in one of our internal storage email distribution groups which I thought was quite interesting. Some of you may recall an article I wrote a few years back on how to trick ESXi 5 in seeing an SSD device which relied on adding an SATP rule for a particular storage device. The actual use case for this feature was that not all real SSD devices would automatically be detected by ESXi and this allowed a user to manually mark it as an SSD.

The other "non-official" use case for this feature allows a user to basically "simulate" an SSD by marking a regular HDD as an SSD and I this actually helped me test the new Host Cache (Swap-to-SSD) feature which was part of the vSphere 5 release. Recently there was a customer inquiry asking for the complete reverse, in which you could mark an SSD as an HDD. I am not sure what the use case was behind this request but I did learn it was actually possible using a similar method of adding a SATP rule to a device.

Note: If you are running Nested ESXi, a much simpler solution for simulating an SSD is to use the following trick noted here.

Before you begin, you will need to identify the storage device in which you wish to mark as an SSD or HDD. Use the following ESXCLI command to do so:

esxcli storage core device list

In the screenshot above, we can see for our device mpx.vmhba1.C0:T2:L0 shows "Is SSD" parameter as false. After running two commands below, we should then see that property change to true.

Marking HDD as SSD:

esxcli storage nmp satp rule add -s VMW_SATP_LOCAL -d mpx.vmhba1:C0:T2:L0 -o enable_ssd
esxcli storage core claiming reclaim -d mpx.vmhba1:C0:T2:L0

 

Marking SSD as HDD:

esxcli storage nmp satp rule add -s VMW_SATP_LOCAL -d mpx.vmhba1:C0:T1:L0 -o disable_ssd
esxcli storage core claiming reclaim -d mpx.vmhba1:C0:T1:L0

To perform the opposite, you simply just need to add the disable_ssd option. If you receive an error regarding a duplicate rule, you will need to first remove the SATP rule and then re-create with the appropriate option.

Another useful tidbit is that if you are running Nested Virtualization and the virtual disk of that VM is stored on an actual SSD, that virtual disk will automatically show up within the guestOS as an SSD so no additional changes are required.