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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.