Kickstart ESXi hosts on IBM/LENOVO servers w/PowerShell



Automatic/silent/unattended/kickstarted (all synonyms) installation itself is not a complicated process, but it requires some basic knowledge. Another is difficult here – deploy intermediate infrastructure for boot over network, which includes PXE, TFTP and DHCP server, and configure it all properly. Probably also you will need to configure the Web Server, Firewall and IBM servers themselves for PXE-booting. And for that, first, you need to have deep technical expertise in many areas and, secondly, it is a time-consuming process, well and thirdly, it is not always possible due to the intra-organization policies Emoj. If you, like me, don’t want to do it all, but still want to use all the charm of a silent installation Emoj, then this article is for you.

What we are going to learn?

  • How to create an ESXi installation script or kickstart file KS.CFG

  • How to edit the boot loader configuration file BOOT.CFG for reading instructions from your kickstart file.

  • How to put these files into the VMware Hypervisor installation disk image (ISO file) on PC with Windows OS installed (most guidelines used for this Linux).

  • How to edit my PowerShell script to suit your kickstart file(s).

  • How using my script and VMware Hypervisor installation disk image fully automatically (zero touch) to deploy ESXi hosts on IBM/LENOVO servers.

KS.CFG – ESXi installation script

  • KS.CFG – kickstart file is a text file that contains instructions for the ESXi installer. It replaces your answers during an interactive installation.

  • The file can include three types of instructions:

Instruction type Description
Supported Installation Script Commands Read VMware «vSphere Installation and Setup» document
ESXi commands Such as vim-cmd or esxcli
BusyBox commands cat/cp/mkdir etc.
  • Also you can declare and use variables, as I did in my file to set network parameters. I advise you to take it as an example for building your own file. During this article I will explain in detail all the commands that I used in my KS.CFG file.

What you should pay attention to?

  • The rootpw --iscrypted command contains encrypted root password. It is understood that store such a password in a clear text, even within the ISO-file is a potential threat, especially if you do not change it after installation. A reasonable question, where you can get it? To do so you should install reference ESXi exactly from the image that you want to use for silent installation, connect to that host via SSH and run the following command:

cat /etc/shadow | grep root | cut -d':' -f2


  • If security considerations do not bother you, or you change the root password at the end of the installation, you can use the rootpw without --iscrypted switch.

  • The install --firstdisk --overwritevmfs command on one hand is very flexible and versatile, on the other there is a risk accidentally format fiber LUN, containing important data, such as virtual machines’ files. There are two solutions, either use a more accurate directive such an install --disk=diskname or install --firstdisk=disk-type, either physically disconnect HBA adapters prior to installation (tester’s choice Emoj).

BOOT.CFG – boot loader configuration file

  • BOOT.CFG file is located in the ESXi installation image in directory \EFI\BOOT\. Such as KS.CFG it is a plain text file.

  • We are interested in only one line kernelopt=runweasel, which regulates the kernel boot options.

  • We need to replace it by kernelopt=ks=cdrom:/KS.CFG, thereby we point to installer where our KS.CFG file is located (cdrom:/KS.CFG – at the root of the image).

  • There is another optional, but an interesting directive title=. What you write in this line will be displayed at the top of the screen during installation.

  • The default is Loading ESXi installer. You can then place your ad here Emoj.


The BOOT.CFG file for example can be seen here.

Embed KS.CFG and BOOT.CFG files into ESXi image

  • Linux administrators uses mkisofs command-line utility to edit boot images. Windows administrators can use WinISO with excellent GUI.

  • Once you have created and saved KS.CFG and BOOT.CFG files, open the ESXi installation image using WinISO and add the KS.CFG file to the root of the image, as shown in the picture (Add Files menu):


  • Then add BOOT.CFG file to \EFI\BOOT\ directory:


  • Save your image (Save menu). The beauty is that the image will stay bootable!

Kickstart-VMHostIMM.ps1 – ESXi kickstart installation supervisor

  • We have created unattended installation image. So that’s all. All that’s left to do is to burn the disc and insert it into the server’s CDROM or mount the disk image into a server’s virtual drive and boot from it. Then sit back and enjoy the progress of the installation without any intervention on your part.

Why, then, you need this script?

Its operation can be divided into three main stages:

  • Necessary preliminary checks and configuring.

  • Mount the image and keep track of installation progress.

  • Post-installation configuring.

So, let’s start in order:

