Thursday, February 28, 2013

How To Quickly Get Started With The New VMware Puppet Modules

Yesterday, VMware Automation gurus Nick Weaver and Nan Liu just announced the release of four awesome new VMware Puppet modules that can help you manage and configure vCenter Server (including ESXi) and vCloud Networking & Security (vShield). You can read all about the details here and here and if you were lucky enough to have attended PEX (Partner Exchange) you might even have caught the demo given by Nick in his session.

I have used Puppet in the past, but it was pretty limited and specifically in How to Deploy ESXi 5 Using Razor & Puppet. I thought this might be a good time to revisit Puppet and try out the new VMware Puppet modules. I took a look at some of the examples provided by Nan on his blog but for new users to Puppet, it may not provide enough details to quickly get started (including myself). I thought I document the minimal steps I took to quickly get started (I also ran into a few bugs which Nan has fixed).

Step 1 - Install Ubuntu Precise (Ubuntu Server 12.04 LTS - See more at: http://www.virtuallyghetto.com/2012/05/how-to-deploy-esxi-5-using-razor-puppet.html#sthash.c3anJPam.dpuf
Step 1 - Install Ubuntu Precise (Ubuntu Server 12.04 LTS). You can use other distros, I just choose Ubuntu as I had the image lying around.

Step 2 - Download Puppet Labs package repository by running the following commands:
wget http://apt.puppetlabs.com/puppetlabs-release-$(lsb_release -c | cut -f 2).deb
dpkg -i puppetlabs-release-$(lsb_release -c | cut -f 2).deb
apt-get update
Step 3 - Install all the necessary packages such as Ruby, Ruby Gems, Puppet, etc. by running the following commands:
apt-get install -y libxslt-dev libxml2-dev ruby rubygems puppet
gem install nokogiri
gem install net-ssh
Step 4 - Install the VMware Puppet modules by running the following command:
puppet module install vmware/vcsa
puppet module install vmware/vcenter
puppet module install vmware/vshield
To start using the VMware Puppet modules, you will need to create what's known as a manifest file that contains the resources which maps to the actions you wish to perform (e.g. configure a newly deployed VCSA appliance or create a Cluster in vCenter Server and add an ESXi host to that cluster). You can find a bunch of example manifest files in each of the Puppet modules, here is the path to each:
/etc/puppet/modules/vcsa/tests/
/etc/puppet/modules/vcenter/tests/
/etc/puppet/modules/vshield/tests/
You will see in some of the examples, they import a file in each directory called data.pp which contains the actual definitions of your VCSA, vCNS and ESXi hosts but you can also just specify that in the main manifest file as well for simplicity. The latter option provides more flexibility as you can easily reference various configurations for different environments. For your convenience, I have created the following manifest files that you can use and you just need to modify them to fit your environment.
Here is what my lab environment looks like and their respective IP Addresses for your reference (these must already be deployed and vCenter & vCNS does not need to be configured but just accessible over network):
vCenter Server = 172.30.0.135
vCloud Networking and Security = 172.30.0.136
ESXi Host = 172.30.0.137
Step 5 - As mentioned by Nan, a custom Rbvmomi was used and we will need to ensure our Puppet management host (Ubuntu system we are on) includes it. To ensure all the necessary packages are downloaded for us, we will use the rbvmomi.pp manifest file for our host and use Puppet to apply the policy. Replace management_server in rbvmomi.pp with the hostname or IP Address of your Ubuntu host and then run the following command:
puppet apply rbvmomi.pp
Note:  You can safely ignore the red warnings, it must not have liked something in my environment.

Step 6 - We will start off by configuring the VCSA so we can then perform operations such as adding in Datacenters, Clusters, ESXi hosts, etc. We will use the configure-vcsa.pp manifest file by running the following command:
puppet apply configure-vcsa.pp
Step 7 - Next we will create a Datacenter, Cluster and add our ESXi host by using the setup-vcenter.pp manifest file by running the following command:
puppet apply setup-vcenter.pp
Step 8 - We are now onto configuring vCloud Networking and Security and we will also associate it with our vCenter Server by using the configure-vcns.pp manifest file and running the following command:
puppet apply configure-vcns.pp
Step 9 - After configuring vCloud Networking and Security, we can now deploy a vCloud Networking and Security Edge Gateway to provide various networking services to our vSphere environment using the deploy-edge.pp and by running the following command:
puppet apply deploy-edge.pp

In about 5-10 minutes, you will have a fully configured vSphere environment that contains your vCenter Server, vCloud Networking and Security Manager and Edge Gateway and ESXi hosts all ready to start providing compute and networking services for your virtual machines and applications! I want to stress the above is a very simplistic example of what you can do with the new VMware Puppet modules. There are definitely more advanced capabilities provided in the modules and I would recommend you take a look in the samples directory of each module for more details. 
Overall, I was pretty impressed with the VMware integration that Nick, Nan and team built with Puppet. This was a great learning experience for myself, I learned quite a bit with just trying out these modules and I think I might have found a reason to dive more into Puppet! :)

