Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There are a number of ways to deploy/install ESX; RDP/PXE, from CD, remote ISO boot etc.

What's your favourite method and why?

share|improve this question
How many do you need to deploy? (I have to ask, professional curiosity/envy.) – Joseph Kern Jun 18 '09 at 20:33
Oh we do a few hundred a year via HP RDP but I'm interested in others situations. – Chopper3 Jun 18 '09 at 20:42
up vote 7 down vote accepted

kickstart with pxe. That's also the direction you'll get directed to in their training courses. For the install it's little more than a redhat install with some extras, so kickstart is the way to do it. This makes more sense when you're building a cluster and want identical installs.

share|improve this answer
Absolutely kickstart and PXE is the way to go. For extra convenience use the VMware Deployment Appliance. Drop it into a VMware Workstation or another ESX host if you have one, test a few builds, tweak the scripts and then roll out to as many ESX servers as you need. In addition to getting a higher level of consistency in your V3.5 configs you also have a reliable easy rebuild process. It's possibly not worth the effort when you're only building a handful but if you're setting up any decent size of cluster it will save you a lot of repetitive, error-prone, manual configuration. – Helvick Jun 18 '09 at 21:51

One at a time. From CD.

I like this method, because the only person I can blame is myself. I have an install document that was created when the first server was deployed. Do it once, double check, do it right.

Of course ... I only have 4.

Scaling beyond this mere handful, I would probably start with PXE. Deploying over the network is much easier and reliable than doing it by hand.

share|improve this answer
I'm not going to vote you down, but structured is almost always better than by-hand. People make mistakes. Scripts make mistakes reliably ;-) – Matt Simmons Jun 19 '09 at 1:51
People do make mistakes, that's why there's documentation ... is it really worth creating a scripted install for < 5 servers? – Joseph Kern Jun 19 '09 at 9:14
That being said ... I just upvoted the kickstart answer. – Joseph Kern Jun 19 '09 at 9:15
I'd argue that it's worth creating a scripted install even for one server. It makes sense to me to distil knowledge into scripts - that one server may need reinstalling one day. – Jon Topper Jul 6 '09 at 15:02

I have a couple of basic system images (VM disks) which I clone as necessary to create new VMs. I keep these base images up to date by firing them up every once in a while and getting patches. I've done cloning both by using the VMWare vCenter Converter and just copying the raw files into a new directory and updating the .vmx files. Turn on the clone, rename the host and update the IP, and I've got a ready-to-go brand new server. I have about a dozen VMs running on two servers right now using this method.

share|improve this answer

Being that it takes about as much time to install ESX as it takes to take the server out of the box, I go CD.

99% of the time when you need to install ESX you're standing beside the physical machine anyway. Pop the CD in and go and skip the network drama.

share|improve this answer

We prefer to SAN boot ESX servers in our environment whenever possible. Instant clones and snapshots make each ESX server very easy to deploy and back-up / migrate. Obviously there are additional costs involved, since an HBA (FC or iSCSI) is required - or you can use an unsupported software solution like the iSCSI software initiator or gPXE. In the cases where we use local disk, the PXE / Kickstart method works great.

share|improve this answer

Depends on where the servers live.

As with most everyone else, PXE booting/install is by far my first choice (and is absolutely trivial with ESXi).

In some cases, PXE booting is not appropriate or available (think secure DMZ's). In this case, installing using the server's out-of-band Lights Out Management CD redirection functionality means I can do it from my desk without hanging out in the datacenter or needing to reconfigure one of the host's switch ports to a more netboot-friendly network.

As for host configuration, configuration can be scripted using the v(I)MA toolkit or virtual appliance, although these tools have some functional limitations. vSphere (ESX4) makes this even easier if you have licenses which include the Host Profiles functionality (configure one host correctly, define it as your host profile configuration source, apply config to all other hosts in the cluster. It will check daily to make sure the hosts are still compliant with their "golden" configuration).

Note that not all configuration can be scripted via v(I)MA or be managed under Host Profiles; some manual processes are required to complete host configuration due to some configuration options not being available through these tools. In this case, a written procedure or checklist will ensure you don't miss anything.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.