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:
part /boot –fstype=ext3 –size= –onfirstdisk
part storage1 –fstype=vmfs3 –size=30000 –grow –onfirstdisk
part None –fstype=vmkcore –size=100 –onfirstdisk
# Create the vmdk on the cos vmfs partition.
virtualdisk cos –size=8000 –onvmfs=storage1
# Partition the virtual disk.
part / –fstype=ext3 –size=0 –grow –onvirtualdisk=cos
part swap –fstype=swap –size=1600 –onvirtualdisk=cos
How would you like to kick off your ESX installation, then go have some coffee, go for a jog, or just hang out by the water cooler until it is finished without worrying if you’re wasting time while it’s waiting done and waiting for you. Well you can with this ESX email script. Incorporating this script as part of your ESX automated deployment script allows you to configure your server to email you once the post installation configuration is finished.
So what do you need to do? It simple you can get the mail_notify script that I found on yellow-bricks.com from our downloads page. Once you have the script you will need to get it on to your server along with the MIME Lite.pm file that you can download here. Once you download and extract the package you can find the Lite.pm file under /lib/MIME/ folder.
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.
I had a conversation with some colleagues of mine about ESX local disk partitioning and some interesting questions were raised.
How many are creating local vmfs storage on their ESX servers?
How many actually use that local vmfs storage?
Typically it is frowned upon to store vm’s on local vmfs because you loose the advances features of ESX such as vMotion, DRS, and HA. So if you don’t run vm’s from the local vmfs, then why create it? Creating this local datastore promotes it’s use just by being there. If you’re short on SAN space and need to deploy a vm and can’t wait for the SAN admins to present you more storage, what do you do? I’m sure more frequently than not you deploy to the local storage to fill the need for the vm. I’m also sure that those at least 20% of the time those vm’s continue to live there.
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. In this example I am deploying VMware ESX 3.5 Update 4 in VMware Workstation 6.5 build 126130.
In this series I am going to walk you through setting up the Ultimate Deployment Appliance (UDA) and VMware Workstation 6.5 to test Automated ESX Deployment Scripts (kickstart). The same principals that you will learn in this video also apply to using the UDA in a physical environment. The UDA is a very powerful appliance and I have found many uses for it. Using it as a medium to quickly and effectively test deployment scripts that I develop is just one.
Even in environments where the UDA is not allowed it can still be utilized. I regularly carry a 5 port gigabit switch which I can use to connect to my laptop to up to (4) servers to quickly deploy up to (4) ESX hosts at a time.
Originally I was going to cover all the various options for initiating your automated kickstart installation as “Automated Deployment of ESX Hosts Part IV”, but I have since decided to cover each method individually as there is a lot to cover and it makes more sense to break them out.
In this post I am going to cover deploying your servers over the network utilizing HTTP. To begin you will need a few things in place for this to work. Below is a list of what you will need: Read more…
This script is very similar to ESX 3.x Deployment Script #1, but I made a handy change. I built this script to allow for easier modification for each ESX host you want to deploy. Once you change all the settings you need changed there is one important area where you will add information about all your ESX hosts.
Below if the area that you will need to be concerned with:
if [\'hostname -s\' == "esxhost1" ] ; then
esxcfg-vswif -i [Service_Console_IP] -n [Service_Console_Netmask] vswif0
esxcfg-vmknic -a -i [VMKernel_IP] -n [VMKernel_Netmask] "vMotion"
fi
You will create this if statement for each of your esxhosts you want to deploy. Once you setup each servers information in this area all you need to do is change the hostname to match the server you are deploying and that is it. If you use dhcp to set the initial installation IP and it is able to resolve to the appropriate hostname then you won’t even have to change the script.
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.
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.