Big thanks to Nan for helping me out with some of my Puppet questions! 
How to Deploy ESXi 5 Using Razor & Puppet
How to Deploy ESXi 5 Using Razor & Puppet
How to Deploy ESXi 5 Using Razor & Puppet
How to Deploy ESXi 5 Using Razor & Puppet
How to Deploy ESXi 5 Using Razor & Puppet
How to Deploy ESXi 5 Using Razor & Puppet
How to Deploy ESXi 5 Using Razor & Puppet
How to Deploy ESXi 5 Using Razor & Puppet
How to Deploy ESXi 5 Using Razor & Puppet
How to Deploy ESXi 5 Using Razor & Puppet
How to Deploy ESXi 5 Using Razor & Puppet

Tuesday, February 26, 2013

How To Run The SilverLining Fling Without Installing It In vCloud Director

A few weeks back the VMware Lab's team released a cool new fling called SilverLining which allows users to build a simplified user-interface for vCloud Director. This interface can be run from any modern web-browser that supports HTML5, CSS3 and Javascript. To access the SilverLining interface, you must first install it on a vCloud Director 5.1 Cell.
From a development or proof of concept perspective, it would be really nice to be able to run SilverLining locally from your desktop and point it to a valid vCloud Director 5.1 instance for testing. Well, this is exactly what Andrea Siviero, a Consulting Architect for VMware discovered while playing around with the SilverLining Fling.

UPDATE: 2/28 - For Safari, you can use open /Applications/Safari.app/ --args -disable-web-security

Disclaimer: The solution described here is specifically for Chrome running on Mac OS X or Windows. I have not looked into equivalent settings for other browsers.

Here are the steps required to make this work:

Step 1 - Download SilverLining and extract the contents to your local desktop

Step 2 - Under Silverlining->js directory, there is a file called main.js that needs to be modified. Add the following right under "$(document).ready(function() {" which should point to the base URL of your vCloud Director instance:
localStorage.server = "https://vcd.primp-industries.com";
Step 3 - Launch Chrome with the additional argument via the command-line and load the index.html in the SilverLining directory:
open /Applications/Google\ Chrome.app/ --args -disable-web-security
Note: For Windows version of Chrome just pass in the following either via command-line or shortcut to Chrome.exe -disable-web-security

If everything was successful, you should be able to login to the vCloud Organization of your choice and see all the vApps and Catalogs you have access to!

If you receive the "You are attempting to connect to a system no longer supported" shown in the screenshot below:
You may be pointing to a vCloud Director instance that is using a self-signed certificate and you will need to trust the site before proceeding. To do so, open up a new tab and enter the following URL (substituting your vCloud Director URL):
https://vcd.primip-industries.com/api/versions
Click on the "Proceed Anyway" and then reload the index.html page and you should now be able to login to vCloud Director.

I would like to thank Andrea for sharing this awesome tip! Now you can easily develop and test your own custom interface using the Javascript SDK provided by SilverLining all on your desktop. Best of all, you can now point this to any remote vCloud Director 5.1 instance whether that be private or public!

