| Article Index |
|---|
| VMware vSphere - Scripted Installer for ESX Server |
| The Pre Section |
| The Post Sections |
| The esx-post-script |
| The Actual Config |
| All Pages |
The ESX 4.0 Server is VMware's customised operating system (a linux-based distribution) that is installed onto a server to provide an interface between the virtual machines and the physical hardware. It also consists of a small VM called the Service Console that is used to both control the VM's running on that host, but also to talk to wider vSphere cluster.
The install for ESX couldn't be much simpler. You have to make some choices regarding the sizes of the various disk partitions, much like any other Linux install, set some networking options, and off you go.
The problem comes a bit later in the game, because to make some of the magic work, all the hosts have to have exactly the same settings for their networking, virtual switches and storage controllers, and they all need to have hosts files pointing at each other and the Virtual Center managing it all. Remembering to do all that when it's 9pm on a Friday evening and you need to build a new host on the quick is not all that reliable.
Read on to see how this can be overcome...
Automatic Installation - Single Host
When you've installed an ESX server with the graphical installer, it leaves a small config file in root's home directory called ks.cfg. This is a record of all the choices made during setup. The easiest (but least-powerful) way to get a "recovery" plan in place is to just pop that file on a USB memory stick, and then the next time you need to re-create the ESX host, just pop that in and select the "USB ks.cfg" option when the DVD boots up.
The problems with that are two-fold:
- It has the server name, IP address and other device-specific settings hard-wired into it
- Doesn't cover any of the configuration past the creation of the disks and the installation of the system
To overcome some of these issues, we need to delve deeper into the ks.cfg, and what it really is...
Automatic Installation - Many Hosts
The problem with multiple-hosts (and really, who has just one ESX host?) is that we need different IP addresses and names for all sorts of things in the configuration. This is where a more complex ks.cfg can help.
In this example, I'll describe the case for four hosts, which will be numbered 1 to 4.
| ESXID | Host name | IP address |
| 1 | ESX-01 | 10.20.30.1 |
| 2 | ESX-02 | 10.20.30.2 |
| 3 | ESX-03 | 10.20.30.3 |
| 4 | ESX-04 | 10.20.30.4 |
There's no easy way to do this, so what happens is kind of like this
- Insert in the USB stick with the configuration we're going to create on it
- Insert the ESX bootable DVD and boot the server
- Select (but DO NOT press enter yet) the option "ESX Scripted Install using USB ks.cfg"
- Press [F2]
- At the end of the command-line, enter ESXID=X, where X is the ESXID of the server being built
- Press [Enter]
What happens now is all of this:
- The server boots into install mode
- The config's PRE section creates the network configuration file
- The config's PRE section creates the disk configuration file
- The config's PRE section creates a call-script.sh to save the ESXID for later use
- The installer reads the main config, the contents of the network and the contents of the disk config files
- The config's POST section copies the new call-script.sh to the new installation
- The config's POST section copies the esx-post-script.sh to the new installation
- The installer calls call-script.sh from the new installation
- call-script.sh calls esx-post-script.sh X, where X is the ESXID
- esx-post-script.sh creates a new customised script esxcfg.sh
- esx-post-script.sh backs up the current /etc/rc.init file
- esx-post-script.sh puts esxcfg.sh into rc.init
- The installer is finished, and so reboots the system
- rc.init now calls esxcfg.sh, which contains customised configuration
- rc.init then copies the original rc.init back over itself
- Done
ks.cfg - The Kickstart File
The ks.cfg file is not actually a simple configuration file as one might expect. The installation process is actually a scripted interface with quite a lot of power, but not quite enough to easily utilised!
The basic part of ks.cfg is the simple and generally-consistent stuff like time-zones, keyboard layouts, eula's, etc
ks.cfg Basic Information
# Regional Settings keyboard uk timezone --utc 'Europe/London' # Installation settings reboot install cdrom # Unencrypted root password (replace by your own) rootpw --iscrypted $1$6uSi8SxC$Gvr0QbKV.4DZhgmT07qCj/ # Licensing accepteula serialnum --esx=50090-0H04Q-18C39-0F8K2-9JCN0 # Authentication auth --enablemd5 --enableshadow # Partitioning %incude /tmp/diskconfig # Network %include /tmp/networkconfig
The clever part starts in the last two items there. You can't have dynamic stuff in the normal configuration section, but you can include other configuration files. So what's happening here is that we're telling the installer to include two files, diskconfig and networkconfig, which will just contain more options.
What's the point of that, you ask? Well, whilst we can't be dynamic in the main config files, there are additional magical sections to this file that can be dynamic. It's in these sections that we'll generate those configs dynamically.





