WilliamLam.com

How to install all versions of ESX and ESXi in VM?

by // 11 Comments

Thanks goodness for Virtualization and the ability to easily install ANY operating system inside of a vSphere Virtual Machine including the very first release of ESX 1.0, which is more than 22 years old now.


While going through the process of installing each of the major VMware ESX and ESXi releases, I had made notes for each of the VM configurations that I had used and any other issues I may have ran into. Figured I share this information in case anyone might be interested and this would also provide an online searchable reference in case I ever need to do this again for my future-self 😀

In addition to recording each installation, which you can watch via the Youtube playlists below, I also had some fun putting together this short compilation that summarizes all the VMware ESX and ESXi releases over the past 22 years. Definitely recommend checking it out and be sure to 👍🔊😉

[Read more...]

Executing Commands During Boot Up In ESXi 5.1

by // 6 Comments

There maybe certain use cases where you need to execute a command or series of commands during the boot up of an ESX(i) host and historically administrators have added commands to the /etc/rc.local which is one of the last scripts to be executed in the boot up process. However, with ESXi 5.1, the location of the file has changed from /etc/rc.local to /etc/rc.local.d/local.sh.

VMware also provides a KB2043564 that describes the locations for the various version of ESX(i):

  • In ESX 3.x/4.x - You would add the command(s) to /etc/rc.d/rc.local
  • In ESXi 4.x/5.0 - You would add the command(s) to /etc/rc.local
  • In ESXi 5.1 - It has changed to /etc/rc.local.d/local.sh

Disclaimer: As mentioned in the VMware KB, though this is supported, it is still not recommended that you edit these files unless directed by VMware support or under special scenarios.

A question that came up recently was about automatically loading the "multiextent" VMkernel module (which is required if you wish to use the 2gbsparse VMDK format, you can find more details in this blog article here) during the boot up of an ESXi 5.1 host as this had to be done manually, even if you had enabled the module. To do so, you just need to edit the /etc/rc.local.d/local.sh and add the following command above the "exit 0".

localcli system module load -m multiextent

Note: The reason I used localcli versus ESXCLI is that hostd may not be completely ready and hence the command may fail during the boot up process. One can also loop and wait for ESXCLI to be ready, but this is another way of performing the operation.

 

Adding Non-Supported ESXi Builds to VIN (vSphere Infrastructure Navigator)

by // 4 Comments

I was recently asked whether it was possible to add a non-supported ESXi host into VIN (vSphere Infrastructure Navigator)? The reason for this request is if you are running an ESX(i) build which is not on the list of supported builds, VIN would fail to discover virtual machines on that host. You may see the following error "Access failed. Unsupported ESX version"

The latest release of VIN 1.2 supports the following ESX(i) builds:

    • ESX/ESXi 3.5 (builds 425420, 408533, and 409724)
    • ESX/ESXi 4.0 (builds 398348, 403553, and 403554)
    • ESX/ESXi 4.1 (builds 433742, 433803, and 433804)
    • and all builds of ESXi 5.x.

If you happen to be running an ESX(i) build which is not listed but the build number is greater than the ones shown above, then there is a workaround. You can add the non-supported ESX(i) build into VIN's whitelist which would allow VIN to discover the virtual machines. In the example below I will be adding an ESXi 4.1 Update 3 Build 800380 which is not listed as a supported build.

Disclaimer: ESX(i) hosts with build numbers that are smaller than the ones listed may still be added, but this will most likely not be supported as the list of default build numbers are the minimum requirements. Please thoroughly test this in a lab environment before applying to your production environment.

You will need SSH access to your VIN appliance and before we get started, we will quickly verify the list of supported ESX(i) build versions by querying the VIN database (I was able to find the details in /var/log/vadm/dbconfig.log). Run the following command which will connect to VIN Postgres DB:

psql -h 127.0.0.1 -U vadm -d inception

The password for the database is vadm

Next, we will run the following SQL query to display the list of supported ESX(i) build numbers which should match the release notes. Run the following command:

select * from valid_host_build;

As you can see from the screenshot, the ESX(i) build numbers matches those listed in the VIN 1.2 release notes and we can also see that a wildcard is also a valid input value for ESXi 5.x which denotes any build of 5.x supported as noted in the release notes.

To add a non-supported ESXi build number into VIN's DB, we will be using the following script /opt/vadm-engine/set_valid_host_versions.sh which is located in the VIN appliance.

Note: You do not need to stop or restart the VIN service to run the command.

The script accepts a very simple XML file that contains the list of supported ESX(i) build numbers and it is very IMPORTANT to note that this will override the original defaults. This is part of the reason we performed a query to the VIN DB to ensure we have a copy of the original build numbers as a reference.

To add our additional ESXi build number, we will need to construct an XML file containing both the original build numbers as well as our non-supported. In this example, I created a file called myHostVersion.xml (based on the original DB data) which contains following:
Next we will pass in our XML input file to the set_valid_host_versions.sh script. Here is a screenshot of what that looks like after the operation has been successfully completed:

If we log back into the VIN DB and query the list of supported ESX(i) builds, we should be able to see our new build number that we inserted into the DB along with the original defaults:

During the next automatic discovery cycle, VIN should now be able to discover virtual machines running on the ESXi host that was not supported earlier.