Monday, February 25, 2013

Exploring the vCloud Networking & Security API Using Ruby

In my previous article I demonstrated how you can easily use Ruby and the HTTParty Gem to access the vCloud API. As mentioned at the end of the article I also performed a similar exercise for the vCloud Networking and Security API and here is the sample Ruby script I reated called vcns.rb

Before getting started, you will need to have the following installed on your system:
You will also need to access to a vCloud Networking and Security 5.x environment to use this script.  To begin, create a file called config-vcns.yml which contains the credentials to your vCNS system and will be used to login. Here is what the file should look like the following:
:username: admin
:password: default
:site: https://vcns.primp-industries.com
The script provides the following output:
  • vCNS Configuration
  • vCNS Edge Gateway(s) Details
  • Syslog Service Details
  • HA Service Details
  • Firewall Service Details
  • DNS Service Details
  • SSL-VPN Service Details
  • IPSec Service Details
  • DHCP Service Details
  • NAT Service Details
  • Load Balancer Service Details

Here is a screenshot of running the vcns.rb script:
As you can see, you can easily implement any of the features provide from the vCloud Networking and Security API, with some basic knowledge of how the API works (of course the documentation examples help too!). To further demonstrate this, I thought for kicks and giggles, I would take a part of the script and apply it to another language, this time using PowerShell (yep, you heard right!).

Luckily, it turns out my colleague Alan Renouf already wrote an awesome little PowerShell module for vShield (vCNS) awhile back. With some knowledge of the vCNS API, it was trivial to add a new command called get-vShieldEdge which Alan did not have that would list all the vCNS Edge Gateways that have been deployed. 

Here is what the the code looks like in Ruby:
Here is what the code looks like for PowerShell:
Minus the language syntax, it looks pretty similar right? Both Ruby and PowerShell are accessing the same vCNS API. As long as you know how the API works, it is pretty easy to switch between programming/scripting languages.

To show the above code works, here is screenshot using the new get-vShieldEdge command:
If you are interested in further automation of vCNS, I would highly recommend you take a look at the vCloud Networking and Security API Programming Guide.

Useful Resources:

Thursday, February 21, 2013

Exploring the vCloud API Using Ruby

While working on something that was completely random, I started to play around a bit with the Ruby programming language. I had a few questions and I reached out to a buddy of mine who is Ruby developer and in doing so I was introduced to a very cool Ruby gem called HTTParty. For those of you who are not familiar with Ruby gems, it is a packaged library or application for Ruby, similar to an rpm or pkg file. The neat thing about HTTParty is that it makes working with REST APIs extremely easy and processing XML request/responses into Ruby objects without too much effort.

With the bit of knowledge I gained from my buddy, I wanted to see how easy it would be to apply this to the vCloud API using Ruby and HTTParty. To my surprise, it was actually pretty easy!

Disclaimer: I am not a developer nor even a Ruby novice. This is probably the second or third time I have used Ruby.

Before getting started, you will need to have the following installed on your system:
The following vCloud APIs are implemented in the sample below:
To demonstrate the use of Ruby & HTTParty, I created a very simple Ruby script called vcd.rb which primarily deals with vApp operations.


To use the script, you will need to create a file called config-vcd.yml which contains the credentials to your vCloud Director instance. Here is what the file should look like:
:username: administrator@system
:password: supersecretpassword
:site: https://vcd.primp-industries.com
Note: This example assumes you are running vCloud Director 5.1 (but sample can be modified to support 1.5)

Here is an example of listing all vApps for the given Organization you are logging into:
Here is an example of listing a specific vApp:
Here is an example of performing several operations on the vApp:
At the end of this little exercise, I was pretty impressed at how easy it was to work with REST APIs using Ruby and HTTParty. I think the toughest part for me personally was getting used to Ruby's syntax which I was not familiar with. I also extended this exercise to the vCloud Networking and Security REST APIs which I will share in another blog post.

Useful Resources:

Tuesday, February 19, 2013

Why Are There Two VMX Files?

