WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple
You are here: Home / Automation / Semi-Interactive automated ESXi installation

Semi-Interactive automated ESXi installation

05.09.2011 by William Lam // 18 Comments

There was a recent thread in the VMTN community forums where a user wanted to provide user input prior to an automated ESXi installation. This may sound odd at first, especially when we are talking about an unattended installation, the last thing you want is any type of user interaction. The reason for this requirement was to maintain a generic kickstart configuration file and based on the site specific input (IP Address, Netmask, Gateway, Hostname and DNS Servers), the ESXi installation would be able to deploy and configure itself the same across multiple locations.

UPDATE (01/10/19) - For ESXi 6.5 or greater, please take a look at this blog post for an updated solution

UPDATE (10/28/15) - Please take a look at this blog post on how to prompt for user input during an interactive or scripted installation of ESXi.

The other reason for this requirement is that all hosts in the user's environment must be configured with a static IP Address, this is not an uncommon requirement for many production environments to not have DHCP enabled networks. I can only assume the initial network the host is being built is either a private build network or booting off of local media such as a USB or CD-ROM device.

Whether you are booting off of local media or via PXE over the network, you have the ability to specify some boot parameters which includes things like IP Address, Netmask, Gateway and DNS Servers. These "bootstrap" options are fully supported and documented in the ESXi Installation Section. You can also specify advanced VMkernel boot parameters which may not be officially supported by VMware, but you can take a look here for more details.The concept of specifying these boot parameters is nothing new and has been supported since the early days of classic ESX and other popular UNIX/Linux distros for PXE boot/installations.

When you boot the ESXi installer, you may have seen a screen similar to the following in which you have a few seconds to hit the "tab" key to edit the boot options.

Once you hit the "tab" key, you will be able to see what the default boot options are and if you are PXE booting, you will also see some IP information appended towards the end of the string. This is where you can append or update additional parameters and later read in by your kickstart script.

Here is an example of an ESXi installation being PXE booted over the network and I have added 4 supported boot parameters and 2 custom ones.

If you take a look at the screenshot, the "+++" IP information towards the end is what was given by the DHCP server but I am interested in specifying a different IP Address for the ESXi installer to boot from. I provided new entries for ip, netmask, gateway and nameserver. You can also see that I introduced two new variables called hostname and dc, these will be used to specify the hostname of the ESXi host and also the name of the datacenter which will be used later in the kickstart script to rename a datastore.

Note: If you redefine the IP information, you do not need to change the IP information found after the "+++", these will just be over-written with the new IP information.

When specifying these boot parameters, you need to make sure it is after the "vmkboot.gz" but before "--- vmkernel.gz". To help make this clear, I have colorized the section that was appended to the default options.

vmkboot.gz dc=ghettoDC hostname=vesxi41-2.primp-industries.com ip=172.30.0.200 netmask=255.255.255.0 gateway=172.30.0.1 nameserver=172.30.0.100 ks=http://172.30.0.108/esxi41u1/ks.cfg --- vmkernel.gz --- sys.vgz --- cim.vgz --- ienviron.vgz --- install.vgz

Note: You can create any custom variables, the key in using the custom variables will be parsing from the boot command line using vsish which will be defined in your kickstart script. This will work also work for local media, but you MUST use a kickstart to perform the actual installation or inject the kickstart script into a custom ISO.

After you have provided all the input, you will then boot the installer and the the following kickstart configuration file is used to parse the boot options using vsish.

accepteula
autopart --firstdisk --overwritevmfs
rootpw vmware
install url http://172.30.0.108/esxi41u1
reboot

%include /tmp/networkconfig

%pre --unsupported --interpreter=busybox

CMDLINE_FILE=/tmp/cmdline
ESXI_INSTALL_LOG=/var/log/esxi_install.log

# extract boot options
vsish -e get /system/bootCmdLine > ${CMDLINE_FILE}

