I’ve been getting asked a lot of question on how to execute scripts within Linux Guest Systems using vCAC. There are a few components to executing scripts in a Linux Guest OS which I’m going to cover in this post. Those items are:
Linux Guest Agent
Linux Guest Agent
The Linux guest agent has a number of feature benefits that you receive if you utilize it. The Linux guest agent is a small agent that acts very similarly to the vCAC proxy agents. When it is installed you give it the name or IP address of the vCAC server. This allows it to check in with the server when it loads on a newly provisioned machine and determine if there is anything it needs to do. If the vCAC server has work for it to do it send the instructions and the agent executes the instructions on the local guest operating system. The guest agent comes with a number of pre-built scripts and functions, but also allows you to execute your own scripts. Some of the features available with the Linux Guest Agent are:
Disk Operations – Partition, Format, and mount disk that is added to the machine.
Execute Scripts – Execute scripts after the machine is provisioned.
Network Operations – Configure setting for additional network interfaces added to the machine.
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.
It turned out to be a relatively easy task once I discovered what was causing my issues. There are two windows cmd scripts that need to be edited to point to the proper locations of your installations. I have included the modified cmd files in our downloads section for those of you that would like them. These files are built to support my specific configuration but they are very easily edited to support your configuration.
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.
A few days later I was on a conference call with the customer. They were having problems with the script. It wasn’t registering all the vm’s. After a few hours of troubleshooting I realized that I needed to go back and try to recreate the problem’s in my lab to fix the script, but the customer didn’t have that kind of time.
A short while after getting off the meeting with the customer I received an email from them stating not to worry they had gotten a shell script that worked. Then I started to think……. I went in to my lab and created a shell script that would do the job. The shell script was 5 lines long as oppose to powershell script that is about 40 lines.
The shell script if anyone needs it looks like this:
for v in ‘find /vmfs/volumes/ -name “*.vmx” ` do echo “Registering $v” >> /log/registeredvms.log vmware-cmd -s register $v done
So the short of the story is sometimes it is best to keep it simple stupid. Utilizing powershell for this problem was just too much overkill and in the end there were issues that were overlooked that I still can’t reproduce in my lab. A simple shell script is all that was required and what I should have originally decided on.
So in the end this is a lesson learned and hopefully it will prevent someone else from making the same mistake.
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.
If the techie wonks at VMware are publishing articles about how to transition to ESXi, then resistance is futile…you WILL be assimilated…
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 email@example.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.
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.
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.
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.
Create a custom installation CD with all the necessary files located on the CD.
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.
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.
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.