The blueprint for this section seems to refer mainly to ESX but I’ve described both ESX and ESXi on the assumption the lab environment used for the exams will move to v4.1 sooner rather than later.
NOTE: Weasel is VMware’s scripted installer. It’s similar to Kickstart as used with Linux, but not identical.
A summary for a scripted install;
- Decide on the bootloader source
- Configure a media repository to hold your source files and scripts
- Create an install script (either from scratch or from a previously built host)
- Perform the scripted install
Use cases for scripted installations
Reasons to use a scripted install;
- Reduce deployment time
- Ensure consistency, reduce human error
- Remove need for local media (when using PXE boot. Very useful for blade and remote environments)
- Delegate installations to junior staff who don’t know how to configure ESX
Along with knowing why you might use a scripted install in the first place you should consider the various types of scripted install and when to use each one. Factors to consider;
- Maintainability. Over time you’ll want to update your install for new releases of ESX, patches, post install steps etc. While a custom CD has the least dependencies it’s harder to maintain compared to a network media repository.
- Dependencies. I created an NFS based install only to find that most of the time the host’s physical networking hasn’t been completed when we want to build the OS, rendering this method useless. I had to convert it to a custom CD instead which was mounted via ILO (it was a blade environment). Another example is USB flash – it’s easier than CD to amend/update but may not be as useful for remote installs.