WilliamLam.com

How to Create Bootable ESXi 5 ISO & Specifying Kernel Boot Options

by // 21 Comments

This week I helped to answer a few questions about creating your own ESXi 5 bootable ISO along with automatically using a static IP Address when the custom ISO first boots up. Although all this information is available via the vSphere documentation, it may not always be easy to put all the pieces together and thought I share the steps for others to also benefit.

You will need access to a UNIX/Linux system and a copy of the base ESXi 5 ISO image. In this example I will be using VMware vMA and VMware-VMvisor-Installer-5.0.0.update01-623860.x86_64.iso and walk you through two different configurations. We will also be referencing the vSphere documentation Create an Installer ISO Image with a Custom Installation or Upgrade Script and Kernel Boot Options.

Create ESXi 5 Bootable ISO w/Remote ks.cfg:

In this configuration, we will create a custom ESXi ISO that will boot with a static IP Address and use a remote ks.cfg (kickstart) configuration file.

Step 1 - Mount base ESXi ISO using the "mount" utility:

$ mkdir esxi_cdrom_mount
$ sudo mount -o loop VMware-VMvisor-Installer-5.0.0.update01-623860.x86_64.iso esxi_cdrom_mount

Step 2 - Copy the contents of the mounted image to a local directory called "esxi_cdrom":

$  cp -r esxi_cdrom_mount esxi_cdrom

Step 3 - Unmount the ISO after you have successfully copied it and change into the esxi_cdrom directory

$ sudo umount esxi_cdrom_mount
$ cd esxi_cdrom

Step 4 - Edit the boot.cfg and specifically the "kernelopt" line to not use the weasel installer but kickstart and also specifying the remote location of your ks.cfg. To get more details on the various kernel boot options, please take a look at the vSphere Boot Options documentation above.

You will also need to specify the static IP Address you wish to have the host automatically use when the ISO first boots up on the same line.

Step 5 - Once you have finished your edits and saved the boot.cfg, you will now change back to the parent directory and use the "mkisofs" to create your new bootable ISO. In this example, we will name the new ISO "custom_esxi.iso":

$ sudo mkisofs -relaxed-filenames -J -R -o custom_esxi.iso -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table esxi_cdrom/

You now have a new bootable ESXi 5 ISO called "custom_esxi.iso" which will now automatically boot up with the specified static IP Address and install based on the ks.cfg that was specified.

Create ESXi 5 Bootable ISO w/Local ks.cfg:

Similar to the above configuration, we will create a custom ESXi ISO that will boot with a static IP Address but use a local ks.cfg (kickstart) configuration file that will be included within the custom ISO.

Step 1 through 3 is exactly the same as above

Step 4 - By default, a basic ks.cfg is included in the ESXi 5 ISO in /etc/vmware/weasel/ks.cfg and we will create a custom *.tgz file that will include our ks.cfg within the ISO. First off by creating a temporary directory which will be used to store our ks.cfg:

$ mkdir -p temp/etc/vmware/weasel

Step 5 - Copy your ks.cfg file into the temp/etc/vmware/weasel:

$ cp ks_custom.cfg temp/etc/vmware/weasel

Step 6 - Create a *.tgz file containing the path to our ks.cfg using the "tar" utility. In this example, we will called it customks.tgz:

$ cd temp
$ tar czvf customks.tgz *

Step 7 -  Copy the customks.tgz from temp directory to your esxi_cdrom directory:

$ cp temp/customks.tgz esxi_cdrom

Step 8 -  Change into the "esxi_cdrom" directory and edit the boot.cfg just like the above, but we will be using the "file://" stanza to specify the path to our ks.cfg, static IP Address as well as adding our customks.tgz to the module list to ensure that it loads up which contains the actual ks.cfg file that is called in the boot.cfg.

Step 9 - Same as Step 5 above, you now just need to run the "mkisofs" utility to create your bootable ISO.

You now have a new bootable ESXi 5 ISO called "custom_esxi.iso" which will now automatically boot up with the specified static IP Address and install based on the ks.cfg that is included within the ISO.

Ghetto webAccess for ESXi

by // 14 Comments

I got the idea for this post a few months back after noticing several questions on the VMTN forums on how to enable webAccess for ESXi. With ESXi, the webAccess interface is no longer available as it was with classic ESX. After seeing the question and randomly browsing through the various flings on VMware Labs, I noticed an interesting fling called Ops Panel for ESX. Ops Panel provides a simple javascript that leverages the vSphere MOB to perform basic power operations for virtual machines and it is loaded onto the homepage of a classic ESX host remotely using Greasemonkey.

