I recently added the ESXi 4.1 base template kickstart file to xCAT. The code is checked in here. We’ve had the ability to do stateless ESXi 4.1 since it came out and we’ve been doing stateless ESXi 4.0 as well. But for some of our customers, we have needed a way to get the ESXi 4.1 server on the disk. This seems to be the most common way people want to install VMware ESX(i) these days. We hope in the future more people will go stateless. But for now, here is our xCAT ESXi 4.1 base kickstart file:
# Sample scripted installation file
# edited and updated by firstname.lastname@example.org
# Accept the VMware End User License Agreement
# Set the root password for the DCUI and Tech Support Mode
rootpw –iscrypted #CRYPT:passwd:key=vmware,username=root:password#
# clear all partitions.
clearpart –alldrives –overwritevmfs
# Choose the first disk (in channel/target/lun order) to install onto
autopart –firstdisk –overwritevmfs
# The install media is on the network.
install url http://#TABLE:noderes:$NODE:nfsserver#/install/#TABLE:nodetype:$NODE:os#/#TABLE:nodetype:$NODE:arch#
# Set the network to DHCP on the first network adapter
#network –bootproto=dhcp –device=vmnic0
# reboot automatically when we’re done.
# A sample post-install script
%post –interpreter=busybox –unsupported –ignorefailure=true
# tell xCAT management server we are done installing
# have to put in the IP address instead of the hostname because VMware
# ESXi 4.1 can not resolve IP addresses…
# enable SSH on next boot:
%firstboot –interpreter=busybox –unsupported –level=47
sed -ie ‘s/#ssh/ssh/’ /etc/inetd.conf #ssh is too nice not to have
Since this is an xCAT kickstart template then you see the #TABLE … # and #COMMAND ..# tags in there. Basically these are just cues for xCAT to look up the different attributes for the nodes so that it can customize this one template to be used on the entire data center. So the password, main HTTP server, and xCAT server are all stored in the xCAT database.
I have two scripts in here. The first is the %post. This script simply signals back to xCAT that it is done installing so that the next time it reboots, instead of reinstalling, xCAT will tell the node to boot to hard disk. This happens right after the install.
The second is the %firstboot script. Notice that I added the –level 47 to the script. This is important as it tells this script when to run. If you look at /etc/vmware/init.d/init you’ll see the levels. Level 48 starts the networking. Before the networking starts, I want to enable SSH, so I just uncomment the section inside /etc/inetd.conf to allow SSH to happen on boot. (Another thing you could do is just do an /etc/init.d/TSM-SSH start)
So this template is stored in xCAT in /opt/xcat/share/xcat/install/esx/. You can have a node boot to it (provided the rest of xCAT is setup and copycds have been run) by doing the following:
nodeset <noderange> install=esxi4.1-x86_64-base
rpower <noderange> boot
Then the template is copied into the /install/autoinst/ directory and the name is changed to match the node and all variables are substituted in. Then the PXE server and DHCP server are set to point to the file to grab and install the node. This is in xCAT 2.5 which you can get now as the development release (make sure you grab the files at the bottom in the ‘Development Builds’ section)
Another thing that is fun to do with the ESXi kickstart file is to make a new VM as part of the kickstart install. Generally I recommend using an NFS server to store your VMs on, but there are cases where you just want them on the local drive. As part of the above kickstart file, the datastore1 partition is created. This is a place where you could now run the vim-cmds during post to create machines. This is easy to do during the firstboot section (you would probably do this at level 99) but not so easy to do in the %post section.
The problem with the %post section is that hostd isn’t running so none of the vim-cmds will work. So you have to start it. This can be done by running:
But wait, there is another problem! The hostd command doesn’t return and hangs! So you have to use some magic (like creating a script to run it that forks off and returns) otherwise your %post hangs forever. (This is a total bug)
Anyway once you work around that then just running the commands like:
/bin/vim-cmd solo/registervm /vmfs/volumes/datastore1/vm01/vm01.vmx vm01
/bin/vim-cmd vmsvc/power.on 16
Seems to work. But, during %firstboot, you’ll have to reregister them again.
I hope to put more information on this as we go forward with it. I am happy that VMware has made this kickstart file for 4.1 and I can only see it improving over time. The more automation the better and with kickstart we can really automate everything we need.