UDA 1.

4 Quick Start –

Deploying ESX 3.x.x with F12 on the

keyboard

Document Version 1.2

By Mike Laverick

© ultimatedeployment.org
and RTFM Education

For Errors/Corrections in this document

please contact:
mikelaverick@rtfm-ed.co.uk

This guide does change. Have you got the latest copy?

Note:
Parts of this guide will be reproduced in the forthcoming book by Scott Herold,
Mike Laverick and Ron Oglesby. This section will be included in the Chapter
entitled “ESX on the Command-Line”. In addition to discussing scripted
installations it also covers esxcfg commands and the post scripting in kickstart
files. So essentially this is a “getting started” document for the UDA. Don’t worry
it will be properly proof-read for spelling errors, typos and missing words before it
gets anywhere near the published book. ☺

http://www.vi3book.com

Change Log: from document version 1.1 to 1.2

• Removed a false reference that stated it wasn’t possible to set VMotion via
the command-line. I’ve since discovered a method
• Added page numbering

Page 1
• Added a way of disabling the DHCP service on the UDA, and enabling it on
a Windows DHCP server instead

Page 2
Scripted Installation of ESX
There are many reasons to automate the installation of ESX. Firstly, if you’re
installing to blades using CDs can be a challenge. Secondly, automated installs
guarantee consistency; this is especially useful if you have datacenter policies for
partitioning and for ensuring consistently named port groups which are required
for VMotion, DRS and HA. Lastly, automating the ESX install will allow you to
quickly rebuild a system if you are in a DR scenario.

There are many ways of automating the installation of ESX. ESX uses the
“Anaconda” installer popular with many Linux distributions – and it can be
automated with a configuration file containing “kickstart” (KS) commands. The
automated install can use the source code via the physical CD-ROM, Floppy boot
disk or remotely by FTP, NFS, or Pre-Execution Environment (PXE). I’ve decided
to put the emphasis on PXE booting because in my experience people doing
automated deployments often desire “diskless” installation where neither CD or
floppy media is required – and wish to build an environment where the operator
merely has to select from a menu the build they wish to deploy.

Another way of approaching this is to use your hardware vendor’s ESX

deployment tools such as IBM RDM or HP RDP. For those people with HP
hardware an excellent site which covers the usage of HP RDP for ESX 2.x and 3.x
is:

http://www.brianshouse.net/hp/

We will use a popular PXE virtual appliance downloadable from the internet. This
will save you considerable time configuring in a Linux environment all the
appropriate services and files required to set up a PXE boot server. I initially
began to use the Ultimate Deployment Appliance v1.3 (UDA) as PXE server for a
number of reasons. Firstly, it is very small to download. Secondly, it offers a
way of serving up the files from the ESX ISO without manually copying the ESX
server source files. Thirdly, it has an easy to use GUI which allows you to
reconfigure the appliance with little Linux knowledge. Lastly, although the
appliance is not geared up to work with ESX 3, with a few modifications it can be
re-engineered to do so – and it can also be used to deploy a whole range of other
operating systems including Windows, Linux (Fedora, Ubuntu, Suse) and Solaris
X86. UDA was built to run on “free” virtualization with either VMware Server or
VMware Workstation and a Windows server is needed to host the ISO files.

At first I used ESX’s own web-based wizard to generate a “base” kickstart.cfg file
which we can modify with additional parameters to customize your installation.

After working with UDA 1.3 for sometime I contacted its creator - Carl Thijssen
who is based in the Netherlands. After some discussions I was able to persuade
Carl to extend the UDA to include ESX specific options. UDA 1.4 has now been
released. Carl is in the process of creating a permanent home for VMware
Workstation version of the UDA on the internet at

http://www.ultimatedeployment.org

The VMware Workstation version contains all files required to get up and running
including the .vmx, nvram, and vmdk files.

Additionally, a VMware ESX version is hosted on RTFM Education. There RTFM

Education version contains sample scripts which outline the post-configuration

