virtuallyGhetto

vcenter event broker appliance

VMware Event Broker Appliance (VEBA) v0.5.0

by Leave a Comment

Just in time for the holidays, the VMware Event Broker Appliance (VEBA) team is excited to announce our latest v0.5.0 release, which is also our last planned release of the year. 2020 has been a very difficult year for everyone, but looking at the positives, we could not have been happier with the engagement and community contributions that we have received from our user base. I just want to say, THANK YOU to everyone who has used and have shared their feedback on VEBA. We have so much more planned for 2021, cannot wait to share with the community! 

While reviewing some of the GitHub commits (changes) for the v0.5.0 release, I had noticed the number of commits in this release has even surpassed our very first v0.1.0 release back in November of last year.  

Here is a quick recap of all 6 VEBA releases: 

  • v0.1.0 (11/25/19) - 351 commits 
  • v0.2.0 (01/23/20) - 311 commits 
  • v0.3.0 (03/10/20) - 252 commits 
  • v0.4.0 (05/11/20) - 191 commits 
  • v0.4.1 (06/10/20) - 141 commits 
  • v0.5.0 (11/25/20) - 356 commits 

Let’s now take a look at what is new with the v0.5.0 release. 

[Read more...] about VMware Event Broker Appliance (VEBA) v0.5.0

Integrating VMware Cloud Notification Gateway with VMware Event Broker Appliance (VEBA)

by Leave a Comment

I previously wrote about the VMware Cloud Notification Gateway (NGW) which provides curated notifications delivered to VMware Cloud on AWS users. By default, NGW supports several  types of notification channels such as email, VMware Cloud Console UI, VMware Cloud Activity Log, vRealize Log Intelligence Cloud (vRLIC) and the vSphere UI when using the vCenter Cloud Gateway. A lesser known feature of NGW is the ability to extend into even more channels by leveraging its webhook functionality which is available when using NGW API.

For a basic "pass through" of the NGW notification to another cloud service such as Slack or Microsoft Teams as example, you can simple setup an incoming webhook on Slack or Microsoft Teams, which I had covered in the previous blog post. From there, you can configure an NGW subscription and forward the NGW notification to the specified incoming webhook.

For more interesting scenarios where customers may want to perform some additional data processing when the NGW notification arrives or run some code/automation and integrate that with other systems which can include your on-premises infrastructure, the basic webhook workflow is not sufficient. Having said that, at the end of the previous blog post I did hint at a solution that would enable customers to support such scenarios which is by leveraging the VMware Event Broker Appliance (VEBA) solution.


The way this works is that we are still taking advantage of the NGW webhook capability but instead of forwarding the NGW notification to a cloud service that supports an incoming webhook, we are sending it to VEBA for processing. Once the notification has been received by VEBA, customers can apply additional logic by using any language of their choice which runs as an automated function and is then responsible for sending the final payload to its destination. This is really the power of VEBA which enables customers to perform any additional processing or business logic to an event before sending it out to its intended target.

[Read more...] about Integrating VMware Cloud Notification Gateway with VMware Event Broker Appliance (VEBA)

Custom notification and automation based on host failure in VMware Cloud on AWS

by Leave a Comment

Physical hardware failure is inevitable, this is true whether it is running in your on-premises datacenter or in the Cloud like VMware Cloud on AWS. Although vSphere HA will automatically restart all affected VMs after detecting a host failure, there is usually additional activities that must be performed by a customer such as notifying all impacted application owners and even creating an incident ticket for hardware replacement.

With VMware Cloud on AWS, the hardware replacement is done automatically for you but the downstream activity of notifying application owners to verify the application is functional is still managed by the customer. There are many ways in how customers can manage such incidents and one solution that I am a huge advocate of is taking advantage of the powerful vCenter Server Events, which has over 1700+ events, not to mention any of the 2nd/3rd party events.

When an ESXi host fails, the com.vmware.vc.HA.DasHostFailedEvent event will be generated which contains all the relavent information related to the host failure including the specific hostname/IP, when the incident occurred and details about the vSphere Cluster and Datacenter is also provided. This information is visible using the vSphere UI but it can also be programmatically retrieved using the vSphere API, which is how the vSphere UI renders this information.

Note: Everything described in this blog post including the VEBA example is applicable to any environment that contains vCenter Server and is not limited to just VMware Cloud on AWS.

[Read more...] about Custom notification and automation based on host failure in VMware Cloud on AWS

New VEBA release, new website and new mascot!

by Leave a Comment

Today I am very happy to share a number of updates with the community regarding the popular VMware Event Broker Appliance (VEBA) Fling. Each release has always been a team effort, but but I am especially proud of this release as it demonstrates how large the team has grown in the past 6 months and their impactful contributions to this solution to help our VMware customers and partners. Michael and I could not be more prouder and the feedback both internally and externally has been nothing but amazing and we are just getting started when it comes to event-driven automation for the SDDC! 

