Pages

Saturday 24 September 2011

ESXi 5.0 Kickstart Installation Part 2 – Getting the Kickstart Script kicking

ESX 5.0 Kickstart Installation

OK.  I must say, looking into VMware “vSphere Installation and Setup” guide for help doesn’t do much help.  Or, you only got 10% of the script required. 

Limited VMware Documentation

For booting and locating the Kickstart file, you can look into vSphere 5.0 documentation
Under the section "Boot Options", you will find some commands option to tell ESXi where to locate the kickstart script.

As for the kickstart script, you can find some information in
ESXi and vCenter Server 5.0 Documentation > vSphere Installation and Setup > Installing, Upgrading, or Migrating Hosts Using a Script > About Installation and Upgrade Scripts
Under the section “Installation and Upgrade Script Commands”.   You will find some commands there, but it will not bring you far for your scripting customization. 

Most ESX 4.1 Kickstart Script Don't Work
With my experience in creating kickstart script in ESX 4.1, I decided to reuse most of my 4.1 kickstart script. To my surprise, most of the command failed. That left me with no choice but to learn how to write vSphere 5.0 kickstart from basic again. 


 
Thanks to William and Duncan
After google for two days, I found some documents talking about how the 5.0 kickstart works with example, 50% of the example don’t work.  So, I am very much left with my own to figure out how to do it, with the help of these two very helpful and knowledgeable people.  Many thanks to William Lam and Duncan Epping for sharing their first hand information posted on their website.

http://www.yellow-bricks.com/2011/07/19/esxi-5-0-and-scripted-installs/




Now, this is the concept I concluded about VMware EXSi 5.0 kickstart script.d


The Boot Process and Calling the Kickstart Script
During the boot process of installing ESXi, you can press shift+O to bring you to a command line that you can input your kickstart command.  This is to tell ESXi where to locate the kickstart script to use for the installation.  In my case, by modifying syslinux.cfg in my USB Drive will do the job of telling ESXi how to locate the correct kickstart script in my USB Drive.

label ESX01
menu label ESX0^1 Scripted Installation
kernel /MBOOT.C32
append initrd=/ubninit -c boot.cfg ks=usb:/ksscript/ks_esx01.cfg +++


“label” is the menu item section name
“menu label” is the menu item text to be displayed .  The “^” is to highlight the quick key.
“kernel” keep it default.  Don’t touch it.
 “append initrd=/ubninit –c boot.cfg” keep it there. 

The magic to get it work is to
append the following statement here.
ks=usb:/ksscript/ks_esx01.cfg +++” to tell ESXi that if this menu item is selected, use the kickstart script located in this USB Drive, under /ksscript directory, and the file name is called ks_esx01.cfg.  Now don’t ask me what the “+++” is.  Some say it is required, and yes, it works.



The Kickstart script process and stages

After some testing, I realized that the Kickstart script is divided into Four stages. 
1)      Pre Stage: Pre ESXi installation stage
2)      Actual ESXi Installation Stage
3)      Post Stage: After ESXi finished installation on the hard disk, but before it does it’s first installation reboot
4)      Firstboot Stage: After ESXi done it’s first reboot.

If you refer back to VMware documentation guide state above and quoted as below

%pre (optional)
Specifies a script to run before the kickstart configuration is evaluated. For example, you can use it to generate files for the kickstart file to include.
--interpreter=[python|busybox]
Specifies an interpreter to use. The default is busybox.

%post (optional)
Runs the specified script after package installation is complete. If you specify multiple %post sections, they run in the order that they appear in the installation script.
--interpreter =[python|busybox]
Specifies an interpreter to use. The default is busybox.
--ignorefailure =[true|false]
If true, the installation is considered a success even if the %post script terminated with an error.

%firstboot
Creates an init script that runs only during the first boot. The script has no effect on subsequent boots. If multiple %firstboot sections are specified, they run in the order that they appear in the kickstart file.
--interpreter =[python|busybox]
Specifies an interpreter to use. The default is busybox.

This are the three stages that you can use in your script. 


Installation Stage

As for the actual ESXi installation, these are the command that you can use.  Cut and pasted from vSphere 5.0 documentation.  I called this the Installation Stage.

These 4 commands are standard, must be in the script.

accepteula or vmaccepteula (required)
Accepts the ESXi license agreement. This command functions as it did in ESXi 4.1.