Necessary preliminary checks and configuring

  • A distinctive feature of this installation method is that each new ESXi host after installation will have the same IP address (the one assigned to a variable VMK0_IP within the KS.CFG file). On the one hand is the lack of because it does not allow you to run multiple simultaneous installations, which will lead to IP addresses conflict. However, it’s a big advantage for post-installation configuration, as you know in advance with which IP will boot each new host.

  • One of the main checks is to verify these three IP addresses: initial host’s IP address (initiated by VMK0_IP variable), management IP address (-MgmtIPv4 parameter) and vMotion IP address (-vMotionIPv4 parameter). Is IP address busy on the network and is it registered in DNS?

  • Since the initial host name, specified by command esxcli system hostname set in the KS.CFG file and the root password (specified by directive rootpw) are also constants, it makes sense to keep them in the administrator’s PC for initial authentication on all deployed hosts. For safe preserving of this sensitive data we will use encrypted XML file, so-called VI credential store. By default, this file is located in %APPDATA%\VMware\credstore\ directory and it looks like this vicredentials.xml one.

  • The script at startup checks whether there is already such an entry in the VI store and if not, create it. If you for some reason have changed the root password in the KS.CFG file, you can also change it in the VI store on your computer by running the script with –Cred parameter.

cd C:\scripts
Get-Help .\Kickstart-VMHostIMM.ps1 –Full
Get-Help .\Kickstart-VMHostIMM.ps1 -Examples
.\Kickstart-VMHostIMM.ps1 -Cred
  • It is important to say that this script is based on my IMM-Module PowerShell module and intended for IBM/LENOVO servers only.

  • To authenticate with IMM, the Get-IMMSupervisorCred function from the IMM-Module is used.

Get-Help Get-IMMSupervisorCred –Full
.\Kickstart-VMHostIMM.ps1 -IMMIPv4 '' -VMHostBorn 'esxdmz03' -Env DMZ -MgmtIPv4 '' -KickstartISO 'C:\ISO\Kickstart5.iso'
  • Then the script changes the server’s Boot Order to boot from your image to CD/DVD Rom -> Floppy Disk -> Hard Disk 0 -> PXE Network. If you need to preserve the original boot order, use –SaveBootOrder parameter, script will remember the existing boot order and restore it at the end of the installation.
.\Kickstart-VMHostIMM.ps1 -IMMHostname immprd11 -ESXi esxprd11 -MgmtIP "" -vMotionIP "" -KickstartISO 'C:\ISO\Kickstart6.iso' -SaveBootOrder

