Templates and their usage are one of the big time savers in ESX. The ability to setup a “perfect” vritual machine and then deploy multiple copies of it allows us to minimise the risk of deployment errors. However, there are a few limits around what can be achieved.

Specifically, in the environment I am in at the moment, there is a requirement for the operating system to be deployed to one LUN and the any application partitons to be deployed to another LUN.

Templates only allow me to deploy the machine’s virtual hard disk to one LUN and not split across two. Hence the problem.

There is no quick fix that I could find; so it was off the scripting land I went.

First things first. The customer required the deployment of twenty seven virtual machines all based off one. The process is prety simple; open my Virtual Infrastructure Client, point it at a Virtual Center (ESX servers by themselves don’t have template functionality), and convert the baseline virtual machine to a template.

I could have chosen to deploy twenty seven virtual machines manually, but, well, I’m lazy. So, the lazy man’s solution? Scripting!

The process was as follows:

1) Remove the 40GB hard drive (cloning and templating doesn’t allow hard drives to be placed in multiple datastores eg. osLUN and appLUN)
2) Create a template of the virtual machine.
3) Install powershell and the Vmware VI Toolkit giving us the powershell for Vmware functionality.
4) Save the following to a .ps1 (Powershell script file):

$array = “Machine1″,”Machine2″,”Machine3″ (and so forth)
$TARGET = “FQDN_OF_TARGET_ESX_SERVER”

Connect-viserver FQDN_OF_VIRTUAL_CENTER

foreach ($vm in $array)
{
$vm=New-VM -Name $vm -Template BASELINE_TEMPLATE -Host $TARGET -Datastore osLUN
}

The above script will connect to the VI Center (it will prompt for username and password) and then create a new machine called “Machine1″ etc. for each machine in the list. It will place the virtual machine on the esx server in $TARGET and build it from the template called BASELINE_TEMPLATE.

Now comes the hard part. There are 27 42GB drives that need to be created for the virtual machines. There is no powershell that will allow this to happen. Therefore, a script is required.

In appLUN is a vmdk called BASELINE_TEMPLATE_VMDK and this is the virtual hard drive (pre partitioned and formatted) that will be used for the virtual machines.

for DESTINATION in machine1 machine2 machine3 machine4 ETC.
do
# Copy
echo “Copying $SOURCE to $DESTINATION”
mkdir $DESTINATION
cp -a $SOURCE/* $DESTINATION/
# Rename vmdk files
cd $DESTINATION
for file in $(ls -1 *.vmdk)
do
echo “Renaming $SOURCE vmdks to $DESTINATION”
DEST=$(echo $file | sed s/$SOURCE/$DESTINATION/g)
mv $file $DEST
done
# Edit .vmdk
for file in $(ls -1 *.vmdk | grep -v flat)
do
echo “Replacing references to $SOURCE in .vmdk file $file”
sed -i s/$SOURCE/$DESTINATION/g $file
done
cd ..
done
echo “Finished”

This will copy the BASELINE_TEMPLATE_VMDK virtual hard drive one time for each virtual machine and make sure it is useable for that machine. It will also go through the .vmdk file and change the reference from BASELINE_TEMPLATE_VMDK to the destination virtual machine name.

Once it is run, we have to manually add the newly created vmdk to the corresponding virtual machine.

Then it is a simple matter of logging into each virtual machine and changing their host names and IP addresses.

There is still a fair bit of manual intervention involved, but at least the boring, tedious bits (deploying the templates and copying the hard drives) has been automated.

If you can offer any other scripts that can complete the picture, let me know!

Guys are hard at work with the labs at the moment here in sunny Hobart, and so I begin trawling the blogs (as is my want). I discovered this brilliant little gem from Mike DiPetrill’s blog.

This post demonstates the awesome power of the Vmware API and the ease of use we get from the VI Toolkit for Windows! The script will move a VM from one ESX host to another, without making use of VMware VMotion. The drawback is that the VM becomes unresponsive for a period of time (usually a few seconds). This is roughly functionally equivalent to Microsoft’s Quick Migration feature, except that this was done in 130 lines of script.