WilliamLam.com

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

Search Results for: vsphere events

Auditing vMotion Migrations

04.12.2012 by William Lam // 3 Comments

I saw an interesting question this week about auditing vMotion events and the number of times a VM has migrated to a particular ESX(i) host for license compliance. You can view this information using the Task/Events in your vCenter Server but you can also extract out the various types of events using the EventManager in the vSphere API. You will be able to go as far back in time as your vCenter Server's database retention policy allows you to. We will be searching for the VmMigratedEvent Event which will include variety of information including the source and destination host for the VM. The destination host will only be populated upon a successful vMotion.

Of course I had to write a script to help automate this, so here is a vSphere SDK for Perl script called getNumberOfvMotions.pl that accepts the name of an existing VM and will return the number of vMotions that has been performed on the VM as well as the list of destination hosts and the number of times it has migrated to those hosts. You will need a system that has the vCLI installed or you can you use vMA.

Note:  If you want to look at past vMotion for a VM that no longer exists, this is still possible, but you will need to parse the "message" within the Event as you can no longer look up that VM object in vCenter.

Here is an example of the script running:

You can easily modify the script to audit all VM's in your environment or just use a simple "for" loop to go through a set of VM's you are interested in, but I will leave that as an exercise for you.

Categories // vSphere Tags // event, VmMigratedEvent, vmotion, vSphere, vSphere API, vsphere sdk for perl

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

  • « Previous Page
  • 1
  • …
  • 34
  • 35
  • 36
  • 37
  • 38
  • 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
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VCF 9.1 - Quick Tip: Easily Generate VCF SSO API Tokens using VCF Component UI 07/27/2026
  • VCF 9.1 - Deploying the VCF License Server Directly to an ESX Host 07/24/2026
  • VCF 9.1 - vSphere Back-in-Time Support for Upgrade, Converge and Import 07/21/2026
  • VCF Infrastructure Services (VIS) Appliance for VCF 9.1 Lab/PoC 07/20/2026
  • Quick Tip - Automatically Generate VCF Download Tool Commands with Express Patches for VCF 9.0.2 and 9.1.0 07/17/2026
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