WilliamLam.com

How to Create a vCenter Alarm to Monitor for root Logins

by // 7 Comments

Another interesting question on the VMTN forums this week, a user was looking for a way to trigger a vCenter alarm when a someone would login to an ESX(i) host using the root account. By default there are several dozen pre-defined vCenter alarms that you can adjust or modify to your needs, but it does not cover every single condition/event that can be triggered via an alarm. This is where the power of the vSphere API comes in. If you browse through the available event types, you will find one that corresponds to sessions called sessionEvent and within that category of events, you will see a UserLoginSessionEvent.

Now that we have identified the particular event we are interested in, we simply just create a new custom alarm that monitors for this event and ensure that "userName" property matches "root" as the user we are trying to alarm on. I wrote a vSphere SDK for Perl script called monitorUserLoginAlarm.pl that can be used to create an alarm on any particular user login.

The script requires only two parameters: alarmname (name of the vCenter alarm) and user (username to alarm on). Here is a sample output for monitoring root user logins on an ESX(i) host:

The alarm will be created at the vCenter Server level and you should see the new alarm after executing the script.

Note: The alarm action is currently to alert within vCenter, if you would like it to perform other operations such as sending an email or an SNMP trap, you can edit the alarm after it has been created by the script.

Next it is time to test out the new alarm, if you click on the "Alarms" tab under "Triggered Alarms" and login to one of the managed ESX(i) host using a vSphere Client with the root account, you should see the new alarm trigger immediately.

If we view the "Tasks/Events" tab for more details, we can confirm the login event and that it was from someone using the root account.

As you can see even though this particular event was not available as a default selection, using the vSphere API, you can still create a custom alarm to monitor for this particular event.

I do not know what the original intent of monitoring for monitoring root logins, but if there is a fear of the root  account being used, the easiest way to prevent this is to enable vCenter Lockdown Mode for your ESXi host.

How to Send vCenter Alarm Notification to Growl

by // 2 Comments

This tweet from Jason Nash and @PunchingClouds says it all and here it is!

I did some research this afternoon and stumbled upon this article Nagios: Notifications via Growl and leveraging the Net::Growl Perl module, I was able to forward alarms generated from a vCenter server to a system that was running Growl.

Software Requirements:

Step 1 -  Install Grow and configure a password under the "Security" tab and ensure you "Allow network notification"

Step 2 - Install vSphere SDK for Perl on your vCenter server. You may also need to update the PATH variable with Perl bin directory (e.g. C:\Program Files\VMware\VMware vSphere CLI\Perl\bin)

Step 3 - Install Net::Growl Perl module using ppm (Perl Package Manager) which is part of ActiveState Perl with the installation of vSphere SDK for Perl. This will require your vCenter server have internet access to ActiveState Perl site, if you can not get this access, you can install this locally on your system and extract the Growl.pm and copy it to your vCenter server C:\Program Files\VMware\VMware vSphere CLI\Perl\site\lib\Net

Step 4 - Copy the Perl script from here and store it somewhere on your vCenter server, make sure it has the .pl extension. In this example, I named it growl.pl

Step 5 - To verify that Growl Perl script works and can communicate to the system with Growl install, you can manually test it by running the following command:

growl.pl -H william.primp-industries.com -p vmware -a custom -t Alert -m "hello william" -s 1

You will need to change -H to the hostname or IP Address of the system with Growl installed and of course the password you had setup. You should see a notification of the message you had just sent.

Step 6 - Create a batch script which will call the growl.pl script and store it somewhere on your vCenter server. Here is what the script (sendGrowl.bat) looks like, you can modify it to fit your requirements.

:: http://www.virtuallyghetto.com/
:: Custom vCenter Alarm script to generate growl notifications

set GROWL_SERVER=william.primp-industries.com
set GROWL_PASSWORD=vmware
set GROWL_SCRIPT_PATH="C:\Documents and Settings\primp.PRIMP-IND\Desktop\growl.pl"
set PATH="%PATH%;C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\site\bin"

%GROWL_SCRIPT_PATH% -H %GROWL_SERVER% -p %GROWL_PASSWORD% -a %COMPUTERNAME% -t Alert -m "%VMWARE_ALARM_EVENTDESCRIPTION%" -s 1

Note: If you would like to get a list of other default VMware alarm variables, run the "SET" command and output it to a file to get more details on various variables that can be accessed.

Step 7 - Create a new or update an existing vCenter alarm and under "Actions", specify "Run a command" option and provide the full path to the sendGrowl.bat

Step 8 - For testing purposes, I created a new alarm that would trigger upon an ESX(i) host going in/out of maintenance mode and you can see from the "Tasks and Events", our script is triggered on the vCenter server

and now for the finale, you should see a notification from Growl on your system and since we enable the "sticky" parameter, the notification will stay on your screen until you click on it. You can see that in the script example, I set the message to the event and application is registered as the name of the vCenter server, which allows you to have multiple vCenter forward you notifications.

So there you have it, forwarding vCenter alarms to Growl.

Note: Once a vCenter alarm has been triggered, the script will not fire off again until the original alarm has been reset to green. This behavior probably is okay for majority of the events one would want to monitor, but if you want it to continuously alert you, you will need to fiddle with a way to reset the alarm on the vCenter server.

UPDATE:  Thanks to Richard Cardona for reminding me, but this can also be implemented on the new VCVA (vCenter Server Virtual Appliance) in vSphere 5. Here are the instructions on setting it up

