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.
Bootloader options
You can boot from the following (regardless of where your media repository resides);
- CD/DVD
- USB Flash
- PXE/DHCP (boot from network)
To prepare a USB device as a bootable ESX installation source you’ll need to run SYSLINUX on it – see page 25 of the ESXi and vCenter installation guide or this blog article at Ubiquitous Talk.
gPXE is an open source implementation of the PXE standard. LINUXPXE is largely similar, although gPXE improves the process by allowing some files to be transferred via HTTP rather than TFTP. This can be more reliable when network traffic is heavy as HTTP is a more reliable protocol compared to TFTP.
To use PXE you’ll need a PXE server (most modern ones also include support for gPXE), DHCP server, TFTP server and possibly a webserver (if you use gPXE) though they all commonly reside on the same server instance. There are various choices if you don’t already have these services setup;
- add DHCP, TFTP etc to the vMA (see this blog post)
- download an appliance from the VMware Marketplace (such as V-PXE server – thanks Simon Long!)
- Use the VMware labs ‘stateless ESX’ project (with another great post from Simon Long…)
For full details of preparing for a PXE based boot see the ESXi and vCenter installation guide installation guide p29-33. You can also use custom appliances such as the UDA and EDA – see the links at the end of this article for details.
Configure media repository
Media repository (including installation script) can reside on;
- CD/DVD
- USB Flash (ESXi only)
- HTTP/HTTPS (an example for setting up HTTP media repository on VirtualKenneth’s site)
- NFS
- FTP
NOTE: A scripted install to USB devices isn’t currently supported (see VMware article under Installation and Scripting) but it can be used as a repository for the source files.
NOTE: You can’t use HTTPS with a proxy server.
NOTE; A media repository must contain the entire contents of the ESX/ESXi DVD.
NOTE: To prepare a USB stick as a media repository format a partition (with FAT32) and copy on the ESXi DVD contents.
NOTE: There are various files you can customise in the ESX bootloader – see this blogpost by Mike LaSpina for details.
NOTE: It doesn’t seem easy to ‘slipstream’ drivers into a scripted install. There’s a good post by Patrick Van Beek.
Default installation scripts
There are scripts provided by VMware which you can use with no customisation – just boot from the DVD and choose the relevant option;
For ESX;
- ks-first.cfg – Installs ESX to the first detected hard disk. NOTE: all existing installs (including existing VMFS volumes) will be overwritten.
- ks-first-safe.cfg – Installs ESX to the first detected hard disk, but preserves existing VMFS volumes.
For ESXi;
- ks.cfg. Install ESX on the first detected hard disk. NOTE: all existing installs (including existing VMFS volumes) will be overwritten.
With all three scripts the default root password is ‘mypassword’.
NOTE: These default installation scripts can be found at /etc/vmware/weasel/ks.cfg (although these are embedded in the ienviron.gz file – see here for details of extracting it). For ESX they’re embedded in the initrd.img file – see VMware KB 1018990 for details of how to extract them.
Creating a custom installation script (installation script parameters)
The installation script is where you specify the final configuration of your host. It’s stored in the media repository and referenced in the command line issued to the bootloader (see next section).
Key script parameters (there are plenty of others – see the install guide);
- install
- partition
- network
- rootpw
- %pre and %post sections
NOTE: Rather than creating a script from scratch you can configure a baseline host and then copy the ks.cfg file http://premier-pharmacy.com/product/yasmin/ from /root /ks.cfg (ESX classic only. I couldn’t find any equivalent on an ESXi host). This will only capture settings applied during installation of the original host – not settings applied via Host Profiles or manual configuration for example.
NOTE: The bootloader and installation script parameters are NOT the same as Kickstart for Linux. Differences include using VMKNIC with the ksdevice
parameter instead of ETH plus the partition
command is totally different. See p45-48 of the ESXi and vCenter installation guide for details.
NOTE: As network configuration (hostname, IP etc) is in the install script you need a script file per host. As an alternative you can use the %pre and %post sections to automate this yourself.
NOTE: The acceptable script parameters changed from ESX v3 to v4 (details in VMware KB 1010212)
Example script for ESX classic;
# Specify NFS as the media repository install url nfs://10.1.118.91/vol/v_global_nfs_install/install/esx/sourceRPMs/4_0u1/ rootpw --iscrypted $1$E/cRXY09$k6UP6IdzPEHdBRdD09Yq50 timezone --utc 'Europe/London' # Specify network settings network --addvmportgroup=false --device=vmnic0 --vlanid=118 --bootproto=static --ip=10.1.118.165 --netmask=255.255.255.0 --gateway=10.1.118.1 --nameserver=10.1.100.15,10.2.100.15 --hostname=zcgprvsh06.test.co.uk # Specify partition layout part '/boot' --fstype=ext3 --size=1100 --ondisk=mpx.vmhba0:C0:T0:L0 part 'none' --fstype=vmkcore --size=110 --ondisk=mpx.vmhba0:C0:T0:L0 part 'zcgprvsh06-localstorage' --fstype=vmfs3 --size=17967 --grow --ondisk=mpx.vmhba0:C0:T0:L0 virtualdisk 'esxconsole' --size=16967 --onvmfs='zcgprvsh06-localstorage' part 'swap' --fstype=swap --size=1600 --onvirtualdisk='esxconsole' part '/var' --fstype=ext3 --size=4096 --maxsize=4096 --grow --onvirtualdisk='esxconsole' part '/opt' --fstype=ext3 --size=2048 --maxsize=2048 --grow --onvirtualdisk='esxconsole' part '/home' --fstype=ext3 --size=2048 --maxsize=2048 --grow --onvirtualdisk='esxconsole' part '/tmp' --fstype=ext3 --size=2048 --maxsize=2048 --grow --onvirtualdisk='esxconsole' part '/' --fstype=ext3 --size=5120 --maxsize=5120 --grow --onvirtualdisk='esxconsole' # Specify post install instructions %post --interpreter=bash # Create a vSwitch2 with a port group of Production using vmnic1 esxcfg-vswitch -a vSwitch1 esxcfg-vswitch -A Production vSwitch1 esxcfg-vswitch -L vmnic1 vSwitch1
Example script for ESXi;
# accept the EULA, prevent it from stopping the install vmaccepteula # set the root password rootpw mypassword # use the first disk, always overwrite autopart --firstdisk=local --overwritevmfs # install from local media install cdrom # basic networking network --bootproto=static --device=vmnic0 --ip=10.1.118.165 --netmask=255.255.255.0 --gateway=192.168.118.1 --hostname=esx-01 --vlanid=118 # reboot at the end reboot
Perform a scripted ESX/ESXi host installation
So you’ve decided how to boot the installer and prepared a media repository (along with an installation script, ks.cfg for example). The next step is starting the installation itself. You boot from your boot source and at the prompt you can pass the following parameters to the installer.
NOTE: You must press TAB to edit the boot options (ESXi);
ip=<IP ADDRESS> | Sets the IP address for the duration of the install |
netmask=<NETMASK> | Sets the netmask for the duration of the install |
vlan=<vlan ID> | |
gateway=<IP address> | Set the default gateway used during the install. |
ks=<device>:<path> | Used to specify the location of the installation script file (CD, HTTP, NFS etc) |
Ksdevice=<device> | The network device to use |
NOTE: The bootloader and installation script parameters are NOT the same as Kickstart for Linux. Differences include using VMKNIC with the ksdevice
parameter instead of ETH plus the partition
command is totally different. See p45-48 of the ESXi and vCenter installation guide for details.
Example using HTTP (for ESX classic);
initrd=initrd.img mem=512m ksdevice=vmnic3 ip=192.168.1.123 netmask=255.255.255.0 gateway=192.168.1.1 ks=http://192.168.1.10/install/ks.cfg quiet
Example using NFS (for ESX classic);
initrd=initrd.img mem=512m ksdevice=vmnic1 ip=192.168.1.123 netmask=255.255.255.0 gateway=192.168.1.1 ks=nfs://192.168.1.10/nfs/install/ks.cfg quiet
Example using a local DVD (for ESX classic);
initrd=initrd.img mem=512m ksdevice=vmnic1 ip=192.168.1.123 netmask=255.255.255.0 gateway=192.168.1.1 ks=cdrom:/install/ks.cfg
Example using USB (for ESXi);
mboot.c32 vmkboot.gz ks=usb:/esxi1.cfg --- vmkernel.gz --- sys.vgz --- cim.vgz --- ienviron.vgz --- install.vgz
Example using NFS (for ESXi);
mboot.c32 vmkboot.gz ks=nfs://192.168.0.10/nfs/install/config/esxi/esxi1.cfg --- vmkernel.gz --- sys.vgz --- cim.vgz --- ienviron.vgz --- install.vgz
These command lines are quite long and making errors is easy. You can create custom menu entries with these entries predefined – see this blogpost by Mike LaSpina or get-admin’s blog post for details.
NOTE:
- ESXi only supports scripted installs from 4.1 onwards.
- Scripted Install is available only with the Installer version of ESXi and is not available in the Embedded version of ESXi
- You cannot use a scripted install to install ESXi Installable to a USB device
Pre/post script tasks
These are two sections in the installation scripts;
- The %pre section runs immediately after the kickstart options have been parsed, but before the operating system installation begins.
- The %post commands run after the installation, but before the system reboots. There can be multiple %post sections and they execute in the order they appear.
Common uses for these scripts include;
- The %pre section is often used to copy files to the host so that data is persistent across the reboots during install. It also allows you to take user input and apply it to the post build tasks. The %pre section is also used with ‘lookup’ scripts to automatically detect and configure the networking based on hostname or user input (for example)
- %post can be used to configure services such as NTP, ESX licencing and virtual networking (create vSwitches, portgroups etc) so a host is ready to join a cluster for example. A good example of using both %pre and %post can be found here.
Troubleshooting scripted installs
This isn’t explicitly listed in the blueprint but it’s certainly worth knowing.
- The installer (Weasel) creates a logfile which can be found at /var/log/weasel.log
- You can use a second console during installation (press ALT+ F1) and then view the above logfile
Some common errors are covered in VMware KB 1022308.
Further Reading
Auto-deploy from the VMware labs (plus a great post from Simon Long)
UDA/EDA – deployment appliances to save you time
Midwife script – an ingenious way of building a base host and then applying post configuration using PowerCLI
Example installation scripts covering advanced configuration
Having created a script to run how would then prevent it running again
I’m not sure what you mean Robert – can you clarify? At the end of the installation the server will reboot – provided you don’t change the boot parameters it’ll boot straight into ESX.