Kickstart: Local Datastore Not Destroyed On Reinstall

[JCCHAMPION]

I've noticed that when I reinstall ESXi 5 on a previously built server, the previous local datastore is not destroyed.

I specify to do an "install" and "overwritevmfs"

   install --firstdisk=mptsas,local --overwritevmfs

at the top of the kickstart but the previous local datastore remains.

I have tried using clearpart

   clearpart --alldrives --overwritevmfs

but the local datastore remains from the previous build as well.

Part of my kickstart process is to rename the local datastore (datastore1) to a meaningful name that includes the hostname so if I reinstall, the datastore rename fails (since datastore1 doesn't exist on the 2nd install).  Also, I need to know the datastore name since I am extracting files to "/" during installation (using oem.tgz) and move them prior to the first reboot in the %post section (or they'll be gone). The only persistent location is the local datastore. This also effects the kickstart during syslog relocation which goes to the local datastore as well.

Any suggestions on how to clear an existing local datastore during installation (short of deleting the RAID and recreating it)?

-- JC

[gmarcil]

I am facing the same problem...

Also note that deleting and recreating the volume does not destroy the volume label.

I verified this by:

     a- deleting the Raid Volume in an HP Smart Controller  (on boot-up F8...) blade server

     b- recreated the Raid volume

     c- reinstalled ESXi5.0 on the newly reinitialized local volume

  

The ESXi installation discovers the old label and will recreate the new VMFS volume using the 'OLD' label instead of default label of 'datastore1'

I guess that the re-initializing the volume at boot time does not erase enough information from the disk so I would suggest that you delete the old disk information by erasing the 1MB of data.

I will update if I find a workaround.

--GM

[gmarcil]

I wrote the following script to rename the old local ESXi 5.0 datastore with the help of kickstart first-time script:

_____________________________________________________________________

accepteula

#clearpart --firstdisk=cciss,local --all --overwritevmfs # Deletes all partitions of local drive (for G1 Blade servers) but won't delete the VMFS label

clearpart --firstdisk=hpsa,local --all --overwritevmfs # Deletes all partitions of local drive (for G6 Blade servers) but won't delete the VMFS label

install --firstdisk=hpsa,local --overwritevmfs

rootpw SECRET

reboot

%include /tmp/networkconfig

%pre --interpreter=busybox

# extract network info from bootup

VMK_INT="vmk0"

VMK_LINE=$(localcli network ip interface ipv4 get | grep "${VMK_INT}")

IPADDR=$(echo "${VMK_LINE}" | awk '{print $2}')

NETMASK=$(echo "${VMK_LINE}" | awk '{print $3}')

GATEWAY=$(esxcfg-route | awk '{print $5}')

DNS="10.130.0.21,10.130.0.22"

HOSTNAME=$(nslookup "${IPADDR}" | grep Address | awk '{print $4}')

echo "network --bootproto=static --addvmportgroup=false --device=vmnic0 --ip=${IPADDR} --netmask=${NETMASK} --gateway=${GATEWAY} --nameserver=${DNS} --hostname=${HOSTNAME}" > /tm

p/networkconfig

%firstboot --interpreter=busybox

# Extract the host number from the hostname

# Example: sc-moon01.tapkit.net = '01, sc-moon02.tapkit.net = '02,sc-moonNN.tapkit.net = 'NN,'

hl=`hostname -s |wc -c`

hostNum=$(hostname -s | cut -c`expr $hl - 2`-`expr $hl - 1`)

# Rename local datastore to something more meaningful

# Find the current local datastore name/LABEL (Exclude all SAN HSV200 datastore)

DatastoreName="$(esxcli storage vmfs extent list | grep ` esxcli --formatter=csv --format-param=fields="Device,Model" storage core device list | grep -v "HSV200" |grep -v "Device" | cut -d, -f1` | awk '{print $1}')"

NewDataStoreName="datastore$hostNum"

# Rename the datastore

vim-cmd hostsvc/datastore/rename $DatastoreName $NewDataStoreName

# copy %first boot script logs to persisted datastore

cp /var/log/hostd.log "/vmfs/volumes/$NewDataStoreName/firstboot-hostd.log"

cp /var/log/esxi_install.log "/vmfs/volumes/$NewDataStoreName/firstboot-esxi_install.log"

# Needed for configuration changes that could not be performed in esxcli (thanks VMware)

reboot

_____________________________________________________________________

Hope this help...

Many thanks to William Lam for his great contribution:  http://www.virtuallyghetto.com/2011/07/automating-esxi-5x-kickstart-tips.html

Gilles Marcil

[JCCHAMPION]