I immediately wondered if I could run the javascript directly on an ESX or ESXi host without the use of Greasemonkey. With a quick tweak of the default index.html homepage, I was able to get a simple "ghetto" webAccess running on both an ESX and ESXi host. I also ran into several bugs, one that dealt with how the power state of a virtual machines was being captured by the differences in the ESX(i) 4.0, 4.1 and 5.0 APIs and a recent fix to a CSRF (Cross-Site Request Forgery) vulnerability in ESX(i) 4.1 Update 1 that made it difficult to get Ops Panel running on more than just ESX(i) 4.0.

I reached out to the fling creator Ivan Donchev and he was kind enough to help assist me in the issues I ran into and also provided an updated version of his script to properly handle both the power state and the CSRF workaround. He recently published an update to his script a few weeks back supporting both ESX 4 and ESXi 5 but missed ESX(i) 4.1 support due to limited amount of testing. This was an easy fix and I modified the script to include support for ESX(i) 4.1 and also changed the default power off operation to a guestOS shutdown. The modified version of the script can be downloaded here.

When you browse to the homepage of your ESX(i) host using the browser, you will be prompted to login which require the same credentials as if you were to login to the host directly using the vSphere Client or vSphere MOB.

Once you have logged in, it will search for all virtual machines running on the host and generate the list of virtual machines and their respective power states.

You can then perform the appropriate power operation such as a power on, shutdown or suspend using the icons on the right. This can be really useful if you don't have access to vCenter Server, vSphere Client or SSH access to the host but just have a web browser.

To load the Ops Panel script on an ESX(i) host, you will need to do the following:

Note: These instructions are applicable for both ESX and ESXi, but with ESXi, it is important that the commands to copy both the modified index.html and Ops Panel script to docroot are executed as changes are not persisted after a reboot for ESXi hosts.

You can also add this to your kickstart file by appending the lines above in your %firstboot stanza so you automatically get Ops Panel after install. Though this will not give you a full webAccess that classic ESX did but it definitely is a useful way to quickly get to your virtual machines and perform simple power operations using a web browser.

How to Automate the Upgrade of Classic ESX 4.x to ESXi 5

by // 3 Comments

In prior releases of ESXi, there was not a supported method of upgrading from classic ESX to ESXi, you had to perform a clean installation. With the release vSphere 5, ESXi is the only available option and providing a supported and easy method for migrating to ESXi will be very helpful for users. There are currently three options of migrating/upgrading from ESX 4.x to ESXi 5. Going forward in the future, two additional methods will be available for upgrading ESXi 5.x to subsequent update/patch releases.

Here is a table of the supported ESXi 5 upgrade options:

Upgrade Method Upgrade from ESX or ESXi 4.x to ESXi 5.0 Upgrade or Patch from ESXi 5.0 to ESXi 5.n
vSphere Update Manager yes yes
Interactive upgrade from CD, DVD, or USB drive yes yes
Scripted upgrade yes yes
vSphere Auto Deploy no yes
esxcli no yes

The first two options should be pretty straight forward and I won't go into any details, but if you are interested, check out Ivo Beeren's post here. If you decide to use VUM to perform you upgrade, make sure you check out this post about lopsided bootbanks before doing so. The 3rd option is a new feature in a kickstart installation and you now can specify two additional types of installation:

  • upgrade - Tries to perform an upgrade from ESX(i) 4.x to ESXi 5.x
  • installorupgrade - Tries to perform an upgrade from ESX(i) 4.x to ESXi 5.x, if it fails, it will perform a clean installation

In addition to the new installation types, there are two new options that can be specified:

  • --deletecosvmdk - If the system is being upgraded from ESX, remove the directory that contains the old Service Console VMDK file, cos.vmdk, to reclaim unused space in the VMFS datastore
  • --forcemigrate - If the host contains customizations, such as third-party VIBS or drivers, that are not included in the installer .ISO, the installer exits with an error describing the problem. The forcemigrate option overrides the error and forces the upgrade

Here is an example of kickstart specifically for upgrading from ESX 4.x to ESXi 5:

Note: One thing I noticed from the upgrade is that even if you specify a new root password, the current password is still preserved. Virtual machines located on local VMFS volumes will also be preserved as long as you do not use the --overwritevmfs option

You will also know that an ESXi 5 host was upgraded from ESX 4.x when you login to ESXi Shell, a motd will display a message.

As you can see you have several options of upgrading both ESX(i) 4.x to ESXi 5, though if you have a choice between an upgrade and reinstall, my personal preference would still be a clean installation via kickstart or host profiles.