Page 3
scripting that can be done using ESX esxcfg- commands. The VMware ESX
version is virtual disk only in the 2gbsparse formatted and can be “imported” into
a VMFS volume using the vmkfstools command. The welcome page is:

http://www.rtfm-ed.co.uk/

This new version of the UDA includes features such as:

• A kickstart creator for ESX 3 which supports options to:

o Install or Upgrade ESX

o The ability to set which NIC is used for the ESX host installation
o To hard-code kickstart scripts to ESX hosts by their MAC Address
o Selective loading of network and storage drivers
o Password protect the GRUB configuration
o Set a full IP configuration including primary, secondary and tertiary
DNS values

• Local mounted ISOs which dispenses with the need for a File Server
• Support for Linux NFS as well as a Windows Sharing
• Custom “help text” to the user of the UDA

The RTFM “ESX Version” of the UDA contains sample kickstart scripts created by
me which demonstrates using the %post section of the kickstart system to handle
such things as:

• Creating virtual switches

• NAS and iSCSI connections
• Set additional DNS name servers
• Add local users
• Lower SSH security to allow root logons
• Enable the SSH client from an ESX host

Configuring the Ultimate Deployment Appliance

(UDA)
UDA contains all the services and daemons required to do a PXE installation. It
has a static IP address (10.0.0.104) and contains a DHCP scope (in the range of
10.x.x.x) for issuing DHCP request to PXE clients. Using its graphical web-
interface it allows you to mount ISO images held with a virtual disk or
Windows/NFS shares and create a menu of pre-defined scripted installations
using an ESX 3.x.x template.

Its configuration for our purpose involves four main stages

• Download, Power On and Reset Passwords

• Reconfigure IP and DHCP Scope
• Setup Mount Point and Select ISO to Mount
• Create a ESX Template

Download, Power-On, and Reset Passwords

1. Download the Appliance

Note:
If you are using the ESX version carry out the following steps, if not skip

Page 4
 to step 5

2. Upload the tar file to your ESX host and extract the .vmdk files to a
temporary location with

tar –xzvf uda14-esx.tar /vmimages

3. Create a new Linux VM called uda14-esx using a lsilogic controller

creating a very small hard drive

Important:
You can use any Redhat Linux option (apart from 64-bit) and other Linux.
Ensure you set the SCSI controller to be lsilogic

Note:
We use the wizard create the directory structure for the UDA VM, and then
replace it with the 2gbsparse version

4. Next at the Service Console delete the virtual disk created at step 3 with

rm /vmfs/volumes/virtualmachines/uda14-esx/uda*.vmdk -f

5. Next import the UDA virtual disk that you extracted to a temporary
location at step 2 with:

vmkfstools –i /vmimages/uda14-esx.vmdk

/vmfs/volumes/virtualmachines/uda14-esx/uda14-esx.vmdk

Note:
If you wish to hold your ISO images on a second disk within the UDA you
might wish to add this at this point. The maximum size supported by the
UDA GUI is 50GB. However, larger sizes are possible if you are prepared
to partition, format and mount the disk manually at the UDA command-
line

6. Power on the UDA VM

7. Login to the Appliance with root with a password of test
8. Change the password of root with the passwd command

9. Open a web-browser on http:/10.0.0.1

Note:
You will need to give yourself a temporary 10.x.y.z address to
communicate to the UDA, if you don’t use this range on your existing
network. Alternatively, if you are comfortable with the command-line you
could use nano or vi to edit /etc/sysconfig/network-scripts/ifcfg-eth0 and
other files to adjust the network settings.

10. Click the Web-Interface link and login as admin with the password of
admin
11. Click the System link, and choose Change Password for web admin
user

Note:
You will find you have to re-login with the new password

Page 5
Reconfigure IP and DHCP Scope
Note:
If you are comfortable with the Fedora Core 5 environment you could always
reset your network settings from the command-line. The following instructions
cover making these changes from the graphical environment of the UDA

