Kickstart your host into configuration conformity

The last few posts I’ve been mentioning how much of the configuration for my ESX hosts is automated. This post I’m going to talk a little more about how that automation is done, and provide an example kickstart script. I have been holding off on this post for a while now, as I have been planning on rebuilding my PXE server, at which point I will document each step and be able to provide a much more detailed post. However, things keep getting in the way and I haven’t had time to rebuild the server yet, so this is a slightly less detailed post, but should still be enough to get you on your way 🙂 And I have no doubt that you, dear reader, are not afraid of asking questions in the comments…

This automation is currently handled (I say “currently” because I’m working to move the majority of it to a remote host and use the SDK) by kickstart when the system is loaded. Well, to be totally honest, kickstart only plays a partial role in the process…during the %post section of kickstart I copy a series of scripts from an NFS mount point into the startup process (/etc/init.d/rc3.d), which are executed at first boot and, like good one-time-only scripts, remove themselves.

This setup allows me to pxe boot a host, give it the boot command which has the host ID appended, and that’s it. I can then walk away and wait for the host to add itself to vCenter, indicating that it’s finished. Kickstart and the post install scripts then configure the hostname, ip, virtual network configuration, security policy, ntp, base user set, install any custom RPMs, etc. This makes it extremely easy for me to keep all of our hosts at the same configuration level.

In order to keep all the hosts the same I simply have to update the relevant post install script when we decide to make a global change and it will configure the host correctly the next time it is loaded/reloaded. For updating hosts that can’t be reloaded (I try to reload the hosts periodically with the newest binaries from VMware…every 4-6 months…so that the software is not a huge conglomeration of patches…I know, it’s unnecessary, but it gives me peace of mind) we use a combination of Glenn’s POSH prowess and the perl toolkit scripts I’ve created to remediate hosts en masse to our baseline configuration.

I’m not going to go into PXE configuration. There are many resources out there, use google. Maybe, maybe, in the future I’ll post a quick setup guide for CentOS, but not today. I will however discuss the kickstart file for my hosts. When you PXE boot a host you end up at a prompt asking which of the configured boots you want to use for your host. At this point you select the one you want by typing in the name and press enter. You also have the option of appending configuration information to the boot line. Common parameters include the IP address to use, the video settings and other such items. You can also add pretty much anything you want and it will be ignored by the kernel, but still available during the kickstart process.

On my PXE menu, “ESX35” is the boot item that will start the network install process for ESX3.5, however I also add a boot parameter: “ESXID=xx”. In the kickstart file I capture this variable and use it to configure the hostname (“ESXxx”) and ip address (“1.1.1.xx”).

A sample Kickstart line

The portion in the PXE config file (/tftpboot/pxelinux.cfg/default):

So, what I type in at the boot prompt is ESX35 ESXID=57. This ESXID variable and it’s value is captured in the %pre section of the kickstart process and written to two files…one for the network config in the main portion of the kickstart and a second that is copied to the newly loaded server’s file system and used in the post install config process.

The %pre section

After the %pre section, kickstart moves into it’s main process. Everything here is normal execpt for one part…the network line is loaded from the file that was created above.

The Main Kickstart Script

Notice the %include directive for the file that was created in the %pre section. This sets our hostname and COS IP according to what was specified at the boot prompt.

After kickstart loads the new system it will execute two portions of the script: %post –nochroot and %post. The former has access to the RAM disk file system that was used during the kickstart process and the newly loaded server’s file system. The latter only has access to the server’s file system. So, since we still need our network config information after the host reboots to do post install configuration, we need to copy our network config script created in %pre to the host file system…

%post –nochroot

And now we can continue with the normal %post section of the kickstart. Some people configure their host network in the %post section, I configure it after the host reboots by mounting an NFS volume and copying the config scripts over. The choice is yours, as they say. For simplicity’s sake, and brevity (which is kind of shot at this point…), I’m not really going to include anything in the example here…


That’s pretty much it. Not too difficult, but the kickstart process is a bit of a mystery to most people.

If you have any questions, please leave them in the comments. Please remember that it is the holidays, so I might be a little slow to respond as I travel around the east coast for the next couple of days.

2 thoughts on “Kickstart your host into configuration conformity”

  1. Hello, how do you have your ESX hosts add themselves to vCenter? I’m very interested in that as the last step of our provisioning process.


  2. hello…
    What a good idea tu use pre and post –nochroot.
    For vsphere , i need to download a very long script to terminate my auto-configuration (like i do for ESX 3.5) and with vsphere no “mount -t nfs” or “wget” work. Now i do wget in %pre, copy in %post –nochroot and create my autoconfig service in %post.


Leave a Reply