WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
    • VMware Cloud Foundation 9
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Search Results for: vsphere events

Leveraging vCD + vCO + Wavemaker Part 2

12.09.2011 by William Lam // 3 Comments

Continuing from our previous post Leveraging vCD + vCO + Wavemaker Part 1, I am now going to show you how to integrate the vCenter Orchestrator workflow we created earlier into Wavemaker to present a simple web application to an end user. If you can not wait to go through all the steps, jump to the bottom for the video of the final product.

You will need to download Wavemaker 6.4.3 RC versus the 6.3.3 GA because there is a specific UI feature that I have utilized to provide a better user experience. You will need to register for a free account to download the development builds and I have been told 6.4.3 should GA pretty soon.

Once you have downloaded Wavemaker, you will need to install it on your system and you maybe asked to perform an additional library download, just follow the instructions and you ready to create your first Wavemaker application. After the installation, go ahead and start the Wavemaker application and it will automatically launch a web browser which will be your workspace. You will need to use either Firefox or Internet Explorer, as it does not work with Chrome.

In case you get lost below or would like to just get this working right away, I have exported my project and it can be downloaded it here. You can simply import the .zip file and make the necessary changes to the project to fit your environment.

Start off by creating a new project and give your project a name and just use the default theme and then click ok.

Next, at the top screen click on "Services" and then "Web Service" since vCO is exposed as a webService API which we will import into Wavemaker.

We need to specify the URL of your vCO server, it should be in the following format:

http://vco.primp-industries.com:8280/vmware-vmo-webcontrol/webservice?WSDL

and then provide a name for your service, in the example, I named it "vCOReference".

Once the vCO service has been imported, click on "Canvas" and then "Palette". We will now add widgets for our web application. Add the following in this order: Picture (if you wish), Text, Button and Grid. It should look something like the following:

Most of these should be pretty self explanatory widgets. The Grid (dataGrid) is used to display your data result.

If you decide you would like to add a logo/banner, click on the "Source" tab at the top and then click on "Resources". Here you will be able to add any additional resources to your project such as a images.

Once you have uploaded your image, select the picture widgets in your canvas and click on "source" icon to the right side of the screen. Here you can now bind to the image you just uploaded and click "Bind", there is also a green icon on the upper right hand corner to show you whether or not the binding is the proper type.

You should see the image being displayed in the picture widget.

Now click on the Text widget in your canvas and go ahead and provide a name for the variable and also a caption which is located on the right side of the screen. In the example, I named both fields "username", you can provide a different name but be sure to keep track of the variable name as it is used later on.

If you recall earlier, I mentioned I am using a specific UI widget that requires Wavemaker 6.4.3 RC, which is the LoadingDialog widget and allows us to display a busy dialog for various events. This is just one of the many features in 6.4.3 release. Go ahead and add this to the canvas and it is under "Dialogs". We will also configure the "widgetToCover" and specify "dojoGrid1" which is just the name of our dataGrid.

Next we will need to add several variables that will call the vCO services and store our results. To add these new variables, you will click on the "Insert" option at the very top. It is also helpful to be in the "Services" tab next to "Model" to see the variables that have been created in your navigation pane.

The first variable that we will add is called "varResult", this will be a regular variable that will be used to store our results. Make sure the following properties on the right side of the screen are set:

  • name = varResult
  • type = StringData
  • isList = checked

The second variable to be created will be a "Service Variable" and will named "getResult" which will retrieve the results from vCO using the getWorkflowTokenResult API method. Make sure the following properties on the right side of the screen are set:

name = getResult
servcice = vCOReference
operation = getWorkflowTokenResult

The third variable will be a "Timer" variable which is located under "Advanced" and will be named "resultTimer". This is needed as the results are not available immediately after executing the workflow and we set a 3sec timer to then retrieve our results.

Make sure the following properties on the right side of the screen are set:

  • name = resultTimer
  • delay = 3000 (in MS, you may need to tweak this based on your env)
  • repeating = unchecked

We will also need to specify the action to trigger when the timer fires, this is defined under "Events" for the resultTimer variable. Set the onTimerFire to "getResult" Service Variable that we defined earlier. When the timer goes off, it will retrieve the results of our workflow

The fourth and final variable that we will need to add is also a "Service Variable" which will execute the workflow by calling the executeWorkflow API in vCO. We will name it "runWF". Make sure the following properties on the right side of the screen are set:

  • name = runWF
  • service = vCOReference
  • operation = executeWorkflow

Now we need to bind our parameters which will be used to provide input to the various variables and/or vCO API methods.

The first one will be the "getResult" variable and you will need to expand down to "parameters" on the right side of the screen. Here you should see three parameters which will need to be populated: password, username and workflowTokenId.

Click on "username" and then a new window will pop-up. Select "Expression" and then select "username" and provide the username that will be used to connect to vCO and ensure there are double quotes around the string and click Apply when finished.

Click on "password" and do the same exact thing and provide the password that will be used to connect to vCO and click Apply when finished.

