cylindric.net

  • Increase font size
  • Default font size
  • Decrease font size

VMware vSphere - Scripted Installer for ESX Server

E-mail Print PDF
Article Index
VMware vSphere - Scripted Installer for ESX Server
The Pre Section
The Post Sections
The esx-post-script
The Actual Config
All Pages

vmwareThe 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

  1. Insert in the USB stick with the configuration we're going to create on it
  2. Insert the ESX bootable DVD and boot the server
  3. Select (but DO NOT press enter yet) the option "ESX Scripted Install using USB ks.cfg"
  4. Press [F2]
  5. At the end of the command-line, enter ESXID=X, where X is the ESXID of the server being built
  6. Press [Enter]

What happens now is all of this:

  1. The server boots into install mode
  2. The config's PRE section creates the network configuration file
  3. The config's PRE section creates the disk configuration file
  4. The config's PRE section creates a call-script.sh to save the ESXID for later use
  5. The installer reads the main config, the contents of the network and the contents of the disk config files
  6. The config's POST section copies the new call-script.sh to the new installation
  7. The config's POST section copies the esx-post-script.sh to the new installation
  8. The installer calls call-script.sh from the new installation
  9. call-script.sh calls esx-post-script.sh X, where X is the ESXID
  10. esx-post-script.sh creates a new customised script esxcfg.sh
  11. esx-post-script.sh backs up the current /etc/rc.init file
  12. esx-post-script.sh puts esxcfg.sh into rc.init
  13. The installer is finished, and so reboots the system
  14. rc.init now calls esxcfg.sh, which contains customised configuration
  15. rc.init then copies the original rc.init back over itself
  16. 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
  1. # Regional Settings
  2. keyboard uk
  3. timezone --utc 'Europe/London'
  4.  
  5. # Installation settings
  6. reboot
  7. install cdrom
  8. # Unencrypted root password (replace by your own)
  9. rootpw --iscrypted $1$6uSi8SxC$Gvr0QbKV.4DZhgmT07qCj/
  10. # Licensing
  11. accepteula
  12. serialnum --esx=50090-0H04Q-18C39-0F8K2-9JCN0
  13. # Authentication
  14. auth --enablemd5 --enableshadow
  15. # Partitioning
  16. %incude /tmp/diskconfig
  17. # Network
  18. %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.



Last Updated ( Wednesday, 05 August 2009 12:53 )  

Top Articles

Error
Can't initialise G2Bridge.