rootpw (required)
Sets the root password for the system.

network (optional)
Specify a network address for the system.

reboot (optional)
Reboots the machine after the scripted installation is complete.



The below command is for the "First Hard disk" detected and installation of ESXi with VMFS 5 creation and partition.

clearpart (optional)
Compared to kickstart, the behavior of the ESXi clearpart command is different. Carefully edit the clearpart command in your existing scripts. Clears any existing partitions on the disk. Requires install command to be specified.

install
Specifies that this is a fresh installation. Replaces the deprecated autopart command used for ESXi 4.1 scripted installations. Either the install, upgrade, or installorupgrade command is required to determine which disk to install or upgrade ESXi on.

installorupgrade
Either the install, upgrade, or installorupgrade command is required to determine which disk to install or upgrade ESXi on.

upgrade
Either the install, upgrade, or installorupgrade command is required to determine which disk to install or upgrade ESXi on.

The below commands are of not much of concerns to the success of the ESXi installation.

paranoid (optional)
Causes warning messages to interrupt the installation. If you omit this command, warning messages are logged.

part or partition (optional)
Creates an additional VMFS datastore on the system. Only one datastore per disk can be created. Cannot be used on the same disk as the install command. Only one partition can be specified per disk and it can only be a VMFS partition.

%include or include (optional)
Specifies another installation script to parse. This command is treated similarly to a multiline command, but takes only one argument.

dryrun (optional)
Parses and checks the installation script. Does not perform the installation.


keyboard (optional)
Sets the keyboard type for the system.



The Basic Kickstart Script Layout
Ok, after the long story.  Let’s put everything back in place on how the basic script will look like.


{script for installation stage}

%pre --interpreter=busybox
{write script to execute for pre installation stage}

%post --interpreter=busybox --ignorefailure=true
{write script to execute for post installation stage}

%firstboot --interpreter=busybox
{write script to execute after first reboot}


As for my case, I am looking at removing my 4.1 ESX partition completely.  Hence, I selected the “clearpart” to clear all my ESX 4.1 partition, follow by “Install” on my first hard disk.  Do nothing on my second hard disk where all my VM reside.

The first “network” command is important here.  You can leave it with DHCP and modify later.  But I felt it is better to specific the setting here as the first “network card” will bind with the “management traffic” setting.  If you don’t do it now, you will have a long script to write later to enable the interface with “Management Traffic”.


Hence, my actual basic kickstart script look like this

vmaccepteula
clearpart --firstdisk –overwritevmfs
install --firstdisk –overwritevmfs
rootpw abcxyz

network --bootproto=static --device=vmnic0 --ip=10.0.0.61 --netmask=255.255.255.0 --gateway=10.0.0.1 --hostname=esx01.localdomain --nameserver=10.0. 0.254 --addvmportgroup=0

reboot –noeject

%pre --interpreter=busybox

%post --interpreter=busybox --ignorefailure=true

%firstboot --interpreter=busybox


Notes

The script for ESXi installation stage is short and please keep it that way.  If there are any errors, the installation will not proceed.  Hence, keeping it short and error free, and get the first copy of ESXi installed on the hard disk is the key to this stage.

In my view, there is nothing much you can do with %pre and %post.  The reason is that you can’t run any esxcli and vim-cmd command here as the full Shell is not loaded yet.  Hence, you can’t customize anything here.   The only reason that I can think of is to drop some files into the ESXi hard disk during the post stage so that you can use it later after the firstboot stage. 

The script after the firstboot stage is where all the customization starts when the full ESXi is loaded and when the full Shell started.

I will touch on more script after %firstboot on my part 3 of ESXi 5.0 Kickstsart Installation.



3 comments:

  1. Thomas, good description on how kickstart works under ESXi 5.0.

    ReplyDelete
  2. Really good post! You were right about your comments in the beginning. Vmware docs about this subjects suck! It's pretty much what you do on your own.
    Thanks for finding the time to share your experience.
    Great resource!

    ReplyDelete
  3. I want to copy the OVA's to the datastore and deploy them offline. But I am not able to do it

    I copied the files in ova directory and used the following command:

    cp -R /vmfs/volumes/CDROM/OVA/* /vmfs/volumes/datastore1/


    but did not succed, can you help me on this?

    ReplyDelete