I went to install the VMware SDK for vSphere 4.0 on to my desktop running Windows 7 64-bit, Visual Studio 2008, and .Net 3.5 SP1 and discovered the SDK setup is not friendly with these versions. According to VMware you need Visual Studio 2005 and .Net 2.0 if you want to run the SDK.
So like most of you reading this I turned to my trusted adviser…google to find the answer I was looking for. Much to my disappointment after 5 minutes of searching around I didn’t find any instant gratification for my problem so I decided to just go ahead and figure it out on my own.
Last week my boss came to me and asked if I could write a script for a customer to register VM’s after being replicated from once VI environment to another. I agreed to take on the project and go for it.
Like everything I do these days I decided to use powershell to write the script. I have taken a liking to it and the fact that I can run the scripts on both ESX and ESXi hosts saves me from having to re-create scripts all the time. So I plugged away to 3am wrote the script, tested it inside out and sideways in my lab. I was confident in the scripts ability to register all vm’s form all datastores I went ahead and sent it off to the customer.
I hear it time and time again…The full ESX console is going away. ESXi is the way to go. I know there are valid arguments for keeping ESX around, but they are few. Failing USB keys may be a valid argument, but I have not heard of this happening. If that is the case, use boot from SAN. You need SAN anyway. As for hung VM processes, there are a few ways to address this in ESXi.
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.
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.
”
