Looking back at Listing 2.1, you’ll see that the default installation script incorporates a %post section, where additional scripting can be added using either the Python interpreter or the BusyBox interpreter. What you don’t see in Listing 2.1 is the %firstboot section, which also allows you to add Python or BusyBox commands for customizing the ESXi installation. This section comes after the installation script commands but before the %post section. Any command supported in the ESXi shell can be executed in the %firstboot section, so commands such as vim-cmd, esxcfg-vswitch, esxcfg-vmknic, and others can be combined in the %firstboot section of the installation script.
A number of commands that were supported in previous versions of vSphere (by ESX or ESXi) are no longer supported in installation scripts for ESXi 6, such as these:
• autopart (replaced by install, upgrade, or installorupgrade)
• auth or authconfig
• bootloader
• esxlocation
• firewall
• firewallport
• serialnum or vmserialnum
• timezone
• virtualdisk
• zerombr
• The – level option of %firstboot
Once you have created the installation script you will use, you need to specify that script as part of the installation routine.
Specifying the location of the installation script as a boot option is not only how you would tell the installer to use the default script but also how you tell the installer to use a custom installation script that you’ve created. This installation script can be located on a USB flash drive or in a network location accessible via NFS, HTTP, HTTPS, or FTP. Table 2.1 summarizes some of the supported boot options for use with an unattended installation of ESXi.
Table 2.1: Boot options for an unattended ESXi installation
Not a comprehensive list of boot options
The list found in Table 2.1 includes only some of the more commonly used boot options for performing a scripted installation of ESXi. For the complete list of supported boot options, refer to the vSphere Installation and Setup Guide, available from www.vmware.com/support/pubs/.
To use one or more of these boot options during the installation, you’ll need to specify them at the boot screen for the ESXi installer. The bottom of the installer boot screen states that you can press Shift+O to edit the boot options.
The following code line is an example that could be used to retrieve the installation script from an HTTP URL; this would be entered at the prompt at the bottom of the installer boot screen:
<ENTER: Apply options and boot> <ESC: Cancel>
> runweasel ks=http://192.168.1.1/scripts/ks.cfg ip=192.168.1.200
netmask=255.255.255.0 gateway=192.168.1.254
Using an installation script to install ESXi not only speeds up the installation process but also helps to ensure the consistent configuration of all your ESXi hosts.
The final method for deploying ESXi – using vSphere Auto Deploy – is the most complex, but it also offers administrators a great deal of flexibility.
Deploying VMware ESXi with vSphere Auto Deploy vSphere Auto Deploy is a network deployment service that enables ESXi hosts to be built off an image template over a network connection. No mounting of installation media is required to get an ESXi host up and running if it is installed using Auto Deploy. You need to address a number of prerequisites before using Auto Deploy. They are listed here, but before I get too far into this section I wanted to mention the requirement for a vCenter Server. Auto Deploy requires an installed vCenter Server to operate but we won’t start discussing this until Chapter 3, “Installing and Configuring vCenter Server.” Feel free to skip this section and come back once your vCenter Server is up and running; otherwise, follow along to see how this service is configured.
vSphere Auto Deploy can be configured with one of three different modes:
• Stateless
• Stateless Caching
• Stateful Install
In the Stateless mode, you deploy ESXi using Auto Deploy, but you aren’t actually “installing” ESXi. Instead of actually installing ESXi onto a local disk or a SAN boot LUN, you are building an environment where ESXi is directly loaded into memory on a host as it boots.
In the next mode, Stateless Caching, you deploy ESXi using Auto Deploy just as with Stateless, but the image is cached on the server’s local disk or SAN boot LUN. In the event that the Auto Deploy infrastructure is not available, the host boots from a local cache of the image. In this mode, ESXi is still running in memory but it’s loaded from the local disk instead of from the Auto Deploy server on the network.
The third mode, Stateful Install, is similar to Stateless Caching except the server’s boot order is reversed: local disk first and network second. Unless the server is specifically told to network boot again, the Auto Deploy service is no longer needed. This mode is effectively just a mechanism for network installation.
Auto Deploy uses a set of rules (called deployment rules) to control which hosts are assigned a particular ESXi image (called an image profile). Deploying a new ESXi image is as simple as modifying the deployment rule to point that physical host to a new image profile and then rebooting with the PXE/network boot option. When the host boots up, it will receive a new image profile.
Sounds easy, right? Maybe not. In theory, it is – but there are several steps you have to accomplish before you’re ready to deploy ESXi in this fashion:
1. You must set up a vCenter Server that contains the vSphere Auto Deploy service. This is the service that stores the image profiles.
2. You must set up and configure a Trivial File Transfer Protocol (TFTP) server on your network.
3. A DHCP server is required on your network to pass the correct TFTP information to hosts booting up.
4. You must create an image profile using PowerCLI.
5. Using PowerCLI, you must also create a deployment rule that assigns the image profile to a particular subset of hosts.
Auto deploy dependencies
This chapter deals with ESXi host installation methods; however, vSphere Auto Deploy is dependent on host profiles, a feature of VMware vCenter. More information about installing vCenter and configuring host profiles can be found in Chapter 3.
Once you’ve completed these five steps, you’re ready to start provisioning hosts with ESXi. When everything is configured and in place, the process looks something like this:
1. When the physical server boots, the server starts a PXE boot sequence. The DHCP server assigns an IP address to the host and provides the IP address of the TFTP server as well as a boot filename to download.
2. The host contacts the TFTP server and downloads the specified filename, which contains the gPXE boot file and a gPXE configuration file.
3. gPXE executes; this causes the host to make an HTTP boot request to the Auto Deploy server. This request includes information about the host, the host hardware, and host network information. This information is written to the server console when gPXE is executing, as you can see in Figure 2.7.
4. Based on the information passed to it from gPXE (the host information shown in Figure 2.7), the Auto Deploy server matches the server against a deployment rule and assigns the correct image profile. The Auto Deploy