Have you noticed that for a powered on virtual machine in vSphere 5.1, there is now an additional VMX file that ends with an ~ (tilde) found within the virtual machine's configuration directory?
This was an observation that was made by a few folks and some thought it might be related to a virtual machine's lock file which is created when a virtual machine is powered on. After a bit of research, it turns out this extra VMX file is not a lock file but actually an "edit file". This edit file is a copy of the original VMX file and when changes are required, they are applied to the edit file first. Once the changes are complete, the edit file is then atomically swapped with the original VMX file which helps prevent potential VMX file corruption. In the worst case event where the original VMX file is somehow corrupted, the virtual machine can be restored using the edit file.

This is another reason why you should not be manually editing a virtual machine's VMX file, especially when it is still powered on. For any VMX configuration changes, you should be automating using the vSphere API through the use of either PowerCLI or the vSphere SDK for Perl. For more information on automating advanced settings across your virtual machines, please take a look at this article.

Sunday, February 17, 2013

Automating VCSA Network Configurations For Greenfield Deployments

If you deploy the VCSA (vCenter Server Appliance) or other virtual appliances directly onto an ESXi host,
you will notice the network configuration wizard for the virtual appliance is not available as you would expect when deploying to a vCenter Server.
The reason for this is that ESXi does not support some of the advanced OVF/OVA properties such as the Networking section and you will need to deploy the OVF/OVA to a vCenter Server to be able to configure these advanced options. This poses a problem if you need to deploy the VCSA in a greenfield environment where you will not have an existing vCenter Server running and you will be deploying directly to the ESXi host. Unless you have a DHCP enabled network, you will most likely need to manually go into the vSphere C# Client to change the network configuration as it was unable to obtain an IP Address.
Though this is a one time configuration, it is still not ideal and would require the use of a Windows system to access the vSphere C# Client. You can actually get around this by leveraging the GuestOperations API (previously known as VIX API) which allows you to perform operations within the guestOS that is running VMware Tools. The other nice thing about the GuestOperations API is that it does not require any network connectivity from the virtual machine.

Note: The GuestOperations API can be accessed in variety of ways and in this article I am demonstrating just two methods and does not require a Windows system. You can also access the GuestOperations API using PowerCLI if you are more comfortable with Windows and do not wish to use the vSphere C# Client to manually configure the network settings for the VCSA. I would also like to stress that though this article is about the VCSA, you can easily apply this to any VMware based virtual appliance or virtual appliance running VMware Tools.

The most important thing to identity before using the GuestOperations API is the specific command or program you wish to invoke and the argument it accepts. To configure the network configuration for the VCSA or any other VMware based virtual appliance, you would use /opt/vmware/share/vami/vami_set_network If you just run this command by itself, there are variety of options from IPv4 to IPv6, static or dhcp configuration. In our example, we will be configuring a Static IPv4 address for our VCSA and the command we would run is the following:
/opt/vmware/share/vami/vami_set_network "eth0 STATICV4 192.168.1.150 255.255.255.0 192.168.1.1"

Method 1 - Using RVC (Ruby vSphere Console)

 

RVC is a nice open-source tool for interactively managing and configuring your vSphere infrastructure. RVC can be installed on any platform, in this example, I am running RVC on my Apple OS X laptop.

Step 1 - We first need to deploy the VCSA OVA and we can do so by using the ovftool via the command-line which can also be installed on Mac OS X system.
Step 2 - We then login to our ESXi host using RVC.
Step 3 - Next we will need to "change directory" to the location of our VM, in this example my VCSA is called VCSA-5.1. We can then run the "info ." command to view the summary of our VM. We can see that our VM is powered on from our initial deployment and we are ready to apply our network configurations in the next step.
Step 4 - To be able to run the above command, we will need to first authenticate into the guestOS. To do so, we will run the "vm_guest.authenticate ." and we will be prompted for the VCSA password. By default, the command assumes the username is root but that can also be specified on the command-line. If you are successful, you should not see any errors and then we can run the "vm_guest.start_program" command. Run the following to set a IPv4 static IP Address:
vm_guest.start_program . --program-path /opt/vmware/share/vami/vami_set_network --arguments "eth0 STATICV4 192.168.1.150 255.255.255.0 192.168.1.1"
Note: All commands in RVC can be tabbed out with auto-completion.

