This week I’ve been working on a means to automate the installation of ESXi with as much of the configuration completed as possible. By this I mean joining the host to an AD for local auth, joining the host to a vCenter environment, building out local vSwitches and implementing as much of the hardening guide as possible. This is the first time I’ve ever used the unattended install kickstart process and it has been slow but pleasing progress. It would appear that almost all my requirements are possible, but may not be so easy through the kickstart process which is why I’ve also utilised the PowerCLI capabilities of vSphere to capture the impossible/difficult bits as a post deployment script. All scripts are in early development and continue to progress as other parts of the infrastructure appear and allow additional functions to be possible.
My objective here is to ensure that all hosts are built identically by removing as much user intervention as possible and quick to deploy with little need to work through complex processes. Yes, you can right a build guide with all the information and steps in minute detail, but steps can be missed for any number of reasons which poses a risk that each host could end up different, or missing a vital security configuration. A mis-configured script could achieve the same result, but the speed of installation is important to me as it is possible other IT support staff will take over the infrastructure once deployment is complete and I want a good, clean, simple process for them to use should they need to deploy more hosts (which is likely too).
Installing from a USB key onto a server that had a local RAID1 array and USB Flash card, the first challenge was to get ESXi to install to the correct USB device, not onto the HDD and certainly not onto the install media USB (which it did the first time of trying!). After some investigation into the kickstart script options I figured out how to achieve this objective but also how to prepare the local HDD for a VMFS datastore at the same time. This was great because I wanted to rename the local datastore through an initial installation process anyway, so sorting out how to build it was taking me in the right direction.
Next came the network info for the management port, and I did have trouble here trying to use the %pre option I’ve seen used in so many online locations….it just complain about “/.pre” and falling over so I left that challenge for later opting for putting the IP details onto the command line. I’m hoping to use a combination of DHCP/DNS and scripting to grab the correct network details from the network and apply that. I also configured a number of vSwitch which were needed for the primary objective of this activity and set security etc. With a few additional %firstboot configuration additions, the install was working nicely but I wanted more!
I don’t yet have a Windows AD, DHCP or DNS so we’re in the early phase of this project task but I’ve seen that it is possible to get a host to join an AD and also a vCenter from the kickstart process. I’ve also seen people creating a local user account with shell access and setting perms but I decided to leave this out of this initial script for now.
With the ESXi host built and configured with it’s local datastore renamed, vSwitch configured and some hardening achieved, I moved to working on a PowerCLI script to complete some other actions needed for a clean and simple installation. One big issue I had that I couldn’t find a way of doing during the unattended install, was to rename the default PortGroup used by the Management VMkernel. I like to rename all PortGroups, which is easily done post-install via the VIClient, but this particular one was trouble for me. So, one reason for PowerCLI because it is easy to do there! Another cool task achieved at this stage was adding the host to vCenter and into the right cluster. There will be several clusters operational so any automated (or semi-automated) process needs to be able to select the correct one without modifying code to do so. PowerCLI did this with ease too. While I was adding things to hosts and vCenters I thought why not add the local user and assign it to a role, propagating it! Again, easy to do………..although I did have problems until I realised I’d spelt propagate wrong!!!
Lots more things to do with these scripts and more scripts to appear as I try to automate, ease the administration of the solution during deployment. What I’d love to be able to do is automate the activation of a PowerCLI script from the kickstart install so it can be processed without user intervention until 100% completed. I’d also like to figure out how to get my boot USB to auto-select the ks.cfg file without me have to SHIFT+O all the time. I’ve tried adding runweasel=ks=usb:/ks.cfg to the BOOT.CFG kernelopts!