Step 1 - Install Grow and configure a password under the "Security" tab and ensure you "Allow network notification" on the system that is receiving the Growl notifications

Step 2 - To install Net::Growl, we'll be using cpan which requires 2 modules that are not installed by default on the SLES VCVA. Using the Tips and Tricks for vMA 5 (running SLES as well), we'll go ahead and setup zypper package manager for VCVA to install the two required packages: make and yaml

zypper --gpg-auto-import-keys ar http://download.opensuse.org/distribution/11.1/repo/oss/ 11.1
zypper --gpg-auto-import-keys ar http://download.opensuse.org/update/11.1/ Update-11.1
zypper refresh
zypper in make
zypper in perl-YAML

Step 3 - You will use cpan to install Net::Growl

perl -MCPAN -e shell

Step 4 - Once you are inside the cpan shell, type the following to install Net::Growl

install Net::Growl

Step 5 - Copy the Perl script from here and store it somewhere on your vCenter server (e.g. /root), make sure it has the .pl extension and has execute permission. In this example, I named it growl.pl

Step 6 - To verify that Growl Perl script works and can communicate to the system with Growl install, you can manually test it by running the following command:

vcenter50-2:~ # ./growl.pl -H william.primp-industries.com -p vmware -a custom -t Alert -m "hello william" -s 1

Step 7 - Create a shell script which will call the growl.pl script and store it somewhere on your vCenter server (e.g. /root). Here is what the script (sendGrowl.sh) looks like, you can modify it to fit your requirements.

Step 8 - Create a new or update an existing vCenter alarm and under "Actions", specify "Run a command" option and provide the full path to the sendGrowl.sh

vMotion' With Style

by // Leave a Comment

I got this idea after catching an interesting tweet by Cody Bunch last Friday:

I had just recently finished a post on How to Ack & Reset vCenter Alarm implementing hidden API method and thought this might work by using a vCenter alarm. After few hours in our skunkwork's lab, I found "a" method to exactly what Cody wished for. If you can not wait, jump straight to the video at the bottom 🙂

The following tools were used:

  • PsExec -Windows utility to perform remote operations
  • SayStatic - Windows text to speech utility
  • A random mp3 audio file found online

The environment consisted of two vESXi 4.1 hosts and Windows XP VM residing on shared storage that was vMotion functional:

You will need to upload some files to your vCenter server and to the desktop in which you want to implement this hack.

Local Desktop Server Setup

1) Download SayStatic to your local desktop ( in the example, it is located on the desktop)

2) Download a playable mp3 file (in the example, it is located on the desktop)

Note: If you decide to change the path to the files above, please make note of the path as it will be used later in the alarm script.

Here is a screenshot of my local desktop:

vCenter Server Setup

1) Download PsTools toolkit and extract the contents to your vCenter Server and make a note of the path (in the example, it is located on the desktop)

2) Create an alarm script and make a note of the path ( in the example, it is located in C:\alarm.cmd)

The alarm.cmd should contain the following:

You will need to edit the script and update at minimum the following variables:
REMOTE_SERVER = This is the hostname or IP address of your local desktop, make sure you keep the double slashes which is needed

REMOTE_USERNAME = This is the username to login to your local desktop and it should be the one you use to login else you will not see anything interesting. Make sure you include both the Domain and username, if your system is not part of a domain, use the local system name else the script will fail.

REMOTE_PASSWORD = The password to the account aove

Note: If you have changed the path of the files on either the local desktop or vCenter Server, you will need edit the remainder variables that specify where to look for the executable's.

Here is a screenshot of vCenter Server desktop:

vCenter Alarm:

Finally, we need to create an alarm in vCenter, you can create this at any level of the vCenter infrastructure.

1) Create an alarm and give it a name and ensure the type is of "Virtual Machines" and monitor type is "Monitor for specific events occurring on this object" (in the example, I call it VMOTIONIN_WITH_STYLE)

2) Now click on the Triggers tab and look for an event type called "VM emigrating", no this is not a typo. VMware apparently has both "VM migrating" and "VM emigrating", apparently the functional alarm is under the name emigrating ... don't ask me why they called it that ;). Make sure the status is set to "alert"

3) Next, click on the Actions tab and set the action to "Run a command" and specify the configuration to the path of the alarm.cmd. In the example, I stored the script in C:\alarm.cmd and then make sure it alarms when it hits "red" or error and then click okay for the alarm to be created.

Now you are ready to go. Instead of explaining and providing screenshots, I thought I show you what this would look like (explanation of what is going on is at the very bottom).

Without further ado, here is a recorded video of this in action:

vMotion' With Style from lamw on Vimeo.

What is actually going on:
When a vMotion is triggered, it will fire off the alarm.cmd script which basically uses SayStatic.exe to remotely execute on your local desktop to announce the virtual machine being vMotioned by capturing the VMware specific environmental variables and then it will also remotely playing the local audio file using Windows Media Player.One caveat that I was not able to solve, was clearing the alarm after the vMotion. You will notice the virtual machines that vMotion and fire off this alarm will stay alerted and will not play again until it has been resetted to green. I thought about creating another alarm to clear this initial alarm but it did not actually clear the alarm.

There you have it, vMotioin' with style ... though cool in concept, I doubt you will last very long with this kicking off on every single vMotion in your environment.

Big thanks to Cody Bunch for the idea! 🙂