IMPORTANT:
The UDA’s IP address and DHCP scope should be set to be in the same network
ID as your ESX Service Console networking. If intend to use a Windows or Linux
File server to host the ISO files it easiest if that is on the same network too.
Personally, I prefer to have my ISO hosted within the UDA.

Windows DHCP:
If you would prefer or are forced to use Windows DHCP on your network. You can
configure Windows DHCP to work with UDA. For more information consult the
appendices at the end of this guide.

1. In the UDA , in the top right-hand corner click the System link
2. Select the Network Settings link
3. Change your IP address, subnet mask, and add a default gateway as
appropriate.

Note:
After clicking OK you will be disconnected, and you will have to connect
under the new IP address

4. Click the Service link

5. Choose the DHCP link and click the Configure button

Note:
replace the IP data with information valid for your network. Below is a
sample of my DHCP file with edits I made in bold

ddns-update-style ad-hoc;
next-server 192.168.3.150 ;
if substring ( option vendor-class-identifier, 0, 9) = "PXEClient"
{
filename "pxelinux.0" ;
next-server 192.168.3.150 ;
}
subnet 192.168.3.0 netmask 255.255.255.0 {
option routers 192.168.3.254;
option domain-name-servers 192.168.3.130 ;
range 192.168.3.20 192.168.3.30 ;
max-lease-time 300;
}

Note:
Next-server is the IP address of the UDA appliance, not a Windows or NFS
file server. The DHCP scope is leased to a PXE boot client during the boot
process – and does not set ESX itself to be a DHCP client. The ESX IP
settings for Service Console networking are provided in a kickstart file

6. Click the Apply button, UDA should stop and restart its DHCP service

GOTCHA:

Page 6
 When you set the UDAs IP address this also sets a global default in all
your subsequent defaults. Both the PXE menus and the kickstart.cfg files
will all have http:// references to the UDAs IP address. Changing the IP
address is a pretty critical reconfiguration – as you would have to update
all your kickstart files accordingly. Additionally, radical changes from one
type of IP address class to another (say from 192.168.3.0 to 172.168.0.0)
would require you to update your DHCP service settings as well as all your
kickstart files.

Setup Mount Point and Select ISO to Mount

As mentioned before there are 3 ways to provide the ISO of ESX during the
install. It can be on the virtual disk of the UDA, on a Windows File Server or a
Linux NFS File Server.

With Virtual Disk

UDA is available in two formats – a VMware Workstation format, and VMware ESX
format. If you have download the Workstation version then included in the UDA is
a second blank disk – which is un-partitioned and unformatted until you engage
it. This workstation disk is in 50GB growable format (type 1 format) but can be
partitioned to any size you like up to 50GB. It is possible to copy an ISO to the
first disk of the UDA, as there is about 500MB free. But you might find it more
useful to locate your ISOs in this second disk – and kept them separate from your
UDAs operating system disk.

If you have downloaded the VMware ESX Format it only includes the UDAs boot
disk. You will have to add a second virtual disk and specify its capacity as per
your requirements.

If you are familiar with Linux you need not use Carl’s web-interface to format and
mount the second disk. You could use fdisk to partition the disk, mkfs or tunefs to
format the disk and edit /etc/fstab to manually mount to the folder of
/var/public/smbmount/DISK2

1. Click the System link

2. Select the Diskspace link
3. Type in the size you wish the disk to be

Note:
Specify an amount appropriate for your needs. In the Workstation version
the disk is in a “growable” format, and its maximum size is 50GB. The
default size is 20GB which might be much more space than you actually
require.

4. Click the Initialize Second Disk button

Note:
Once the initialization has completed the second disk should be mounted.
To confirm this click the Mount Points link you should see that both DISK1
and DISK2 status is “mounted”

5. Lastly, using a secure Copy client such as WinSCP, Veeram FastSCP, or

SCP command within Linux connect to the UDA and copy your ISO(s)
to /var/public/smbmount/DISK2

Page 7
Windows Shared Folder
The Windows file server should be in the same IP range as the UDA and ESX
hosts.

