ESX automated deployment email completion notification

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.

The take the Lite.pm file and the mail_notify.pl file and tar them together for easy retrieval. Then upload the mail_notify.tar file to your web server. Next include the following in your automated deployment script.

##### Setting up Mail Notification ########
echo Setting up mail notification
echo Setting up mail notification >> /var/log/post_install.log

cd /tmp
lwp-download http://[server ip]/path/mail_notify.tar
tar xvf mail_notify.tar
mkdir /usr/lib/perl5/5.8.0/MIME
mv Lite.pm /usr/lib/perl5/5.8.0/MIME/

##### Move the files to where they belong #######
mv mail_notify.pl /usr/local/bin/
chmod +x /usr/local/bin/mail_notify.pl

####### Let’s send an email that the install is finished #####
/usr/local/bin/mail_notify.pl -t youremail@yourdomain.com -s “Server installation complete” -a /var/log/post_install.log -m “Server Installation complete please review the attached log file to verify your server installed correctly” -r [your smtp server]

Optionally you could set the smtp server in the mail_notify.pl script and not have to specify when sending a mail message.

if you include this at the end of your post installation portion part of your script but before the EOF line you will get a nice email notification informing you that your installation has finished with the post_install.log file attached.

Network configuration for automated ESX deployment

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.

Anaconda does not support 802.1q VLAN tagging. If you plan on tagging the service console network traffic this will affect your kickstart installation. The anaconda installer will not tag the vlan id to the traffic and therefor will not be able to perform the installation. You have a few options on how to handle this.

  1. Don’t have the networking folks tag the vlan until after the install finished.  However this can cause problems if your post installation script needs to grab some files from across the network so be aware of what you are doing during your post installation.
  2. Use a dedicated deployment network.  If you use this option take a look at my ESX 3.x Deployment script #2 located on our download page.
  3. Don’t tag the service console traffic.  If you share vSwitch0 with both the vmkernel(vMotion) interface and the service console only tag the vmkernel traffic.  This still allows for isolation of the traffic.  Have your network guys set the service console vlan as the native(untagged)vlan.
  4. Create a custom installation CD with all the necessary files located on the CD.

ESX local disk partitioning

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.

Is the answer to not utilize local vmfs storage? If you don’t what do you do with the left over space? Not all servers are created equal, sometimes servers have different size local drives so you have a few options. Do you create standards for your partitioning and set a partition such as / to grow and have varying configurations amongst your hosts? Or do you create a standard for all partition sizes and leave the rest of the space raw?

Typically this is the partition scheme I use for all deployments I do.

Boot = 250 (Primary)
Swap = 1600 (Primary)
/ = Fill (Primary)
/var = 4096 (Extended)
/opt = 4096 (Extended)
/tmp =4096 (Extended)
/home =4096 (Extended)
vmkcore = 100 (Extended)

This configuration will create inconsistencies amongst hosts with varying drive sizes. To maintain consistency I could do something like the following and leave the rest of the space raw.

Boot = 250 (Primary)
Swap = 1600 (Primary)
/ = 8192 (Primary)
/var = 4096 (Extended)
/opt = 4096 (Extended)
/tmp =4096 (Extended)
/home =4096 (Extended)
vmkcore = 100 (Extended)

I’m a fan for utilizing all the space you have available, but others like consistency. What is your preference? Weight in an let us know.

ESX vs. ESXi which is better?

So the question is which is better VMware ESX or VMware ESXi. A lot of die hard Linux fans will always say VMware ESX because of there attachment to the service console. The service is a great tool and once upon a time it served it’s purpose. Today there are many other options available to manage your VMware ESX servers without the service console. There is the Remote CLI, the VI ToolKit for Windows (powershell), and last but not least the VIMA.

With these tools you can effectively create scripts to help manage your VMware ESX environment without the service console. The service console opens up an additional security risks for each and every VMware ESX host you have deployed. Mitigating this risk increases the management overhead involved in the maintaining and deployment of these server in your environment. VMware ESX also consumes more server resources than VMware ESXi. The service console in VMware ESX uses CPU cycles and memory that you could be utilizing for virtual machines on VMware ESXi.

As far as feature and functionality VMware ESX and VMware ESXi are equals. They both support all of the Enterprise feature available as part of VI3. There are some add-on products that require the use of VMware ESX such as Lab manager and Stage Manager but hopefully they as well will be ported to VMware ESXi. You can find the VMware ESX and ESXi comparison here.

A growing number of servers are available from all major vendors that have support for embedded VMware ESXi. If you have one of these servers their are even greater benefits to running VMware ESXi. With these their is no need for internal or SAN storage for your boot partitions. Eliminating internal storage is a great way to go green. The average coast of a 73Gb 15K SAS drive is $400.00. Typically you would have (2) for redundancy adding an average of $800.00 to the cost of each server. The estimated annual cost to run a single SAS drive is $23.00 rounded making it $46.00 per server per year. This does no include the additional cooling capacity needed for the heat produce from the drives.

If you have 40 VMware ESX server running in your environment you can save $32,000 in the acquisition of hard disks and $1,840 per year in energy costs, not to mention the benefits to the environment from the reduction in your carbon footprint and well as the reduced maintenance costs. I don’t have any figures on this but there will most definitely a savings in the overall administration effort required to support VMware ESXi vs. VMware ESX. The sheer need to lock done the service console and keep it secured is pretty demanding task.

