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.
Back in the summer, I saw Stu’s Post about automating the installation of ESXi. I was reminded again by Duncan’s Post. Then, I found myself in a situation when a customer bought 160 blades for VMware ESXi. With this many systems, it would be almost impossible to do this without mistakes. I took the ideas from Stu and Duncan and created an ESXi automated installer that works from a PXE deployment server, like the Ultimate Deployment Appliance. I took it a step further and added the ability to use a USB stick or a CD for those times when PXE is not allowed. The document below is a result of it.
This is a little different than the idea of a stateless ESXi server, where the hypervisor actually boots from PXE. This is the installer booting from PXE so that the hypervisor can be installed on local disk, an internal USB stick or SD card. You could also use it for a “boot from SAN” situation, but extreme care should be taken so you don’t accidentally format a VMFS disk.
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.
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.
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.
”