Great solution for finding the current datastore name - I definitely will use that and works around the rename issue very nicely. This needs to be reported as a "bug" I believe and should get fixed as soon as possible in a patch/bundle - not Update 1 (or whatever they'll call it in vSphere 5 :smileywink: )

However, I still have the problem of getting files off the custom ISO onto the newly built system.

I'm not sure what commands are even available in the %post section but I need to move (mv) files from the / partition in %post to the local datastore. So I need to either 1) determine the local datastore in the %post section or 2) figure out a different path/location that persists after reboot.

I use a custom .tgz to get any update bundles (there already is one for ESXi 5 amazingly!) onto the system during installation, then in the %firstboot I apply the update bundles using the "esxcli software vib install" command.  The custom .tgz is extracted as part of the install command line in boot.cfg (--- custom.tgz).

So, %post looks like this:

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

mv /*.zip /vmfs/volumes/datastore1

...and in %firstboot the datastore is correctly renamed then:

#################
# APPLY UPDATES
#################

esxcli software vib install --maintenance-mode --depot /vmfs/volumes/$DATASTORENAME/ESXi500-201109001.zip

...but is it possible to determine the current datastore name in %post?

Will let you know if I come up with anything...if anyone else does please let us know too :smileygrin:  Copying files onto the system during installation is a fairly common task for automated builds, whether it be update bundles, scripts, or modifying existing files (ie /etc/motd, /etc/issues).  Placing them on the local datastore in %post is the usual method.

-- JC

[JCCHAMPION]

Came up with something similar using localcli in th %post section:

#######################################

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

#######################################

CURRENTDS=`localcli --format-param=show-header=false storage vmfs extent list | grep -E "vmhba1:C0:T0:L0" | cut -d " " -f1`

mv /*.zip /vmfs/volumes/$CURRENTDS

localcli --formatter switch only takes xml as a parameter but removing the header is sufficient.

Bad thing with this method is it's hardware specific (grep -E).  This example works on an ESXi VM in Workstation. On a Dell server with SSDs it comes up as an "naa.xxxxxxxxxxxxxxxxx" device - will take some testing to see how consistent the reference is across servers.

For use in the %firstboot section replace localcli with esxcli (but not necessary). Only difference is localcli does not require the hostd process to be running while esxcli does (and changes made with localcli would require a reboot).

Maybe the best solution is to not rename the local storage to begin with :smileygrin: But what happens if the admin decides to rename it themselves later and a rebuild is needed.

Still needs to be fixed! :smileyconfused:

-- JC

[mwzard]

Has anyone come up with a solution to destorying the Local Datastore on reinstall?

[William Lam]

Take a look at this blog article which provides steps to ensure VMFS label defaults back to "datatore1" - http://www.virtuallyghetto.com/2012/04/removing-previous-local-datastore-label.html

[JCCHAMPION]

Instead of trying to destroy the partition (which seems to have mixed results) and recreate it, I thought why not just retrieve the name of the datastore (in %post and %firstboot) then rename in %firstboot. Assumptions: only 1 local datastore and external storage is unreachable.

There's probably a cleaner way to get the local datastore name (and would love to see them) but this works for our environment :smileygrin:.

#######################

%pre --interpreter=busybox

#######################

# MASK FC LUNS (Ref: http://www.virtuallyghetto.com/2012/04/disable-lun-during-esxi-installation.html)

localcli storage core claimrule add -r 2012 -P MASK_PATH -t transport -R fc
localcli storage core claimrule load
localcli storage core claiming unclaim -t plugin -P NMP
localcli storage core claimrule run

#######################

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

#######################

# FIND EXISTING LOCAL DATASTORE NAME (if any)

LINECOUNT=`localcli --format-param=show-header=false storage vmfs extent list | wc -l`

if [ $LINECOUNT = 1 ] ; then
   LOCALDS=`localcli --format-param=show-header=false storage vmfs extent list | cut -f1 -d" "`
else
   LOCALDS="datastore1"
fi

# MOVE FILES TO LOCAL DATASTORE (files were extracted during installation using a tgz file in the boot.cfg)

mv /*.zip /vmfs/volumes/$LOCALDS

###########################

%firstboot --interpreter=busybox

###########################

SVRNAMESHORT=`hostname | cut -d'.' -f1`

LINECOUNT=`localcli --format-param=show-header=false storage vmfs extent list | wc -l`

if [ $LINECOUNT = 1 ] ; then
   OLDDATASTORENAME=`localcli --format-param=show-header=false storage vmfs extent list | cut -f1 -d" "`
else
   OLDDATASTORENAME="datastore1"
fi
DATASTORENAME="$SVRNAMESHORT-Datastore"

.....

.....

vim-cmd hostsvc/datastore/rename $OLDDATASTORENAME $DATASTORENAME

localcli storage core claimrule remove -r 2012