Everyone at this point should be aware that the Service Console is now
located in a vmdk on a VMFS partition. The Service Console vmdk must
be stored on a vmfs datastore and the datastore must either be local
stoage or SAN storage that is only presented to the one host. So I
guess no shared vmfs datastores to house all the Service
Consoles....... The next question I had about the new service console
was the /boot partition. Where is it and how is the server
bootstrapping? Well I can't say I have totally gotten to the bottom of
this yet but I have discovered a few things. When digging into
scripting installations of vSphere I first looked at the disk
partitioning which sheds a little light on the boot process. Here is
what the disk partitioning portion of the script looks like:

Read more of this post here.

I have been asked this question a few times so I thought it would be wise to post an article on it. When deploying an automated build script with the kickstart and/or installation files located on http, ftp, or nfs there are network configuration dependencies that you need to be aware of.

The ESX installer is a modified version of anaconda which is the same installer used for RedHat and a few or Linux variants. Anaconda is what allows for the kickstart portion of the automated build script. Anaconda itself has some limitations as far as what it supports.

Read more of this post

In Part 2 of this series we are going to deploy our virtual ESX host in a VMware Workstation 6.5 virtual machine. We will utilize the UDA setup that we created in the first part to this series. If you haven't setup your UDA you will want to do so before proceeding. Make sure you check out the sample deployment scripts available on our download page.

Watch the video tutorial here!

This is Part III of a multi-part blog. If you haven't read Part I or II I recommend that you do before continuing.

In Part II we developed a standard build for our hosts that we are going to use to build our automated build script. Keep in mind the information I provided in my standard build is not all inclusive and is limited for the demostration of building the script.

First we will start with the kickstart portion of the script. The kickstart is what configures the basic part of the installation that you would normally do manually from the CD. The ESX 3.5 kickstart is a modified version of anaconda.

In the begining of our script we have the Regional Settings that we need to set. Below are the regional settings for my installation.

Read more of this post

A very important part of deploying your Virtual Infrastructure environment is consistency when it comes to the configuration of the ESX hosts. Time and time again as common practice I see users deploying ESX hosts manually with no documentation to follow other than what they have in their heads. Deploying ESX hosts in this fashion can lead to inconsistent configurations between hosts. Choosing manual installations over scripted installations can lead to all sorts of problems some of which can be very difficult to diagnose.

There is a very common misconception that scripted installations are difficult or not worth the time and effort to create. This couldn't be farther from the truth. Utilizing scripted installations can save countless hours of time spent manually installing ESX and troubleshooting problems from inconsistent manual installs. This is part I of a multi-part blog in which I am going to walk you through the different options that are available with scripted installations. I am also going to share with you some sample scripts and methods to streamline the testing of scripts you develop. Before we begin to develop a script we need to know what our "standard" configuration is going to be. Without having a standard configuration we don't know what we need to configure. It's important to develop a standard configuration for your environment. If you have multiple clusters in your environment your standard configuration may have minor changes from cluster to cluster but should ultimately be consistent across the environment to make troubleshooting and maintenance much simpler.

Read more of this post