Create local VMFS with 8MB block size during ESX4 kickstart install

I’ve been creating a new kickstart script, to automate ESX 4 deployments.  There were a couple of pieces missing that I couldn’t find a good solution to online.  This was the first. Hopefully recording it here might save someone else a bit of time.

Before I start, I would like to point everyone to this excellent blog post by Mike La Spina.  If you are thinking about using kickstart for your ESX deployments, then this post is fantastic.  Thanks Mike.

Problem: When you create VMFS partitions during the ESX install, they are all created with a 1MB block size.

To get around this, I found a couple of suggestions:

  • This forum post has a suggestion by Mike, however it doesn’t seem to work as advertised.
  • PatrickD has an interesting solution on the forums, which runs before the install and effectively changes the default to 8MB (I found this via Duncan’s post here).  However this would mean all VMFS partitions would take this default during the install and I’m always concerned that the format on the DVD might change and break the script.
  • Gabe has a great post here, about doing this manually at the command line.  But I wanted something scriptable.

To be clear, I wanted a VMFS partition that would house my esxconsole.vmdk file and a separate VMFS partition to fill the rest of the remaining local disk.  This has the advantage of splitting the VMs from the OS, meaning VM snapshots are never going to impact your OS and rebuilding the OS at a later stage should be much less invasive on your precious data.

Here is the partition structure that I was looking for:

# Create new partitions
part /boot –fstype=ext3 –size=1100 –onfirstdisk
part None –fstype=vmkcore –size=100 –onfirstdisk
part  [HOSTNAME]-cos –fstype=vmfs3 –size=40960 –onfirstdisk
part temp_partition –fstype=vmfs3 –size=1024 –maxsize=2047000 –grow –onfirstdisk
virtualdisk cos –size=35840 –onvmfs=[HOSTNAME]-cos
part swap –fstype=swap –size=1600 –onvirtualdisk=cos
part /var –fstype=ext3 –size=2048  –onvirtualdisk=cos
part /tmp –fstype=ext3 –size=2048 –onvirtualdisk=cos
part /home –fstype=ext3 –size=2048 –onvirtualdisk=cos
part /opt  –fstype=ext3 –size=20480 –onvirtualdisk=cos
part / –fstype=ext3 –size=5120 –onvirtualdisk=cos

This creates the following physical partitions (you can see this with fdisk after the build):

  1. primary partition – /boot
  2. primary partition – vmkcore
  3. extended partition
  4. unused primary partition
  5. VMFS partition for my esxconsole file (40GB)
  6. VMFS partition for my VMs

It is the last partition that I want to create with an 8MB block size. So using the great suggestion from Gabe above, I’ve made it work in the kickstart script.

To do this, I create the VMFS partition during the kickstart install in the usual way with this line:

part temp_partition –fstype=vmfs3 –size=1024 –maxsize=2047000 –grow –onfirstdisk

This creates a partition called “temp_partition”, 1GB in size and grows it to fill the remaining space.

Then I add a script in the post install section, which runs after the first reboot (thanks to Mike for the script format):

# Create post config script
cat << EOF > /etc/rc3.d/S99postconf
#!/bin/bash

# Allow hostd etc. some time to load
/bin/sleep 90

# Recreate VMFS partition for VMs to an 8MB block size
disk=”`ls /vmfs/devices/disks/vml*6`”;vmkfstools -C vmfs3 -b 8m -S [HOSTNAME]-01 $disk

# Reset system to normal boot mode
echo “Removing automated post script.”
rm /etc/rc3.d/S99postconf
EOF
chmod +x /etc/rc3.d/S99postconf

The important line here is:

disk=”`ls /vmfs/devices/disks/vml*6`”;vmkfstools -C vmfs3 -b 8m -S [HOSTNAME]-01 $disk

Basically it sets a variable “disk”, which is equal to the original disk label given to partition 6 created during the install.  It then uses that to recreate the disk but with an 8MB block size.  How come I know its always going to be disk 6?  I can do this because I know my partitioning structure is always going to be the same – its scripted!

One thing to note – if you choose to use this script in the future to rebuild a host and don’t want to overwrite any existing VMFS volumes in the main kickstart script (by not specifying the –overwritevmfs flag), this post-install script will just ignore that and overwrite it anyway.

Edit: I’ve changed the name of the temporary partition as the old name might have been confusing.

10 thoughts on “Create local VMFS with 8MB block size during ESX4 kickstart install

  1. Hi, is there a way, through which I can log all what is done by the kickstart file to a log file?
    I am looked around and did not find much info on this.

    Thanks

    1. Hi Tom,
      The regular install bit is logged to /var/log/esx_install.log
      However, if you want each step of your kickstart script logged you should be able to echo each bit out to a local file. If you want to know if each command was successful or not, then that would involve a bit more work. Should be do-able but would involve a bit of investigation.

  2. This works great if you are not loading your COS onto VMFS, but does anybody know of an option when you place COS within VMFS? Our Kickstart looks like:

    zerombr
    bootloader –location=mbr
    clearpart –firstdisk –overwritevmfs

    # boot partition, vmk partition and the rest is vmfs for COS
    part /boot –fstype=ext3 –size=200 –onfirstdisk –asprimary
    part None –fstype=vmkcore –size=100 –onfirstdisk
    part vgLocal –fstype=vmfs3 –size=21000 –onfirstdisk –grow

    # create a virtual disk
    virtualdisk cos –size=20000 –onvmfs=vgLocal

    # 512M swap, 10G root, the rest is for logs in /var
    part swap –fstype=swap –size=512 –onvirtualdisk=cos
    part / –fstype=ext3 –size=10000 –onvirtualdisk=cos
    part /var –fstype=ext3 –size=8192 –onvirtualdisk=cos –grow

  3. That procedure is quite complex and basically it’s all about changing the file fsset.py to include blockSizeMB to 2, 4 or 8. As we install ESX servers through RIS, I did this another way.

    The file initrd.img basically contains a gzipped archive of the installation files as loaded onto the server. So I gunzipped it and used hexedit to find the blockSizeMB parameter in the fsset.py file and changed the number 1 into 4. Then I gzipped it again and copied the new file on my RIS server. Now all my installations are formatted with a blocksize of 4MB without manual intervention.

    1. Any reason you chose 4MB and not 8MB? There really is no performance issue, or wasted space, so I’d always go for 8MB. Even if the drive isn’t that big, you never know when you might start using that install CD on a bigger server. Just curious.

  4. No specific reason. So I might have taken 8MB as you said. I just needed to have virtual disks that are bigger than 256GB and the biggest I have is 700GB.

    The initrd.img modification just makes things very easy for me 😉

    I’m using it on a RIS server, but I guess this modification can be done for DVD installs and so on too.

Leave a Reply