1. On a Windows File server setup a Windows share which contains the

your ISOs

Note:
You could also add additional ISOs supported by UDA if you so wish

2. Click the Permissions button in the Sharing Tab

3. Remove Everyone/Read, and Set the Permissions to be Full Control for
an individual user account

Note:
This account must be “local” to the Windows File Server. In other words it
cannot be an Active Directory or NT4 Domain User account

4. Click the Mount Points link at the top of the page,

5. Choose Create New Mount – fill in the form to access the share. Figure
12.1 shows my settings

Figure 12.1

Note:
Clicking Mount Point again will show you the shares you have currently
mounted.

Linux NFS Share/Exports

The Linux NFS file server should be in the same IP range as the UDA and ESX
hosts. When configuring Linux as an NFS, the export directory that holds the ISO
files, should be assigned full access (read/write). Additionally, ensure the UDAhas
read/write access to the NFS share. Do not squash root access (no_root_squash).
In the sample before the UDA which I configured with a 192.168.3.150 is given
sole and exclusive access to the ISO files

/udashare

192.168.3.150

(rw,nohide,insecure,no_root_squash,no_subtree_check,async)

Page 8
NFS mount points are connected to in a similar way as SMB shares. However, you
do not need to supply a username, password or domain name as access is
controlled by the IP settings configured in the Linux NFS /etc/export file.

Configuring your Deployment OS

1. Next in the web-admin tool, click the OS link
2. Click the Configure link for VMware ESX 3.0.x, and in the following page
select an ISO from your mounted share/disk. Figure 12.2 shows my
list

Figure 12.2

3. After clicking OK, you should find that in the OS page it now reads in
green “Mounted”

Note:
Although Carl has used the name ESX 301 in most of the files. You can use
this OS template to install and upgrade ESX 3.0.0 and ESX 3.0.1. We do
not expect any problems in installing or upgrading future version of ESX 3.

Create a New Kickstart Template

1. Next click the Template link
2. Click Create New Template
3. Type in a friendly templateID name

Note:
This must be exactly 5 characters in length, so something like ESX01 or
RTFM1 will work. When the new ESX host boots you will be presented with
a menu. The operator selects the build by typing the 5 character template
ID name

4. Select the OS Type, in my case this esx301 (VMware ESX Server

3.0.x)
5. Type in a description

Note:
I would recommend typing the hardware vendor such as HP, IBM or DELL
together with the FQDN. This will assist the operator in selecting the
correct installation option.

Other options include “Bind to MAC Address” this can be used to restrict
the kickstart script a particular host. This can be useful in stopping
operators for applying the wrong kickstart script to the wrong server. The
“Hardware Manufacturer” option supports four options – generic, DELL, HP
and IBM. This option is specifically relevant to the HP users as it builds a

Page 9
 custom partition table appropriate for a HP server with a Smart Raid Array
Controller. Lastly, the custom option allows you to customize the kickstart
script using the UDA wizard appropriate to you environment. On the other
hand typical simply saves the kickstart file and allows you to hand-edit the
kickstart file in a simple text window.

6. Click OK

Using the UDA Kickstart Configurator

Figure 12.3 shows the first page of the UDA Kickstart Configurator. It’s a simple
wizard that configures all the main options associated with the ESX installation –
and includes some options which are not available in VMware’s own kickstart
creator. The UDA offer installation options which are more advanced than VMware
own script generator. However, if you prefer to use VMware’s tool it is outlined
later in this chapter.

Figure 12.3

Hopefully by now you should be familiar enough with the ESX installation to follow
each part of the wizard.

General
• Allows you set if the ESX host reboots after installation
• Indicate if the script installs or upgrade the ESX host
• Set the root password and encrypt it

Regional
• Allows the configuration of language and keyboard
• Time zone and UTC Settings

Authentication
• Allows the configuration of different directory services
• Default uses ordinary users and groups on the Service Console