If the command was successful, you can quit RVC and you should be able to ping the IP Address that you have just configured.

Method 2 - Using vSphere SDK for Perl Script

 

Awhile back I wrote a script called guestOperations.pl which is a vSphere SDK for Perl script that implements the new GuestOperations API. This is a generic script which can be used to remotely connect to either a vCenter Server or ESXi host and perform operations within a guestOS as long as VMware Tools is installed and running. In this example, I also have the vSphere SDK for Perl installed on my Mac OS X laptop, but you can also install this SDK on any platform as well.

Step 1 - We will first use the "validate" operation to ensure our credentials to the guestOS is correct, but more importantly ensure that VMware Tools is up and running.
If the operation was successful, we should see our guest credentials validated. If not, you may need to wait a minute or two while VMware Tools is still loading up.

Step 2 - To invoke the command to configure the network configuration, we will use the "startprog" operation and run the following:
./guestOpsManagement.pl --server mini --username root --guestusername root --vm VCSA-5.1 --operation startprog --program_path /opt/vmware/share/vami/vami_set_network --program_args "eth0 STATICV4 192.168.1.150 255.255.255.0 192.168.1.1" --working_dir /
If the command was successful, then you should now be able to ping the IP Address that you have just configured.

As you can see, with the use of the GuestOperations API, you can do more than just setup the network configuration for a VM, you can run pretty much any command within the guestOS as you normally would if you were to RDP or SSH in. This is a very powerful interface that you can leverage to help you automate your virtual machine deployment and configurations!

Friday, February 15, 2013

How To Backup & Restore Free ESXi Host Configuration

ESXi host configurations can easily be backed up and restored using either the vCLI's vicfg-cfgbackup or PowerCLI's Get-VMHostFirmware cmdlet. These commands along with others that perform "write" operations are only supported when you have a (paid) licensed version of ESXi. If you are using free ESXi, the remote commands are only available for "read-only" operations. For more details, please refer to this article here.

Note: In my personal opinion, it is much quicker and more efficient to re-install ESXi and apply your configurations using either a scripted deployment such as kickstart or a combination along with post configuration scripts. Re-installs become extremely trivial when you centralize your ESXi host configurations, even for small setups. 

Having said that, if you are running free ESXi in a small shop or in a home lab and wish to backup your ESXi host configurations, you can still do so by leveraging a neat little tool called vim-cmd found within the ESXi Shell. There is a section under hostsvc/firmware which manages the ESXi host configuration which also uses the same vSphere APIs that both vicfg-cfgbackup & Get-VMHostFirmeware command uses.

Under this section of vim-cmd, there are four commands:
  • backup_config   
  • reset_config    
  • restore_config  
  • sync_config
Prior to actually backing up your ESXi host configuration, run the following command which will flush the ESXi configuration changes:
vim-cmd hostsvc/firmware/sync_config
To backup the ESXi host configurations, run the following command which will generate a file that will be automatically stored in /scratch/downloads and can also be downloaded from a web browser using the URL shown from the output:
vim-cmd hostsvc/firmware/backup_config
Before restoring your ESXi host configurations, you will need to ensure the file is renamed to configBundle.tgz and stored under /tmp directory. You will also need to ensure the ESXi host is placed in maintenance mode by running the following command:
vim-cmd hostsvc/maintenance_mode_enter
To restore the ESXi host configurations, run the following command and specify the backup configuration file which should reside in /tmp/configBundle.tgz:
vim-cmd hostsvc/firmware/restore_config /tmp/configBundle.tgz
Note: Upon completing the restore, it will automatically reboot your ESXi host.

Here is a screenshot using the above commands to backup and then restore ESXi host:
Note: You can not restore an ESXi host using a configuration file backed up from a different host.

Monday, February 11, 2013

Enable Auto Startup After Power Failure For Apple Mac Mini

