kickstart

Configuring dnsmasq as PXE Server for ESXi

07/09/2020 by William Lam Leave a Comment

One really cool thing that I came to learn while setting up the infrastructure to network boot the latest Raspberry Pi 4 was the use of dnsmasq, which I have used in the past but I did not realize it could do so much more. In addition to providing DNS services, it can also be configured to run TFTP and provide DHCP capabilities which can then be used to support PXE installations.

Another neat feature of dnsmasq is ability to proxy to an existing DHCP server which is extremely useful for anyone with an existing DHCP infrastructure. Given the simplicity of dnsmasq and having already set this up for the rPI, I figure it would also be useful to take folks through in setting up dnsmasq to also support ESXi installations over PXE, since this still comes up from new folks just getting started with ESXi kickstart automation.

For more details about PXE installation of ESXi, I highly recommend this whitepaper and although it states 6.0, the concepts and configurations are still applicable to the latest ESXi 7.0 release.

How to prevent physical CD-ROM from ejecting after installing or upgrading ESXi?

07/15/2019 by William Lam Leave a Comment

While catching up on some news over the weekend, I had noticed a VMware Reddit thread asking a pretty interesting question on how to prevent the physical CD-ROM tray from ejecting after installing or upgrading ESXi? This behavior occurs whether you are using a physical CD-ROM media or a "Virtual" ISO image via an out-of-band interface like an iDRAC or iLO. If you are automating the installation or upgrade using Auto Deploy or network installation such as Kickstart, this is not a problem.

However, I was a bit surprised to hear that this was still a pain point in 2019, as many of the new servers in market do not even include an option for CD-ROM. Some of the suggestions really brought me back to the early 2000's including physically taping up the CD-DROM tray, which I have definitely seen customers doing but this is not a scalable solution and it requires a visit to the datacenter.

One easy solution that I had suggested was to take advantage of ESXi's scripted installation capability also known as Kickstart and use the supported ESXi --noeject option after reboot. Since the install/upgrade was being done manually, the added benefit of this solution is that you can now have it automated 🙂 The other nice thing about this option is that you can specify the kickstart using the default ESXi ISO or you can take it a step further and embed the Kickstart with a custom ESXi ISO.

Automated ESXi Installation to USB using Kickstart

07/09/2019 by William Lam 9 Comments

I frequently re-install ESXi on my physical host for various types of testing as I normally work with a number of future releases. Although the process just takes a couple of minutes, having to enter the exact same information each time and also requiring a keyboard and monitor is not really ideal. For the majority, this is really not a problem and manually going through the install workflow is fine for most folks, especially as this is an infrequent operation.

However, with some recent customer conversations, I thought it was worth while to re-visit this topic and demonstrating just how easy it is to automate the installation of ESXi with just a single bootable USB device and embedding an ESXi Kickstart Script. Even for infrequent installation and/or upgrades of ESXi for home labs, this can be a time saver, especially if you do not have monitor and keyboard just lying around. Below are instructions including a reference Kickstart example that folks can use as a starting point. For more advanced automation, please take a look at my ESXI Kickstart Resources as well as the official VMware documentation for ESXi Scripted Installations.

Revisiting prompting for user input during an interactive or scripted install of ESXi

01/10/2019 by William Lam 14 Comments

For those that have a need to prompt for additional user input during an installation of ESXi, whether that is an interactive session or using a scripted install (Kickstart) may have noticed the solution posted in my 2015 blog post no longer works with recent releases of ESXi (newer than 6.0).

I was recently contacted by VMTN community cacheman, who authored the original snippet after my 2011 post with an updated solution that would work with newer releases of ESXi (e.g. 6.5 or newer). Thanks to Chris, he discovered the following after taking another look at the initial hack:

It seems that the tty1 techsupport.sh which I had commented out in /etc/inittab is having no effect in these versions and the login prompt is starting on tty1. As far as I can tell this is because for versions >= 6.5, the init process starts before the extras.tgz is unpacked, so it reads the /etc/inittab that comes natively with ESXi rather than the modified one in extras.tgz.

Using ESXi Kickstart %firstboot with Secure Boot

06/26/2018 by William Lam 5 Comments

If you install ESXi via a Kickstart script and make use of the %firstboot option to execute commands on the first boot of the ESXi host after installation, you should be aware of its incompatibility with the Secure Boot feature. If you install ESXi where Secure Boot is enabled, the Kickstart will install ESXi normally only execute up to the %post section. However, it will not execute the %firstboot scripts and if you look at the /var/log/kickstart.log after the host boots, you should see the following message:

INFO UEFI Secure Boot Enabled, skipping execution of /var/lib/vmware/firstboot/001.firstboot_001

If you have Secure Boot enabled, %firstboot is not supported. The reason for this is Secure Boot mandates only known tardisks which can hold executable scripts, and a kickstart script is an unknown source so it can not run when Secure Boot is enabled. If you wish to continue using %firstboot scripts, the only option is to disable Secure Boot and then re-enable it after the installation. A preferred alternative is to convert your %firstboot logic into an external script which can then be applied using the vSphere API (recommended method) and this way you can still customize your ESXi host after the initial installations. I have already filed an internal documentation bug to add a note regarding Secure Boot and %firstboot, hopefully that will roll out with the net documentation refresh.

Quick Tip – What hashing algorithm is supported for ESXi Kickstart password?

05/21/2018 by William Lam 2 Comments

I had a question the other day asking whether the encrypted password which can be specified within an ESXi Kickstart file (denoted by the --isencrypted flag) can use a different hashing algorithm other than MD5? The answer is absolutely yes. In fact, MD5 as a default hashing algorithm has NOT been used for a number of releases, probably dating back to classic ESX (you know, the version that had the Service Console).

For all recent releases of ESXi including 5.5 to 6.7, the default hashing algorithm has been SHA512 for quite some time now. Below are two ways in which you can check which default hashing algorithm is currently being used:

Option 1 - SSH to ESXi host and take a look at /etc/pam.d/passwd

Option 2 - SSH to ESXi host and take a look at /etc/shadow and look at the field prior to the salt.

As a reference:

$1$ - MD5
$5$ - SHA256
$6$ - SHA512