Mount the image and keep track of installation progress

  • Making sure that the boot order is successfully changed, the script mounts the image, specified by –KickstartISO parameter to server’s virtual drive and reboots the server. Have to understand that if the image that you created is not completely unattended (contains no sufficient information in terms of ESXi installer) or it contains critical errors in KS.CFG file, then the script will not work properly. I recommend that you first test your image manually making sure that it really will not require your intervention. If you have specified –SaveBootOrder parameter, then boot order will be restored before the first boot of the host.

  • Note that if your original boot order does not include a device from which the ESXi boots (directive install in KS.CFG file), the script will wait until you will correct this (either manually in server’s BIOS, or using IMM-Module.

Import-Module IMM-Module
Get-IMMServerBootOrder -IMM ’’
Set-IMMServerBootOrder –IMM ’’ –Boot1 'Embedded Hypervisor' –Boot2 'Hard Disk 0' –Boot3 'CD/DVD Rom'
  • Then you will see the installation progress, the script will keep track of all the restarts required during the installation process and in due time react to them (everything will take approximately half an hour).

Post-installation configuring

  • At the end of the installation the script tries to connect to your newly made host, but this time not through the IMM, but directly to the host (by the name assigned to the variable $ksCfgVMHost). For this to work, you are sure to have the following two conditions:

  • First, your computer must resolve the name specified in $ksCfgVMHost to an IP address, assigned to variable VMK0_IP in the KS.CFG file. It is advisable to register it in the DNS if someone else in your organization will use this script, but it will be enough to add it to the hosts file on your computer. For example, in my KS.CFG file the name esxprd00 (hostname or A-record) should be resolved to the IP address

  • Secondly, NICs (uplinks), defined in the KS.CFG file for host’s management must be connected to the appropriate physical network. For example, in my KS.CFG file:

  • Uplinks vmnic0 and vmnic1, connected to vSwitch0, it is provided by the following commands (lines beginning with # character are comments):

### Uplinks ###
esxcli network vswitch standard uplink add --uplink-name=vmnic0 --vswitch-name=vSwitch0
esxcli network vswitch standard uplink add --uplink-name=vmnic1 --vswitch-name=vSwitch0
  • The vSwitch0 contains Portgroup, named Management Network:
PGMGMT="Management Network"
### Portgroups ###
esxcli network vswitch standard portgroup set --portgroup-name="${PGMGMT}" --vlan-id=${VLANMGMT}
  • This Portgroup contains VMKernel management port:
### VMKernel ports ###
esxcli network ip interface add --interface-name=vmk0 --mtu=1500 --portgroup-name=${PGMGMT}
esxcli network ip interface ipv4 set --interface-name=vmk0 --ipv4=${VMK0_IP} --netmask= --type=static
esxcli network ip interface tag add -i vmk0 -t Management
  • Summarizing all the above, at least one network adapter (in my case vmnic0 or vmnic1) must be connected to the network VLAN 21. Why not both and at least one? Because in the Default Policies for vSwitch0 both adapters are active (--active-uplinks=)
### Default Policies ###
esxcli network vswitch standard policy failover set --active-uplinks=vmnic0,vmnic1 …
  • A few words about the indexing of network adapters. The Hypervisor automatically adds an index, starting from zero, to each network port (vmnic). Onboard (embedded) ports indexed primarily left to right, if you look back to the server. Additional adapters’ ports indexed top to bottom for ports within particular adapter and from left to right for adapters.

  • Unfortunately, this script is not universal in meaning that some things in it are closely linked to the configuration of your KS.CFG file(s). Why files? Of course, each image can have only one KS.CFG file, but you can have as many of images for different infrastructures or for different clusters, such as one for the production environment, one for tests or labs and one more for the DMZ.

  • All these images can be managed by one script. For this, -Env parameter was created. It takes one of the values specified by ValidateSet() attribute of the parameter:

#region Parameters
[ValidateSet('PRD', 'DMZ', 'LAB')]
  • Each of them is intended for a particular image, but rather for a specific KS.CFG file and has a collection of settings declared in the #region Initialize Kickstart Configuration sets. Let’s say you want to add a new configuration and call it VDI, you simply add to the Switch operator one more value and the corresponding settings:
#region Initialize Kickstart Configuration sets
'VDI' {
$ksCfgVMHost = 'esxvdixx'
$ksCfgRoot = 'root'
$ksCfgMgmtIP = ''
$ksCfgMgmtMask = ''
$ksCfgvMoIP = ''
$ksCfgvMoMask = ''
$envDNSServer = 'VDI01'
$envDNSZone = ''
$envBehindFW = $false
  • The values of variables, starting with $ksCfg should match to the appropriate settings in KS.CFG file.

  • Variables, starting with $env relate to the infrastructure in which you deploy a new host: $envDNSServer and $envDNSZone there are DNS server and DNS zone in which the script will create the A-record for the new host. By the way, do not forget to install PowerShell DnsServer module before using the script, it is part of the RSAT (Remote Server Administration Tools).

  • And finally the variable $envBehindFW controls is network, where you deploy your ESXi host, allows to respond to the ping and communicate with DNS server from your administrative PC. If this variable is $true, the script will not check and create the A-record in the DNS and will not perform any checks of busy IP addresses (all these checks and actions you have to do yourself manually).

  • Do not forget to add your newly created configuration to the ValidateSet() attribute of -Env parameter as follows: [ValidateSet('PRD', 'DMZ', 'CLOUD', 'VDI')].

  • Finally the script renames the host to the name specified in the -VMHostBorn parameter, changes vMotion IP address, if you have specified it (-vMotionIPv4 parameter) and management IP address (-MgmtIPv4 parameter), than disconnects from the host and registers host in the DNS.

  • As a result, less than an hour you will get maximally configured, and most importantly standardized host, ready for registration in the vCenter server. This approach eliminates the errors and flaws that inevitably arise during manual installation and configuration.

  • Notice one of the last commands in the KS.CFG file:

### Copy %firstboot script logs to persisted datastore
cp /var/log/hostd.log "/vmfs/volumes/${vDS}/1boot-hostd.log"
cp /var/log/esxi_install.log "/vmfs/volumes/${vDS}/1boot-install.log"
  • Above commands copy log files, created during installation process to the Datastore LocalSSD-00, created during installation:

  • If something went wrong, you can always review these logs.


  • The script itself Kickstart-VMHostIMM.ps1 you can download here. It contains content based help and some examples. All this can be viewed using following commands (previously navigate to the folder where you have saved the script):

cd C:\scripts
Get-Help .\Kickstart-VMHostIMM.ps1 –Full
Get-Help .\Kickstart-VMHostIMM.ps1 –Examples
Get-Help .\Kickstart-VMHostIMM.ps1 –Parameter VMHostBorn

Here you can download all the files mentioned in the article.

  • Looking ahead, I will say that with the help of unattended ESXi installation image and Kickstart-VMHostIMM.ps1 script one administrator in one working day can completely from scratch deploy a cluster of 10-12 hosts, in parallel doing daily cares, which we always have in abundance.

Useful links

  • About Supported Installation Script Commands you can read this document from VMware vSphere Installation and Setup on pages 143-152.

  • Also I advise to read this Knowledge Base from VMware and be sure to look William Lam’s site Kickstart section.

  • About vim-cmd you can read here and esxcli commands described here.

You may also like:

IMM-Module – PowerShell module for IBM/LENOVO servers management
Connect-VMHostPutty – Open multiple putty sessions to ESXi hosts with no password

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s