get-admin

VMware is a facilitator. I know, you’re thinking “yeah, they facilitate my power/space/cooling savings, they facilitate infrastructure consolidation, IT agility, high availability, etc.”, but really, they facilitate me being lazy (which for sysadmins is a good thing…a lazy admin will only want to do a task once, then automate the sh*t out of it).

I’ve already documented how I hacked the ESXi 4.0 installer to have it do the installation without interaction. However, VMware has one-upped me and integrated kickstart into their installer. This makes things VASTLY easier, requires no tomfoolery with the ISO, and is significantly more capable.

This blog post will be just a short one to demonstrate how easy it is now to have the install be “touch-free”. I am working on some more complex examples in the coming days.

So without further blithering from me, on with the install! Put the CD in the drive (or mount the iso remotely), boot the server. When it reaches the boot options menu:

Press tab to append options to the boot line. Append the following after the vmkboot.gz, but before the --- after it.

ks=file://etc/vmware/weasel/ks.cfg

It is VERY IMPORTANT that you place the kickstart file location after vmkboot.gz, but before the next boot module. It should not be at the end.

mboot.c32 vmkboot.gz ks=file://etc/vmware/weasel/ks.cfg --- vmkernel.gz ---sys.vgz ---cim.vgz --- ienviron.vgz --- install.vgz

Here is an example:

When you’re done, press enter. It will begin to load the data off the CD, and when the different install modules are done it should simply begin to install ESXi just like how I had hacked it together previously…

The only thing left will be to press “Enter” when it’s done (why?!).

A word of caution…the kickstart that VMware has provided will automatically select and format the first disk that it finds, regardless of it being local or “remote” (i.e. a SAN LUN). I would assume that the vast majority of the time it’s going to find the local disks first, however……..

Hopefully in the next few days I’ll have some more time to play with the new kickstart features and post some more examples. VMware has really done some great things with this process and it is now possible to have the entire process be automated…
1) use DHCP to provide the “permanent” IP
2) use a network PXE boot for the media and to provide a KS file
3) use the --post section of the kickstart file to have the server reach out and touch a vCLI or PowerCLI configuration host and provide permanent configuration.

The reason that step one should provide the actual IP is that it provides an easy way of having your configuration host (vCLI or PowerCLI) know what IP (and potentially hostname) to assign to the host.

Good luck, and thanks to VMware for (finally) integrating kickstart with ESXi!

The last few posts I’ve been mentioning how much of the configuration for my ESX hosts is automated. This post I’m going to talk a little more about how that automation is done, and provide an example kickstart script. I have been holding off on this post for a while now, as I have been planning on rebuilding my PXE server, at which point I will document each step and be able to provide a much more detailed post. However, things keep getting in the way and I haven’t had time to rebuild the server yet, so this is a slightly less detailed post, but should still be enough to get you on your way And I have no doubt that you, dear reader, are not afraid of asking questions in the comments…

This automation is currently handled (I say “currently” because I’m working to move the majority of it to a remote host and use the SDK) by kickstart when the system is loaded. Well, to be totally honest, kickstart only plays a partial role in the process…during the %post section of kickstart I copy a series of scripts from an NFS mount point into the startup process (/etc/init.d/rc3.d), which are executed at first boot and, like good one-time-only scripts, remove themselves.

This setup allows me to pxe boot a host, give it the boot command which has the host ID appended, and that’s it. I can then walk away and wait for the host to add itself to vCenter, indicating that it’s finished. Kickstart and the post install scripts then configure the hostname, ip, virtual network configuration, security policy, ntp, base user set, install any custom RPMs, etc. This makes it extremely easy for me to keep all of our hosts at the same configuration level.

In order to keep all the hosts the same I simply have to update the relevant post install script when we decide to make a global change and it will configure the host correctly the next time it is loaded/reloaded. For updating hosts that can’t be reloaded (I try to reload the hosts periodically with the newest binaries from VMware…every 4-6 months…so that the software is not a huge conglomeration of patches…I know, it’s unnecessary, but it gives me peace of mind) we use a combination of Glenn’s POSH prowess and the perl toolkit scripts I’ve created to remediate hosts en masse to our baseline configuration.

Continue Reading »