# extract and set variables
HOSTNAME=$(cat ${CMDLINE_FILE} | grep hostname | sed -e 's/.*hostname=\([^ ]*\).*/\1/')
IPADDR=$(cat ${CMDLINE_FILE} | grep ip | sed -e 's/.*ip=\([^ ]*\).*/\1/')
NETMASK=$(cat ${CMDLINE_FILE} | grep netmask | sed -e 's/.*netmask=\([^ ]*\).*/\1/')
GATEWAY=$(cat ${CMDLINE_FILE} | grep gateway | sed -e 's/.*gateway=\([^ ]*\).*/\1/')
NAMESERVER=$(cat ${CMDLINE_FILE} | grep nameserver | sed -e 's/.*nameserver=\([^ ]*\).*/\1/')
DC=$(cat ${CMDLINE_FILE} | grep dc | sed -e 's/.*dc=\([^ ]*\).*/\1/')

# create networkline based on boot options
echo "network --bootproto=static --hostname=${HOSTNAME} --ip=${IPADDR} --netmask=${NETMASK} --gateway=${GATEWAY} --nameserver=${NAMESERVER} --addvmportgroup=0" > /tmp/networkconfig

# persist custom variables in ESXi install log for %post section
echo "GHETTO_CUSTOM_VARIABLE-DC ${DC}" >> ${ESXI_INSTALL_LOG}

%firstboot --unsupported --interpreter=busybox --level=9999

#extract custom variables in ESXi install log
DC=$(grep "^GHETTO_CUSTOM_VARIABLE-DC" /var/log/esxi_install.log | awk '{print $2}')

vim-cmd hostsvc/datastore/rename datastore1 "${DC}-datastore1"

vim-cmd hostsvc/maintenance_mode_enter
vim-cmd hostsvc/enable_remote_tsm
vim-cmd hostsvc/start_remote_tsm
vim-cmd hostsvc/enable_local_tsm
vim-cmd hostsvc/start_local_tsm

The script does the following:

  1. Reads the boot options using vsish and temporarily stores the output to /tmp/cmdline for later use
  2. Extracts all the relevant boot parameters in /tmp/cmdline and stores them in variables to be used in the script.
  3. Creates the "network" stanza for static IP assignment of the ESXi host which includes: Hostname, IP Address, Netmask, Gateway and Nameserver
  4. Writing out the custom variable "dc" into /var/log/esxi_install.log because this will be persisted through the reboot and can be later read in for any %firstboot operations.
  5. Upon the reboot, %firstboot will execute and read from /var/log/esxi_install.log to extract the "dc" variable in which it will use to rename the local datastore

Note: The above is just an example of what you can do with custom parameters. You can easily add as many as you need for site specific configurations and then use those input in your post configure your ESXi host. Also note that you do not need to make sure of ip,netmask,gateway,dns parameters to use custom variables, these are all optional.

You can add as many custom entries as you would like, but this can easily get error prone due to the amount of typing required. One thing you can do to minimize the amount of typos is to pre-specify the custom variables in your PXE/TFTP configuration file.

To do so, your PXE/TFTP configuration file would look something like this:

IMEOUT 300 #30 seconds
PROMPT 1
DEFAULT menu.c32
SAY -
SAY vga - Install esxi410u1 (vga console)
SAY -

LABEL www.virtuallyghetto.com - Semi-Interactive ESXi Install
KERNEL mboot.c32
APPEND vmkboot.gz dc= hostname= ip= netmask= gateway= nameserver= ks=http://172.30.0.108/esxi41u1/ks.cfg --- vmkernel.gz --- sys.vgz --- cim.vgz --- ienviron.vgz --- install.vgz
IPAPPEND 1

This not only reduces the amount of typing but also lets the user know what variables must be defined in order for the installation to proceed.

I totally understand where the user is coming from and I have had this requirement in the past but I think having a static DHCP entry and maintaining a simple configuration file can easily solve this problem. This not only makes the deployment process hands-off as it should be in the first place but also removing the human factor out of the equation. Can you imagine deploying 100-300 ESXi hosts in a day? I sure can not if I had to manually type out all those addresses by hand.

More from my site

  • Disable LUN During ESXi Installation
  • Automating ESXi 4.1 Kickstart Tips & Tricks
  • How to prevent physical CD-ROM from ejecting after installing or upgrading ESXi?
  • Automated ESXi Installation to USB using Kickstart
  • Revisiting prompting for user input during an interactive or scripted install of ESXi

Categories // Automation, ESXi Tags // ESXi 4.1, kickstart, ks.cfg

