ESXi: Kickstart installs using CD-ROM or USB media

Kickstart and PXE are almost always used in conjunction, however you don’t have to use PXE to kickstart your installs. Fortunately you can provide the location of a kickstart even if you are using bootable media from USB and/or CD-ROM.

The process I’m going to describe here involves putting the kickstart(s) in a place accessible on the CD/USB media. This is particularly useful if you have an isolated network, a network that has limited resources or if you simply want to eliminate any questions during a manual install process. For example, I use kickstart to do the basic network configuration and the like, however there are very few things that can not bet set via the command line, so, you could, if desired, use kickstart as a method of configuration management. Or, you could simply have it do the install exactly the same as if you answered the questions when the default media is booted, but without actually answering the questions for each host.

You can also provide kickstart files from a web or NFS server even if you are using media. This can prove especially beneficial if you have frequently updated kickstarts (or a large number of them) and you don’t want to have to update the media when kickstarts are changed and/or added. VMware’s documentation describes how to provide the location if you are using web (http) or NFS as the method for providing the configuration.

The example I have here was done from a linux host (RHEL5 to be exact). All of this is reproducible in Windows, however I am not providing any documentation on how to do that.

Read moreESXi: Kickstart installs using CD-ROM or USB media

VMware vSphere Hypervisor (ESXi) 4.1 kickstart – A.K.A. official “touchfree” ESXi installs

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:

ESXi 4.1 Boot options screen

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


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:

ESXi 4.1 Boot Options with KS

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…

ESXi 4.1 KS Install

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!

Experimenting with the vSphere ESXi install process

I suppose easy is relative.

One of the comments to the post I made about touch free ESXi installs asked about testing without having to reboot and wait for the install process to load, and fail, to determine what went wrong. I did this testing by switching to a different console and using the Python interactive shell to load the same modules VMware uses, call their methods, and simply look at the values returned. By reading their code I was able to determine what the dialogs (the prompts presented to the admin during the install process) return, and the simply return that without the dialog occurring.

From the install screen you can switch to a different console (Alt+F1, if I recall correctly), and then access a command line (you may need to use the “unsupported” trick to get the command line).

The install process is actually quite interesting. VMware is booting, via ISOLINUX, into a full ESXi environment (instead of the standard ESXi yellow and black, they display the install dialogs), asking you which disk you want to use, then formatting that disk with VMFS and copying a virutal machine to the new VMFS volume. They then configure the boot partition to start the ESX kernel and start the ESXi management virtual machine. It’s rather interesting (well, to me) what they are able to accomplish because of the power and flexibility having such a small hypervisor affords them. Not to mention the sheer genius of using their own hypervisor to perform the install of itself…simplicity!

Read moreExperimenting with the vSphere ESXi install process

ESXi 4.0 autoinstall

Being, first and foremost, lazy and getting my paychecks for being a system administrator, I felt that the amount of work involved in loading ESXi 4.0 on my blades was entirely too much. I have well over 100 blades, each one needing to have vSphere loaded onto it, configured, and added to vCenter. Even using the directions scattered across the internet about reducing the amount of effort involved in loading vSphere was too much for me.

Others have documented how to PXE boot ESXi elsewhere on the internet, however I wasn’t interested in having a “stateless” install…I merely wanted to automate installing ESXi to the local hard drive. My blades have a single hard drive, a single generation one SSD or two SAS drives in a RAID 1 depending on the vendor, and I simply want the installer to always install to that drive without bothering me. Loading from the “remote media” functionality of the DRAC/iLO for the blades takes forever, so I wanted to be able to install using PXE and push the media over that medium.

So, having been a developer for several years I decided to dive further into the the install process than others had detailed. Turns out that eliminating all input from an administrator to load the operating system was pretty simple.

The end result is that I am able to power on a blade, hit F12 to have it PXE boot and walk away. Some time later, we can use PowerShell and the PowerCLI to find the hosts (they will be somewhere in the DHCP scope of the provisioning LAN), give them a permanent IP and hostname, then configure them and add them to vCenter. By using PXE and the interactionless (yes, I did make up that word) install, I cut the time to load ESXi from about 45 minutes (using the remote media function takes FOREVER!) to less than 10.

Read moreESXi 4.0 autoinstall