I recently came across a very useful tidbit after receiving several inquires asking how to configure an Apple Mac Mini to automatically startup after a power failure. This is extremely useful for situations where power is eventually restored and you are not physically around to press the power button. Automatically starting up after a power failure is not a new feature of the Mac Mini and it actually exists on most modern day systems and can be configured using a variety of tools.

The challenge arises when you are running ESXi, how do you go about enabling this functionality in ESXi itself? Well the answer is actually quite simple, you can enable this outside of ESXi. Normally to enable this feature you can either run a setpci command on UNIX/Linux system or configure the energy saver settings in OS X. Several folks from the VMTN community such as zippytiff and twuhabro have already confirmed having success using the latter option when booting OS X off a USB or SD card to modify the energy saving settings.

I finally got a chance to look into this a bit more for myself and with a bit of research, I found several other methods which also works and may potentially be easier.

Note: I have heard that historically the auto startup flag has not persisted in older Apple hardware, but for the new Mac Mini 5,3 and 6,2, they seem to be persisting without any issue from my testing. YMMV depending on your hardware and/or firmware.

Method 1 (Configure in OS X)

If you already have OS X install on your Mac Mini, then you just need open up the System Preferences and enable auto startup under the Energy Saver section. Once that has been enabled, you can then perform your ESXi installation.

If you already have ESXi installed, then you can use either Method 2 or 3.

Method 2 (Configure using bootable Ubuntu on USB)

We can create a bootable Ubuntu image running off of a USB device (minimal footprint) and run the following setpci command to enable auto startup:
setpci -s 0:1f.0 0xa4.b=0
If you are interested in the gory details on the above command, please refer to this great article which breaks it all down for you. After you have created your Ubuntu image using the instructions in the above link, you can boot off of the USB device (Make sure to hold down ALT/OPT key so you can select to boot off of the USB device). Once Ubuntu has booted up, you will right click on the purple icon on the upper left hand corner and type in terminal.
You will then launch the terminal application and type the following to change over to root user.
sudo su -
Finally, you will enter the above setpci command which will enable the auto startup. At this point, you can type reboot and remove the USB device.

Method 3 (Configure using bootable OS X on USB)

Another method is to create a bootable OS X image running off of a USB device and change the power management settings by using the pmset utility. To enable auto startup, run the following command in the terminal:
pmset autorestart 1
You will need the original OS X installer and if you are using either Lion or Mountain Lion, you can use Lion DiskMaker to help you create the bootable USB image (Make sure to hold down ALT/OPT key so you can select to boot off of the USB device). Once the OS X installer boots up, at the top select Utilities and click on the Terminal application.
Go ahead and run the above command to enable auto start and then type reboot and remove the USB device.

The last thing to do of course is to actually test this out on your Mac Mini. Go ahead and let the system boot up and then yank the power cord and then give it a few seconds before plugging it back in. You should see the Mac Mini automatically power back on after you plug the power back in.

References:

Friday, February 8, 2013

How to Access vSphere Remote Console Using vSphere & VMRC API

Similar to my vCloud Director article, you can also provide access to the remote console of a virtual machine in a vSphere environment to your end users. This can be accomplished by leveraging both the vSphere and VMRC (Virtual Machine Remote Console) APIs and can be useful if you are building a custom portal for users to access their virtual machines. To use the VMRC API, you can download the latest VMRC 5.1 SDK which provides the following:
The VMRC SDK allows you to use a Web-based application to connect to a vCenter- or vCloud Director-managed virtual machine and access that virtual machine’s console in a browser window. You can interact with the virtual machine console input and screen. You can also use the VMRC SDK to manage virtual and physical device connections on a vCenter-managed virtual machine.
The VMRC SDK includes documentation to the API as well as a sample webpage implementing some basic functionality of the VMRC API. I recently received a question on how to get started with the sample as it was not completely intuitive and thought I take you through the required steps to get the sample working.

Step 1 - Download the VMRC 5.1 SDK and extract the contents to your local desktop.

Step 2 - Open the vmrc-embed-example.html using a web browser located in the docs folder.