New VEBA Release

Here are some of the key features in our latest v0.4 release. If you wish to see a detailed change log, please refer to the VEBA github releases page.

Below are two features that I think is worth highlighting:

Thanks to Frankie Gold, we now have a slick new VEBA DCUI which replaces the old static /etc/issue entry which was only updated once after a successful deployment. If you decided to change the hostname, these changes would not be reflected. The new VEBA DCUI is dynamic and will display the latest configuration from the system including the configured system resources. In addition, it also uses the new /etc/veba-release file found within VEBA appliance which provides information about the version of VEBA, commit ID along with the event processor that was configured.


As part of the DCUI development planning, I was reminded of this fun little VMware Easter Egg. I thought it would be fun to include a few of our own and also give a nod back to this old school easter egg which sadly is no longer in the product. The default color scheme is green (cyan) and if you go into the VM Console and type "veba", you will activate an alternate color scheme as shown in the screenshot below. To return to the original color scheme, just type "veba" again to deactivate.


There is actually a couple more interesting 🐣easter eggs which I had asked Frankie to include ... I wonder who will be the first to find and share them? Maybe the first few folks who share details about the easter egg on it Twitter will get one of the new VEBA sticker!

UPDATE (05/13/20) - Congrats to Allan Kjaer on finding the first VEBA DCUI Easter Egg #1 which is typing the word "pride" (this is a nod back to the original easter egg found in Fusion, see reference above)

Congrats David Bibby on finding the second and final VEBA DCUI Easter Egg #2 which is typing the word "otto" (name of VEBA's mascot) which will activate VEBA DCUI console with rendering of Otto 🙂 To deactivate and return to the default screen, simply type "otto" again.

[Read more...] about New VEBA release, new website and new mascot!

Integrating vCenter Event Broker Appliance (VEBA) with vRealize Orchestrator 

by Leave a Comment

VMware vRealize Orchestrator (vRO) is still used by many of our customers to automate various infrastructure tasks whether that is running it in standalone mode connected to a vCenter Server(s) or powering the extensibility of vRealize Automation. For customers who have already built an extensive collection of vRO workflows, it certainly makes sense that they would like to reuse the Automation they have already created.

For customers that want to easily subscribe to specific vCenter Server event(s) and trigger specific Automation workflows, the vCenter Event Broker Appliance (VEBA) Fling has been a very popular solution. Customers no longer have to write or manage the code to retrieve specific event(s) from vCenter Server, instead they can focus on the really interesting part of the workflow which is automation or "business logic" that does something specific with a given vCenter Server event. Some common examples including notification using Slack or SMS, vSphere automation such as applying a vSphere Tag or hardening a VM configuration to alerting using PagerDuty to ticket creation in ServiceNow or Salesforce.com, the list goes on and on.

The great news is that vRO customers can also benefit from VEBA while leveraging their existing vRO workflows. VEBA can integrate with any vRO workflow by simply having a function, written using any language of your choice, that calls into the vRO's REST API to trigger a specific vRO workflow. To demonstrate this integration, I have built VEBA function using PowerShell which executes a vSphere Tagging vRO workflow which can be found here and below is a video on how this works.

Big updates to the vCenter Event Broker Appliance (VEBA) Fling

by 1 Comment

The vCenter Event Broker Appliance (VEBA) team has been working hard over the last couple of months on some pretty exciting enhancements and today we are pleased to announce the release of VEBA v0.3 which can be download from the VMware Fling site. Although this is a "dot" release, do not let that fool you as this release contains a large number updates including a major re-architecture in how events are consumed and processed at the core of VEBA.

While this re-architecture does introduce some breaking changes, it does unlock a number of new capabilities that our current users have been asking for. It also provides us with a solid foundation for delivering on future enhancements such as multi-vCenter Server support and additional event sources from NSX-T, vSAN and other VMware Cloud Services to just name a few. Today, the "V" in VEBA stands for vCenter, but in the future, I do see it changing to just "VMware" as it can support so many other solutions.

Having said that, some of the breaking changes also improves the overall user experience, especially as it relates to defining and consuming vCenter Server events as well as troubleshooting and debugging. The team is super excited to get this release in the hands of our community and we look forward to hearing your feedback!

What's New:

  • Introduction of the VMware Event Router which provides a modular and flexible architecture for decoupling the stream "Providers" such as vCenter Server from the actual stream "Processors" like OpenFaaS. More details including its architecture and design can be found here

[Read more...] about Big updates to the vCenter Event Broker Appliance (VEBA) Fling