Media
• By default UDA provides the kickstart file and ISOs via webservice
• It is possible to create an kickstart file for use in conjunction with for
example a CD
• UDA how ever is designed to allow PXE booting installation without the
need of physical CD
• The default settings here should be fine

Bootloader

Page 10
 • UDA assumes you will store you MBR on either /dev/sda or /cciss/c0do
• If you are installing to a SAN LUN you will need to adjust the default
values specified here
• UDA optionally allows you to password protect the GRUB bootloader
• Again the default should be fine for local installations

Partitioning
• The default partitioning scheme is based on recommendations in this book
• The option to delete partitions allows you to remove partitions and as you
might expect the “Add Partition” button allows you modify the default
partition table
• Most of the partitions are of a fixed size, but the UDA Kickstart
Configurator does allow for partition that “grow” to take up the remainder
of disk space

Networking
• From here you can set the IP address settings for the Service Console
• Although the boot protocol allows for DHCP and BootP I would recommend
using the default option of “static”

Licensing
• The licensing option assumes you are using license server and you are
using the full version of ESX
• UDA does support setting the values of the starter edition (Esxpress) and
use a host-based LIC file

Post-Installation (Optional)
• Currently this area is blank
• Later in this chapter I will be covering esxcfg commands that allow you to
configure your networking and storage
• Once you are familiar with these commands – we will revisit configuring
post configuration settings

Hardware Options (Optional)

• This interface allows you to stop the automatic loading of device drivers by
the Anaconda installer
• This allows for the selective loading of network and storage device drivers
• One usage of this is deliberately loading only local storage drivers, and
allows us to guarantee that the SAN is not accessible during the
installation. This offers an alternative to disconnecting SAN cables or
Zoning/Masking LUNs as the storage controller

Triggering a UDA Installation

When you power on a server different BIOS will prompt you at the appropriate
time to press the PXE keystroke to trigger a PXE boot. All hardware systems use
[F12]. However, Dell systems prompt for this at first power on, as the BIOS is
loading. HP systems on the other hand prompt after all cards with a BIOS has
been loaded. Figure 12.4 shows a sample UDA menu screen which is displayed
once the server has been leased a DHCP address

Figure 12.4

Page 11
To trigger the install type in the short five character templateID value, in the case
of Figure 12.4 this would be esx01. F1 can be used to request help information.
Currently, this states “No help yet, you're on your own, Edited! Edited2”. You can
modify this default help message in the UDA in the web-based administration tool
under the Services, TFTP, and Help Text button.

If you have a blank disk or LUN with no existing partition table – the installer will
ask if it is OK to initialize the LUNs it sees. This can also happen if your SAN is
attached. This can be very dangerous if /dev/sda is not a local LUN but a SAN
based LUN that contains data. Figure 12.5 shows the warning box

Figure 2.5

Additional Notes:
If you wish to edit by hand the various files used by UDA with nano or vi you will
find them located here:

Your Template files: /var/public/www/kickstart/

UDA Built-in Templates: /var/public/www/templates
UDA PXE Menu: /var/public/tftproot/message.txt
Default Help Message: /var/public/tftproot/help.txt
pxelinux.cfg File /var/public/tftproot/pxelinux.cfg/pxelinux.cfg

Page 12
Appendix 1: Enabling VMware ESX Scripted Installer
If you would rather not use UDAs kickstart builder you could use a VMware’s own
scripted installation builder. As mentioned earlier ESX has its own wizard for
creating the kickstart.cfg file. It is a web-based tool, but it is not enabled by
default on the ESX host. You must first edit a configuration file (struts-
config.xml) on the ESX server to enable it. If you don’t make this change, when
you try to access the web-page the message appears

“Scripted Install is disabled

Message: Your ESX Server is not configured to support scripted installations. To
support scripted installations, please refer to the VMware Web Access
Administrators Guide.”

1. Open a command-line view on an ESX 3.x host and change into the
directory where the struts-config.xml is location at

cd /usr/lib/vmware/webAccess/tomcat/apache-tomcat-
5.5.17/webapps/ui/WEB-INF/

