Kickstarts are wonderful. Simple and effective. The ability to automate the mundane installations for *nix all about. In my case, I need to automate the installation of hosts that will be booting from SAN.
We have an admin that once installed a couple of ESX hosts atop other host’s boot LUNs. It’s pointless blaming the admin, as there’s a basic rule that must be followed at all times that will prevent this from happening.
NOTE: Don’t let the host see boot LUNs for any other host than itself.
This can be accomplished with:
- LUN Masking (on the host HBA)
- SAN Zoning (on your fabric)
- Port Grouping (on your storage)
Horror story aside, lets have a look at a basic kickstart for the ESX. When you install ESX by hand, it creates a
ks.cfg file in root’s home. Inside you will find the host configuration at the time of install.
ASSUMPTION: You have already provisioned the necessary space on your array for your host, and have mapped the host access to that LUN.
After a few modifications and some cleanup, I ended up with the following
auth --enablemd5 --enableshadow
#this will work on all 'fresh' LUNs. If you want to an
#existing vmfs store, then add --overwritevmfs
rootpw --iscrypted $1$MoIxblff$td1t5Oe4Kq8KZqyByh5Bc1
timezone --utc 'Australia/Sydney'
network --addvmportgroup=true --device=vmnic0 --bootproto=dhcp
part '/boot' --fstype=ext3 --size=1100 --onfirstdisk
part 'none' --fstype=vmkcore --size=110 --onfirstdisk
part 'HOSTNAME_boot' --fstype=vmfs3 --size=9232 --grow --onfirstdisk
virtualdisk 'esxconsole' --size=8232 --onvmfs='HOSTNAME_boot'
part 'swap' --fstype=swap --size=1228 --onvirtualdisk='esxconsole'
part '/var/log' --fstype=ext3 --size=2000 --onvirtualdisk='esxconsole'
part '/' --fstype=ext3 --size=5000 --grow --onvirtualdisk='esxconsole'
# ntp settings
esxcfg-firewall --enableService ntpClient
chkconfig ntpd on
cat > /etc/ntp.conf <
I set out to install onto the FIRST available drive. In my case, thats always LUN 0, and if by some accident there's already a VMFS on it - installation will cease (you can accomplish a force through by adding
--overwritevmf to the
Once the setup completes you will be greeted with a "Press
reboot --eject just before the
%post statement. Unfortunately this doesn't seem to work for ESX. I'll update the post once I find a way.
You may notice that I keep referring to HOSTNAME - that's because the
ks.cfg is part of another script which puts together a custom ISO for each of our blades.