|Gabrie van Zanten|
The most efficient way to ensure that your ESX hosts have the same configuration – which is necessary for successful VMotion migrations and to prevent networking issues -- is to perform a fully automated install of your ESX hosts.
In the first article in this series, I provided an overview of the automated install procedure along with a ZIP file containing the necessary scripts to perform the install. Since it is a combination of scripts that are downloaded or created during install, it is good to have both the global and an in-depth view of how the individual pieces work together to automate the creation of an ESX host. The following diagram shows how.
Executing the kickstart script
The boot parameters line used in the Ultimate Deployment Appliance (UDA) works for each configuration with just a few adjustments. In this line, the last part is most important, which is "ESXIP=10 ESXCL=001". This passes two variables to the %pre section of the kickstart scripts. ESXIP is the number of the last octet of the IP address that will be assigned to the host. This number will also be used for the VMotion IP address, but in a different subnet. And finally, the number will be used as part of the DNS name of the host.
The ESXCL parameter is used to determine which cluster the host will be part of. Note that the script does not add the host to the cluster in vCenter Server, but based on this cluster parameter, the correct cluster VLANs will be configured for that host.
The kickstart procedure does most of the configuration and triggers the other scripts. This kickstart script has several sections in it: %Pre, %Post, and a main section that does not have a specific name. The problem with kickstart is that for each section a separate shell is started and variables cannot be passed through, which makes it difficult to use specific settings throughout the script. By using a special "%post –nochroot" section it is possible to pass variables from the main section to the %post section by writing them into a script file on the temporary file system in a subdirectory that will later become part of the permanent file system.
The %pre section analyzes the command line (boot parameter line) and reads the needed ESXIP and ESXCL variables. A temporary file is created using these variables (/tmp/networkconfig). In this file, we write the network configuration, which then can be read again in the next session.
Ahe very end of the automatic install, ascript configures all vmkernel settings, such as virtual vSwitches and virtual local area networks (VLANs).. A helper script called call-esx-postinstall-3.5.sh is written to disk to run this, which is only needed to start the /root/esx-postinstall-3.5.sh with the ESXIP and ESXCL variables. Still with me? In layman's terms, %pre writes the variables to disk in a new script file so it can later kick off the final configuration script using the variables.
The main section is pretty straight forward, and most comments in the script are self explanatory. An important part is setting the partition sizes. It all depends, of course, on what the size of your local storage is. But if you have 30 GB or more, you can just use the same values from my script. Be aware that a lot of administrators used to make a /var/log partition. I changed this to /var since processes that crash will create a dump file in /var/core, and some installations have a lot of dump info that caused the volume to run out of space. If you make a /var/log, then /var/core is not part of the volume, preventing the root volume from running out of space which would cause your service console to come to a halt. Instead we use /var.
A very short section, it is used only to copy the call-esx-postinstall-3.5.sh from a temporary file system to the final permanent file system. This permanent file system is mounted during installation as /mnt/sysimage. Writing the call-esx-postinstall-3.5.sh script to this file system makes it available later on.
After the script installs VMware ESX, the last part of the kickstart procedure (which is different from the complete auto-install), will download the esx-post-install-3.5.sh script from the UDA server. By using the call-esx-postinstall-3.5.sh script, we copied in the %ost –nochroot section, we can now start the esx-post-install-3.5.sh script.
Esx-post-install-3.5.sh and esx-kernelconfig.sh
The esx-post-install-3.5.sh script is long and configures most of the VMware ESX settings.This script is the real time saver when compared with manual installation. Most settings, however, can be configured only when the vmkernel loads. Therefore, we again perform the trick of writing a script to disc so it can be started in a later phase. With the command cat > /root/esx-kernelconfig.sh <<EOF1, a script file is created. Creation ends at the EOF1 marker close to the bottom of esx-post-install-3.5.sh.
To start the esx-kernelconfig.sh script, we reconfigure the /etc/rc.d/rc.local script. The original rc.local is copied to rc.local.bak, then rc.local is modified to run the /root/esx-kernelconfig.sh script and after reboot the rc.local.bak (the original) is copied over the modified rc.local to put it back in to the original state.
In the esx-kernelconfig.sh script, there are comment lines that explain what the script does in detail. Here is a short list, though, of the script's functions.
- Creates the service console vSwitch
- Configures VMotion
- Creates quarantine vSwitch (no network adapters attached)
- Creates VM vSwitch, depending on destination cluster
- Configures Active Directory authentication
- Creates a number of local users that have secure shell (SSH) access
- Configures DNS settings
- Configures time-sync settings
- Unloads VMFS2 driver from kernel
- Configures firewall to allow VEEAM FastSCP access
- Sets service console memory to 800 MB
After the esx-post-install-3.5.sh script has finished, the kickstart procedure is complete and the VMware ESX host will reboot. At the next reboot, the script esx-kernelconfig.sh will run. After this script finishes, VMware ESX host configuration is complete. A last reboot will now ensure that all settings are activated and your automatic install is complete. Your host is now ready to be added to vCenter and then assigned to a cluster.
Gabrie van Zanten (VCP) has been in the IT industry for 12 years. Currently he is a virtualization architect for a worldwide consultancy company and has designed and maintained virtual infrastructures for a number of customers. He has written articles for magazines and frequently publishes in-depth articles at his weblog, GabesVirtualWorld.