2. Make a backup of the configuration file with

cp struts-config.xml struts-config.xml-backup

3. Edit the configuration file with

nano –w struts-config.xml

4. Comment out the line that begins

<action path=“/scripted install …. Disabled.jsp

Note:
You comment things out by beginning the comment <!—and ending the
comment with -->. If you read the line just above it will tell you why we
are doing this. Basically this stops the warning message outlined above

<!-- Note: Please comment the line below, if enabling Scripted Install
Functionality. -->

5. Next remove the comments to enable the line that begins just
below with

<!--- <action path="/scriptedInstall"

type="com.vmware.webcenter.scripted.ProcessAction">

and ends with

<forward name="scriptedInstall.form7" path="/WEB-

INF/jsp/scriptedInstall/form7.jsp" />
</action>
-->

Figure 12.6 shows the layout of my configuration file

Page 13
 Figure 12.6

6. Save the file and exit nano

7. Restart the webAccess service with

service vmware-webAccess restart

Creating a base ESX KS.cfg File

Depending on your selection the web-based wizard displays 6 pages, each with a
specific purpose. The layout and design of these web-pages are not completely
intuitive – but they do work. For example you are asked about licensing twice on
three separate pages rather than just one (one page for the EULA, another for the
license mode and third for your license server name and port number). However,
this said, the scripted installer web-pages does a great job of creating a base
kickstart file which we can modify for our purposes.

• Page 1: Deployment Method, Time zone, root password

• Page 2: Input IP Settings of ESX Host
• Page 3: Accept EULA
• Page 4: Disk Partition Scheme and Licensing Mode
• Page 5: Licensing Server Information
• Page 6: Download completed kickstart file

1. Open your web-browser to the URL of your ESX Host

2. Click the hyperlink called Log in to the Scripted Installer
3. In Page 1 of 6, Change the installation method to be Remote
4. In the Remote Server URL type: http://<ipofuda>/esx/esx301/

Note:
The IP address I am specifying here is of the UDA appliance (not the
Windows file server), so adjust appropriate to your IP scheme. Also the
path here must be completed with /fedora/fc5/ as this is the default
location that UDA will look for your kickstart script – the final / is also
required by the ESX scripted installer tool.

5. For Network Method, select Static IP

Note:
This IP and directory location is where the physical ESX host will PXE boot
to. As ESX is based on the Anaconda Installer and so is Fedora Core 4 and
5 we can reuse the work done by the UDA.

6. Choose No, to the option to “Create a default network for VMs”

Note:
Set your VLAN and Time Zone as appropriate to your network and
geographical location.

Page 14
7. Set a default root password
8. Click Next

9. In Page 2 of 6, enter the IP settings for the ESX host

10. In Page 3 of 6, tick to Accept the EULA
11. In Page 4 of 6, create the partition table for the appropriate disk

Note:
If you are unsure what partitions to create check back to the first chapter
about installing ESX which discussed appropriate partitioning schemes.

Under “drive” column ensure you select the right type of device to
partition. In my experience my old Dell PowerEdge Servers which merely
have an Adaptec SCSI controllers always see the local disk or LUN as
/dev/sda. In contrast my HP DL385 Proliant server with a Smart Raid
Array 6i sees this device as /cciss/c0d0.

GOTCHA:
As well as reading the important warning here – be cautious if you are
doing the install with a SAN connected to the ESX host the way local
storage device is recognized can be very different from what you can
expect. I have seen cases where the internal disk or LUN is listed after all
the SAN LUNs and has device name of /dev/sdh rather than /dev/sda

Figure 12.7 shows the layout of my partition table. In this case I opted to
create a local VMFS partition in case I decided to use VM Clustering on this
host.

Figure 12.7

Note:
The tick next to the “Grow Option” indicates that this partition will be
created with the remainder of the disk or LUN. Personally, I would not

Page 15
 recommend creating VMFS using the scripted installation. Firstly, as
