When we’re ready to deploy new ESXi hosts in our environment, we order them from Dell with ESXi pre-loaded on the internal SD-Card. This is nice and all, but what do you do when you have to go through and configure NTP, Users, Groups, Scratch directory, lockdown mode, and the list goes on?

You’d have to fire up each server, go through and configure everything, x10 if you had 10 new servers.

Since we’re working on a new rather larger virtualization deployment, we were looking at ways to overcome this.

On our standard fat ESX hosts, we used to use Altiris to PXE boot and run a kickstart file, but when Symantec bought Altiris and doubled the price, we dropped them and went to a new solution: ESX Deployment Appliance, or EDA

The EDA is awesome, except I couldn’t get it to deploy across different VLANs at different sites, instead I just created an EDA for each ‘cluster’, which worked well. Also, instead of using all of their script options, I edited the php file to use all our stuff from our standard kickstart, and only pulling name, ip, and a few other pieces from the EDA web page. All in all, that works really well since you can pre-stage your hosts, as long as they’re full blown ESX.

EDA also works for ESXi, but only in the base OS deployment, no configuration options, so here’s what we did…

We took one server and set it up with everything we wanted (CNA device drivers that aren’t already in the media, etc), installed ESXi, configured storage, set up a scratch directory, fully patched, configured users, NTP, and anything else we wanted, then shut the system down.

From there, we popped out the SD-Card, set it to read-only so as not to kill our golden image, and used WinImage to create an image of the drive. After that, we simply wrote that image to all other SD-Cards.

True, after we wrote the images, there’s still some config needed. We have to change the scratch directory, name, IP address, and iSCSI target (if you’re using iSCSI, that is).

This is much easier than doing all the config over and over, especially since a reboot is needed after the scratch directory is configured, then again after third party drivers are loaded, and yet again if your media is 4.0u1 (build 208167) because build 219382 was released in early January, iirc.

We did find a windows port of dd, but it proved problematic. It would suck up the image fine (as far as we could tell, anyway) but wouldn’t let us write to the SD-Card if a partition table existed, so we’d go into diskpart and do a clean on that disk. Disk management showed an empty disk, and dd would write the image, but whatever was on the SD-Card previously was still there, kinda like it only wiped the MBR or partition table.

It might work in *NIX, but we didn’t have any sd-card readers handy to try in other systems, only the internal one on a windows laptop.