Comments

  1. *protectedJosh Justic says

    12/20/2011 at 7:18 pm

    William, You are awesome. We have been searching for the past few days on a method to create an interactive install for ESXi 5. Your method worked. We just need to update a few variables that were ESXi specific. Nice Work!

    Reply
  2. *protectedWilliam says

    12/20/2011 at 7:30 pm

    @Josh,

    Glad this was useful

    Reply
  3. *protectedJosh Justic says

    12/20/2011 at 10:41 pm

    If you would like a copy of the ESXi 5 script we used. Send me your email, and I'll send it over.

    Reply
  4. *protectedWilliam says

    12/20/2011 at 10:57 pm

    @Josh,

    If you would like to share, you can send it to admin[at]virtuallyghetto[dot]com

    Reply
  5. *protectedMaish Saidel-Keesing says

    06/06/2012 at 10:57 am

    Hi William - I gather this way can also be used to accept a root password as one of the variables.

    The problem though is that the password in then stored in plain text in the log file.

    Is there anyway to parse the bootCmdLine and then provide it as an encrypted string to the ks file?

    Reply
    • *protectedWilliam says

      06/06/2012 at 2:13 pm

      @Maish,

      Please refer to the vSphere documentation on kickstart - http://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.upgrade.doc_50%2FGUID-61A14EBB-5CF3-43EE-87EF-DB8EC6D83698.html

      The "rootpw" can be either plain text or the encrypted hash

      I've not tried this method with root pass, but it should work in %pre section which is what this script is doing. The only thing is you'll need to type out a very long string which is probably going to be error prone. Why not just have specific KS with their appropriate password or update it later

      Reply
  6. *protectedAnonymous says

    07/03/2012 at 1:32 am

    Hi William - been experimenting a lot with this... Sometimes results are unpredictable. Do you know if the variables you have (like nameserver, ip, hostname) are some kind of reserved vars for kickstart?

    Reply
    • *protectedWilliam says

      07/03/2012 at 5:36 am

      Take a look here http://pubs.vmware.com/vsphere-50/topic/com.vmware.vsphere.upgrade.doc_50/GUID-9040F0B2-31B5-406C-9000-B02E8DA785D4.html?resultof=%22%6b%69%63%6b%73%74%61%72%74%22%20 for the list of available default boot options params

      Reply
  7. *protectedMark Jones says

    01/15/2013 at 3:52 pm

    William,
    How come on the official documentation they do not list the hostname as a boot option? is that not valid?

    Reply
    • *protectedWilliam says

      01/15/2013 at 4:02 pm

      Hi Mark,

      Looking at the documentation, it doesn't look like hostname is not an official boot option and hence the custom parsing. I'm not sure why it's not, but if it's something you require, I would recommend filing an FR.

      Reply
  8. *protectedMark Jones says

    01/15/2013 at 5:40 pm

    Ok so maybe I am doing something incorrect here, but I did not specify network line in my KS file because I was hoping the network boot options I passed would be taken by the installer, but that doesn't appear to be the case.

    Is there anyway to pass the IP, netmask, even hostname that i specify in the boot options to the ks file or network option?

    Reply
    • *protectedWilliam says

      01/15/2013 at 6:54 pm

      Not sure I follow? If you take a look at this article, it does exactly what you're asking for, which is to specify the network settings during the boot option which can then be read by the KS

      Reply
  9. *protectedMatt says

    02/04/2013 at 5:12 pm

    William,

    How would this work for ESXi 5? Passing the IP, netmask, etc through the isolinux.cfg file is not the same as it was in 4.1.

    Reply
  10. *protectedVinx says

    01/17/2014 at 1:33 pm

    It works for ESXi 5.1 :

    - default pxe conf file (= isolinux.cfg) :
    KERNEL mboot.c32
    APPEND -c boot.cfg dc= hostname= ip= netmask= gateway= nameserver=

    - boot.cfg :
    bootstate=0
    title=Loading ESXi installer
    kernel=tboot.b00
    kernelopt=runweasel ks=http://ip/share/ks.cfg
    modules=b.b00 --- useropts.gz --- k.b00 --- chardevs.b00 --- a.b00 --- user.b00 --- s.v00 --- misc_cni.v00 --- net_bnx2.v00 --- net_bnx2.v01 --- net_cnic.v00 --- net_tg3.v00 --- scsi_bnx.v00 --- scsi_bnx.v01 --- scsi_bfa.v00 --- ima_be2i.v00 --- net_be2n.v00 --- scsi_be2.v00 --- scsi_lpf.v00 --- char_hpc.v00 --- char_hpi.v00 --- hp_ams.v00 --- hp_build.v00 --- hp_smx_p.v00 --- hpbootcf.v00 --- hponcfg.v00 --- hpssacli.v00 --- hptestev.v00 --- scsi_hps.v00 --- scsi_hpv.v00 --- net_igb.v00 --- net_ixgb.v00 --- scsi_mpt.v00 --- net_mlx4.v00 --- ima_qla4.v00 --- net_qlcn.v00 --- scsi_qla.v00 --- ata_pata.v00 --- ata_pata.v01 --- ata_pata.v02 --- ata_pata.v03 --- ata_pata.v04 --- ata_pata.v05 --- ata_pata.v06 --- ata_pata.v07 --- block_cc.v00 --- ehci_ehc.v00 --- weaselin.t00 --- esx_dvfi.v00 --- xlibs.v00 --- ipmi_ipm.v00 --- ipmi_ipm.v01 --- ipmi_ipm.v02 --- misc_dri.v00 --- net_e100.v00 --- net_e100.v01 --- net_enic.v00 --- net_forc.v00 --- net_nx_n.v00 --- net_r816.v00 --- net_r816.v01 --- net_s2io.v00 --- net_sky2.v00 --- net_vmxn.v00 --- ohci_usb.v00 --- sata_ahc.v00 --- sata_ata.v00 --- sata_sat.v00 --- sata_sat.v01 --- sata_sat.v02 --- sata_sat.v03 --- sata_sat.v04 --- scsi_aac.v00 --- scsi_adp.v00 --- scsi_aic.v00 --- scsi_fni.v00 --- scsi_ips.v00 --- scsi_meg.v00 --- scsi_meg.v01 --- scsi_meg.v02 --- scsi_mpt.v01 --- scsi_mpt.v02 --- scsi_rst.v00 --- uhci_usb.v00 --- tools.t00 --- hpnmi.v00 --- scsi_qla.v01 --- xorg.v00 --- imgdb.tgz --- imgpayld.tgz
    build=
    updated=0

    Reply
  11. *protectedjvmware says

    03/03/2016 at 3:20 pm

    Hi,

    I am trying to mimic this script with your other one which prompts for user input. Now my biggest issue is getting the variables written to a file in pre and be able to use them in $firstinstall. I have tried the --unsupported route but esxi 6.0 keeps erroring that its an unknown argument for %pre and first boot. I basically copied the commands above to create the /var/log/esxi_install.log but it is not working any ideas would be great. Also these hosts are not connected to the network so any pxe solution will obviously not work.

    Reply
  12. *protectedSam says

    10/15/2019 at 4:17 am

    How does this work when using UEFI? when booting it will use boot.cfg which does not contain an append but kernelopt=

    Also say we have 100 esxi servers to deploy what is the best way to populate the addresses statically?

    I could have a textfile that sits on the https ks server with serial # and IP information. Using "esxcli hardware platform get" I can get the serial number and search it against the file - is this possible?

    Regards

    Reply
    • lamw says

      10/15/2019 at 6:08 am

      It works with both Legacy BIOS and UEFI. For the latter, you need to edit the boot.cfg that's located in EFI directory rather than the root directory.

      Yup, having a remote file that contains the mapping which gets parsed is probably the easiest method. You could even have a basic API endpoint that serves the mapping with a GET operation but does require you to create a basic HTTP API to provide that.

      Reply

Trackbacks

  1. How to prompt for user input during an interactive or scripted install of ESXi? | virtuallyGhetto says:
    10/28/2015 at 10:24 am

    […] something I have written about before using PXE boot options as a workaround to provide for a semi-interactive automated installation of ESXi. The most recent request for this was not actually from a customer but rather someone internally […]

    Reply

Thanks for the comment!Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VMware Flings is now available in Free Downloads of Broadcom Support Portal (BSP) 05/19/2025
  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025