Note: In my example, I uploaded both the javascript and html file to a web server and accessed the sample by connecting to the server instead of running it locally on my desktop. This was to show how users could access the custom portal using the VMRC SDK.

Step 3 - At the top of the page where it says "VMRC Modes", make "MKS" is selected in the drop down box and click on the "+" icon to add. Then go ahead and click on the "Start" button to start a VMRC instance and ensure you see a success message on the right hand side of the console box.
Step 4 - To authenticate to VMRC, you will need a session ticket which will be obtained through the use of the vSphere API using the acquireCloneTicket() method provided by the SessionManager managed object. In this example, we will be using the vSphere MOB to quickly retrieve our session ticket, but in a real implementation, you would programamtically retrieve the session ticket along with few othe pieces of information to connect to the VMRC. Open up a new tab in your web browser and connect to the following URL:
https://reflex.primp-industries.com/mob/?moid=SessionManager&method=acquireCloneTicket
Note: Make sure you substitute in your vCenter Server IP Address/Hostname

Once you have authenticated, go ahead and click on the "Invoke Method" which should generate a session ticket:
Step 5 - Copy the session ticket string and go back to our VMRC sample page. We will now need to fill out the following sections before we can access the remote console of a virtual machine:
  • Hostname (IP Address/Hostname of your vCenter Server)
  • Allow SSL Validation Errors (Check this if you are using self signed SSL certificates)
  • Ticket (Paste the session ticket from the previous step here)
  • VM ID (This is the MoRef ID of the VM you wish to connect to the remote console)
Once you have filled out the minimum required fields, go ahead and click on the "Connect" button and if everything was successful, you should now see the remote console of the virtual machine you selected.

Saturday, February 2, 2013

How to Send vCenter Alarm Notifications to SMS & Other Online Services Using IFTTT

I just discovered a pretty cool free online service called IFTTT (If That Then This) which allows you to easily create what is known as a recipe that is composed of trigger and an action to send a notification. This can be thought of like a vCenter Alarm with a trigger and action, but in IFTTT's case, a trigger and action can be almost anything such as an email, facebook event, twitter, etc.
I stumbled onto IFTTT while going through some of my unread blog feeds this morning since I could not go back to sleep after randomly waking up at 4am in morning. I was reading an article from Matt Cowger about something called a Pebble which I had not heard of before and it peaked my interest. In reading about Pebble (pretty slick actually), I learned about IFTTT which is one of the notification systems Pebble supports. I decided to give IFTTT a try and to see how easy it would be to setup SMS notifications for a vCenter Server alarm.

Step 1 - Sign up for IFTTT account, you need to ensure the email account that you use to register is the same account that will be used to send the trigger.

Step 2 - Create a new Recipe using email as the trigger and SMS for the action. The process is very straight forward, just follow the wizard and at the end you will enter your phone number for SMS notification and confirm with a code.
Step 3 - Create a vCenter Alarm for the event you wish to trigger off of and set the email address to send to trigger@ifttt.com as noted in the Recipe.
Step 4 - In my test, I created an alarm for a Powered Off event and went ahead and powered off a VM to generate the alarm.
Step 5 - IFTTT checks the triggers every 15minutes. If you do not wish to wait 15minutes you can force a check by clicking on Check Now button in the Recipe.
Step 6 - If everything was setup correctly, you should have received a text message with the details of the vCenter alarm. In my Recipe, I configured it to only send the Subject which contains everything you would need to know about the vCenter alarm, at least for you to decide whether or not you want to investigate the issue.
The possibilities are pretty much endless in terms of the triggers and actions that you could create with IFTTT, I even created one for my ghettoVCB backup notification. The only downside that I noticed while giving IFTTT a try is that the trigger check is every 15minutes which could be a bit long for things requiring immediate attention, but I also read that there are certain Recipes that supports a "Quick Trigger" which would then execute immediately upon receiving. I think for a free service this is very cool and much easier than setting up your own SMS system. I would recommend giving IFTTT a try and see what cool Recipes you can build and integrate with your VMware or other environments.

I hope my body will let me crash and get some sleep now ...