mentioned earlier in this book only the Vi Client can correctly cope with
the “disk alignment” issue. Secondly, although a scripted install will create
a VMFS partition in the LUN, it does not format it. You would be forced to
manually format this partition with vmkfstools –C command.

You might find it easier to create VMFS volumes at the end of the install
processes automated with the %post section of the kickstart.cfg file

12. Click Next

13. In Page 5 of 6, type in the name of your license server and what port
it is listening on (the default is 27000) and select your license type, in my
case Standard

Note:
This page appears because we choose to leave the default of “Use License
Server” in the License Mode section

14. On Page 6 of 6 click the Download Kickstart File button

Modifying the Base Kickstart File

When viewing the KS file in Windows I would recommend using the old DOS
editor (edit.com) or Wordpad. You will want to avoid notepad as it does not lay
out the KS file in a readable way. Of course, if you using Linux on your desktop
then Vi or nano will suit your purposes perfectly well. The KS file contains five
possible sections. We can customize it beyond the defaults asked in the web-
access scripted install tool on the ESX host:

• Command
• %packages
• %pre
• %post
• %vmlicense_text

The command section contains the main instructions to complete the installation
– some of these are vanilla and would be found in Linux installations, and some
are specific to ESX, including the network, clearpart, part, vmaccepteula and
vmlicense sections. %Packages are used to install additional components.
Scripts can be called in %Pre and %Post processed run just before and after an
installation. Of these the %Post is the most important – as we can call a script
here that will run VMkernel commands to handle such things as the creation of
vSwitches, iSCSI Software Initiator and NAS configuration. Lastly %vmlicense is
only used in a host-based licensing scenario, if you are using this format you can
append the contents of a host LIC file to the KS script below the %vmlicense
section.

Many of the commands you might be looking for can be viewed in the default
kickstart script that is left on an existing ESX host after a manual installation. It
is held in the /root directory and is called Anaconda.cfg. A complete list of KS
changes is perhaps too lengthy to dwell on here. If you are looking for a
comprehensive list of all the entries possible in the KS file visit:

https://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/sysadmin-
guide/s1-kickstart2-options.html

GOTCHA:

Page 16
There are some edits we need to make to the base kickstart file to make it work
correctly. If you have more than one disk or LUN, or your ESX host can see LUNs
on a SAN – then you will have to instruct Anaconda where the MBR record should
be written. This is done by modifying the # Bootloadder section.

Additionally, if you want to stop a prompt for which network card should be used
for the kickstart installation we need to edit a configuration file in UDA.

1. Open your ks.cfg file in Wordpad, Vi or nano

2. Locate the # BootLoader section
3. If your install LUN is presented to anaconda as /dev/sda then modify:

bootloader --driveorder=sda --location=mbr

4. If your install LUN is presented to anaconda as /cciss/c0d0 then

modify:

bootloader --driveorder=cciss/c0d0 --location=mbr

5. Save the ks file, and select all the text and copy
6. Back in the web-interface of UDA, click the Template Link, and create
a new template
7. Select all the text and paste your ESX based KS file – replacing the
default ESX 3.x.x KS file generated by UDA

Appendix 2: Enabling Windows DHCP with UDA

In some environments it maybe not possible to use the UDA's built-in DHCP
daemon. It is possible to disable the DHCP Service on the UDA, and configure a
Microsoft DHCP server to take over the role. This is quite an easy configuration
change:

To Disable DHCP On the UDA

1. Logon as Admin on the UDA's web-admin tool
2. Click the Services link
3. Select the DHCP link
4. Click the Configure button
5. Disable the option for Start DHCP on boot
6. Click the Apply button
7. Click the Services link again
8. Select the DHCP link again
9. Click the Stop button

To Enable DHCP On the Windows DHCP

1. Configure the following Scope Options or Server Options:
2. Enable the option 066 Boot Server Host Name, and set the empty
string value to be the IP address of your UDA
3. Enable the option 067 Bootfile Name, and set the empty string to be,
pxelinux.0

Page 17