I regularly hear “We are waiting on VMware ESXi” and when I ask why I never hear a thought out valid answer. I would like to hear your opinion on this topic. Please leave comments as to your views on VMware ESX vs. VMware ESXi I would like to gain some greater insight into why more organizations are not making the switch.

Using the Ultimate Deployment Appliance to test ESX kickstart scripts – Part II

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.



Using the Ultimate Deployment Appliance to test ESX kickstart scripts – Part I

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.



Deploying Automted Kickstart Scripts Over HTTP

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:

  • Web Server to hosts the kickstart files and optionally your ESX installation.
  • ESX Installation media or ISO’s for all versions of ESX you plan to deploy
  • Your kickstart script

The first thing we need to do is setup our web server so we can host our kickstart files and optionally our installation files.  You can utilize apache, IIS, or whatever your favorite web server is for hosting HTTP.  You will need to configure a folder under your web server root for the files to be stored.  Below is my recommended structure.

-webroot
—deployment
——ESX35U1
——ESX35U2
——ESX35U3
——ESX35U4
——kickstart

Once the folder structure is created we need to copy the contents of the installation media to the respective folder. To do this you will literally copy everything on the CD and place it in the folder. Then next you will need to copy your kickstart.cfg files to the kickstart folder.

Once you have all the files uploaded to the web server it is a good idea to use your web browser to test that you are able to access them.

As part of our kickstart we define where we are going to be installing from with the following line replacing server_IP with your server IP address and ESX25U4 with the version you would like to install.

url –url http://server_IP/deployment/ESX35U4

If you wanted to pull just your kickstart.cfg files form the http server but install from the local CD media you would replace the above string with “cdrom” to let the kickstart know to look to the cdrom drive for the installation media.

Now that we have our web server up, our installation copied to our webserver, and our kickstart.cfg files on the server we can kick off our kickstart installation.

To do this we need to boot the server from the installation CD. You can boot from the CD in the cdrom drive or remote mounted over a lights out port like iLo, DRAC, or RSA. If you are going to remote mount the CD over a lights out connection you can use a much smaller portion of the ESX CD.

On your ESX installation media there is an iso file named boot.iso located under the “images” folder on the CD. You can extract that ISO image which is roughly 4mb and remote mount that to your server for the boot process if you intend to install over HTTP.

OK so now we boot off of our media either the full ESX CD or the boot.iso image and when the ESX installation screen appears we need to tell the installation where to find the kickstart file. There are a couple of options for this which are below:

If you are using dhcp then your installation string will look similar to the below string:

esx append ip=dhcp ksdevice=eth0 network ks=http://server_name/deployment/kickstart/kickstart.cfg

If you are not using dhcp it would like similar to the follow string:

esx append ip=192.168.1.2 netmask=255.255.255.0 gateway=192.168.1.1 ksdevice=eth0 network ks=http://Server_IP/deployment/kickstart/kickstart.cfg

The statement ksdevice=eth0 tells anaconda (the installer) to use the eth0 interface for the install. I recommend always using eth0 for your installs. ESX will by default make the install interface the Service Console interface. So it will become the interface that is assigned to vSwitch0.

If you are using a seperate kickstart file for each server then you can call each one by name. If you are using a script like the one I discuss here then you will only need to have one kickstart file.

ESX 3.x Deployment Script # 3

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.

For example if you change this line:

network --device eth0 --bootproto static --ip [SC IP ADDRESS] --netmask [SC NETMASK] --gateway [SC GATEWAY] --nameserver [NAMESERVERS comma serperated] --hostname [HOSTNAME] --addvmportgroup=0

to the following:

network --device eth0 --bootproto dhcp

and then add the following setting the appropriate IP addresses and hostnames:

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

if ['hostname -s' == "esxhost2" ] ; then
esxcfg-vswif -i [Service_Console_IP] -n [Service_Console_Netmask] vswif0
esxcfg-vmknic -a -i [VMKernel_IP] -n [VMKernel_Netmask] "vMotion"
fi

and you setup each ESX server in dhcp and DNS you will never need to modify this script. You need to ensure that the DNS and gateway that the server initially get’s from DHCP are correct. If you are doing this on a different subnet then what you will be running your ESX server on then you will need to do this a little differently. This can be done with my ESX 3.x Deployment Script #2.

I have included a script with this code included in our download section.

VI Toolkit powershell simple script #4 – VM Information

This is a good powershell script for tacking virtual machine inforamtion for change management. It will output the vm’s name, the host it is on, the powerstate, Memory, Number of CPU’s, IP address, and FQDN to a csv file.


$IPprop = @{ Name = "IP Address"; Expression = { $_.Guest.IpAddress } }
$HostNameProp = @{ Name = "Hostname"; Expression = { $_.Guest.Hostname } }
Get-VM | select name, host, powerstate, MemoryMB, numCPU, $IPprop, $HostNameProp | export-csv c:vm_info.csv

Fixed: VMware Tools status shows as not running after running VMware Consolidated Backup

A while back I mentioned that VMware Tools would appear to change to a not running status after a VCB Snapshot was taken. Vmware said a fix would be forthcoming in ESX U4. VMegalodon posted on the communities this morning that he is running VC 2.5U3 and ESX 3.5 U4 (Which is probably a bad combination…) and the VMware Tools issue appears to be corrected.

So, what are you waiting for?? Get to upgrading!

Thanks VMegalodon!