Click on "workflowId" and instead of selecting "Expression", select "Simple" and drill down into the "runWF" Service Variable and select "id". As part of the executeWorkflow return object, a WorkflowTokenType is returned and the "id" property is what is needed for us to retrieve the results of the workflow. Click "Bind" to finish the parameter binding for this service variable.

Note: There is a green box on the upper right hand of the screen which validates the property binding type, this can be helpful when binding parameters.

After you have finished binding those three parameters, you should now see the following:

Lastly for this service variable, we will also need to create an event trigger. Select "onResult" and click on "Javascript" which will allow us to insert some javascript logic upon the result of the data.

You will now be taken to the "Source" tab and a new javascript function will automatically be created for you called "getResultResult" assuming you have followed the naming standards in the example. You will need to add the following lines of javascript to the function:

The script clears any previous output on the dataGrid and then retrieves the data which is returned as a single string and replaces all the characters we do not want. It then splits using the ";" as the delimiter and adds each entry to our dataGrid.

Once you have pasted the javascript, go ahead and click back on the "Cavnas" tab. In addition to the first even trigger, we will also set "onSuccess" to loadingDialog1.hide which will hide the busy dialog after the results are available to be displayed on the dataGrid.

Now we need to configure the event triggers for "runWF" service variable. The first is "onBeforeUpdate" and we will set that to loadingDialog1.show which will display the busy dialog while the workflow is being executing. The second will be "onResult" and that will be configured to call the "resultTimer" timer variable and retrieve our results after the workflow has been executed.

Next we will need to configure the "submit" button event and we will again create a custom javascript which will call our "runWF" service variable.

Note: This technically could have been easier to bind to the parameters of the "runWF" service variable, but I found a bug that prevented this from working. A work around was provided by Michael Kantor, a Wavemaker developer and the bug has been reported and hopefully will be fixed before the GA version of 6.4.3 is released.

You will need to add the following lines of javascript to the function:

Here you will need to substitute the username/password to your vCO server and the workflowId which can be obtained by following this blog post. The workflowInputs requires the name of the workflow input variable name and assuming you followed the previous article, you can keep the same name and "this.username.getDataValue()" will extract the string from the username text widget you added. If you changed the name of the variable, you will need to update this accordingly.

Okay, we are almost there. The last widget we need to add an event trigger to is the dataGrid and for "onClick" we will also create a new javascript.

You will need to add the following lines of javascript to the function:

This single line of javascript will open a new window when a user clicks on one of the dataGrid cells.

Now lastly, we just need to bind our dataGrid to our "varResult" variable that contains the results. Select the dataGrid widget and click on "dataSet" and bind to "varResult" and ensure you see a green icon on the upper right hand side of the window.

You can also name the column header, by default it is called "DataValue" and you can change it to "orgUrls" if you like. To do so, right click on the dataGrid and select "editColumns".

We are all done now! We just need to compile the application by click on the "Run" icon at the very top. After the application compiles, it will open a new window to your new Wavemaker application.

Here is a quick video demonstration of the application using:

Leveraging vCD + vCO + Wavemaker Part 2 from lamw on Vimeo.

So there you have it, creating your own custom web portal application using Wavemaker, vCenter Orchestrator and vCloud Director vCO Plugin! As you can see the possibilities are endless and with a little javascript knowledge, you can create any type of portal that goes beyond just VMware products!

I would like to give a big thanks to Christian Johannsen, Michael Kantor and especially Craig Conover in assisting me with creating my first Wavemaker application. These guys are truly rock stars with vCO and/or Wavemaker! For more information about Wavmeker, definitely check out documentation/examples and the Wavemaker community forums.

In addition, there are some other great examples of utilizing Wavemaker written by my colleagues:

  • Hany Michael - Eating My Own Dogfood: SpringSource + WaveMaker + vCloud APIs + Cloud Foundry + vCloud Director
  • Massimo Re Ferre - vCD Custom Portals and Backend Integrations in a Service Provider Environment

Categories // Uncategorized Tags // orchestrator, vcd, vcloud director, vCO, wavemaker

How to Create a vCenter Alarm to Monitor for root Logins

10.12.2011 by William Lam // 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.

Categories // Uncategorized Tags // alarm, api, root, vsphere sdk for perl

How to Send vCenter Alarm Notification to Growl

08.14.2011 by William Lam // 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:

  • Growl for Windows or Mac OSX installed on a system to receive notifications
  • vSphere SDK for Perl installed on vCenter Server

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

Categories // Uncategorized Tags // alarm, api, growl, VCSA, vcva, vSphere 4.1, vSphere 5.0, vsphere sdk for perl

  • « Previous Page
  • 1
  • …
  • 33
  • 34
  • 35
  • 36
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • USB Native Network Driver for ESXi supports Realtek RTL8157 & RTL8156BG 02/13/2026
  • Automating the Retrieval of VCF Installer Deployment Milestones 02/10/2026
  • Cross vCenter vMotion workloads from vSphere 7.0 to vSphere 9.0 02/09/2026
  • Installing Realtek Network Driver Fling using Free ESXi 8.0 Update 3e ISO 02/05/2026
  • Modern Kubernetes Visualization using Radar 02/01/2026

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.

To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2026