Automating ESXi 4.1 continuation
William Lam has posted a great article on tips and tricks of automating ESXi 4.1 here. Go read his post first.
Seriously, go read his post first.
Ok, you’re back?
I wanted to add to his post with some issues and fixes I’ve run across with moving from ESX to ESXi automation.
With ESX 4.0, at the beginning of the ks.cfg file, you would specify an install line. Nothing else was needed as the url location of the install bits was passed in the PXE config line. No more. For ESX(i) 4.1, you must specify the url for the install location in the ks.cfg file.
Beginning with ESX(i) 4.1, ip append 2 in the PXE config boot line no longer works. What does this do exactly? This told the ESX(i) to use the same nic it booted from for downloading the install bits. If this was not specified, ESX(i) would try to use the first nic it detected, vmnic0. With ESX(i) 4.1, you must specify ksdevice=vmnic(x) if you are booting and installing from a different nic than vmnic0. I’m not sure why this behavior changed between 4.0 and 4.1.
William did mention vim-cmd. In ESX, the command is actually vmware-vim-cmd. For ESXi, be sure to update these commands to vim-cmd.
For disk setup, I have two lines in my ks.cfg file: clearpart –onfirstdisk –overwritevmfs and autopart –onfirstdisk –overwritevmfs. I did notice this will create the datastore name on each ESXi host as datastore. I need to investigate if this can be changed at this part, or add a line in the script to update that name.
In my working with scripting ESXi installations, I’ve found it much easier to have everything run after firstboot then trying to run the configurations before firstboot.
Plenty of advanced configurations (SNMP, Active Directory, adding to vCenter) can be handled through the scripted install, but involve writing a python script to handle. For some, it will be easier using the supplied commands in the vMA or writing PowerShell scripts.
Outside of these differences, scripted ESXi installs are awesome.
Check out Tip #10 regarding renaming the default datastore. I believe you can also set the default datastore name by using the “datastorename” parameter but I have not verified this.
William Lam
September 12, 2010 at 9:25 am
Thanks. Not sure how I glanced over this in your post. May test this today and provide an update.
jguidroz
September 12, 2010 at 9:57 am
We’ve found, while doing firstboot scripting with ESXi 4.1, that vim-cmd commands fail (login not allowed, or something simelar). For now, we’ve gotten around this by downloading (using wget) and running our own “first boot” script in the background. So, in the firstboot section, use something like:
# DL and run our own first boot script in the background.
# Otherwise vim-cmd commands fail.
wget http://webserver/script.sh
chmod 700 script.sh
./script.sh&
The script.sh sleeps for a while, to make sure hostd is accepting connections and the boot process is finished.
We have a Makefile, and variable substitution, which we use to create a kickstart file and “custom first boot” script for each ESX host – so the kickstart file for a particular host, downloads the proper script to be run in the background.
Ivan
September 12, 2010 at 12:04 pm
Interesting. I’ve seen no issues with vim-cmd.
jguidroz
September 12, 2010 at 2:28 pm