vCenter Event Broker Appliance – Part I – Deployment


I recently became aware of the vCenter Event Broker Appliance Fling, Open Source code released by VMware which allows customers to easily create event-driven automation based on vCenter Server Events. You can think of it as a way to run scripts based on alarm events – but you’re not limited to only the alarm events exposed in the vCenter GUI. Instead, you have the ability to respond to ANY event in vCenter.

Did you know that an event fires when a user account is created? Or when an alarm is created or reconfigured? How about when a distributed virtual switch gets upgraded or when DRS migrates a VM?  There are more than 1,000 events that fire in vCenter;  you can trap the events and execute code in response using VEBA. Want to send an email and directly notify PagerDuty via API call for an event? It’s possible with VEBA. VEBA frees you from the constraints of the alarms GUI, both in terms of events that you can monitor as well as actions you can take.

VEBA is a client of the vSphere API, just like PowerCLI. VEBA connects to vCenter to listen for events. There is no configuration stored in the vCenter itself, and you can (and should!) use a read-only account to connect VEBA to your vCenter. It’s possible for more than one VEBA to listen to the same single vCenter the same way multiple users can interact via PowerCLI with the same vCenter.

For more details, make sure to check out the VMworld session replay “If This Then That” for vSphere- The Power of Event-Driven Automation (CODE1379UR)

Installing the VEBA – Updated on January 23, 2020 to show the 0.2 release

If you notice screenshots alternating between an appliance named veba01 and veba02, it’s because veba02 was my v0.1 appliance and veba01 is my new v0.2 appliance. I realize the naming is backwards, but veba02 was actually my second v0.1 appliance and I re-used the old veba01 IP and DNS entry.

The instructions can be found on the VEBA Getting Started page.

First we download the OVF appliance from and deploy it to our cluster


I learned from my first failed VEBA deployment to read the instructions – it says the netmask should be in CIDR format, but I put in Make sure you’re using CIDR format.

Another potential gotcha is DNS settings – DNS is space separated in the OVF, although the 0.2 version guides you with a prompt for space separated.

Both NTP and proxy support are new in 0.2. I don’t have a proxy server in the lab so I am not configuring it here.

The POD CIDR network is an important setting new in 0.2. This network is how the containers inside the appliance communicate with each other. If the IP that you assign to the appliance is in the POD CIDR subnet, the containers will not come up and you will be unable to use the appliance. You must change either the POD CIDR address or the appliance’s IP address so they do not overlap.



This is what the VEBA looks like during first boot


If you end up with this, [IP] in brackets instead of your hostname, something has failed. Did you use a subnet mask instead of CIDR? Did you put comma-separated DNS instead of space? Did you put in the incorrect gateway? If you enabled debugging at deploy time, you can look at /var/log/boostrap-debug.log for detailed debug logs to help you pinpoint the error. If not, see what you can find in /var/log/boostrap.log

If you made a configuration error and the initial setup was unsuccessful, you can make changes to the vApp properties and reboot. Note that changes made to the vApp properties after the first successful boot of the VEBA will not alter the appliance configuration.

In this case, the debug log showed me that DNS lookups were failing, and I used comma-separated DNS. I also used the wrong gateway, so I had to make multiple fixes before setup succeeded. The VM must be powered off to make changes to the vApp Options. I clicked on guestinfo.dns, then clicked the “SET VALUE” option, and correctly entered my DNS servers with space separation. Note that in future releases of the VEBA appliance, the configuration screen will notify you that you need to use space-separated DNS.

This represents a successful VEBA boot.

Now we have a VEBA appliance and need to configure it with functions to respond to events. Note that it may take some time for the appliance to respond to http requests, particularly in small homelab. It took about 4 minutes for it to fully come up after succesful boot in my heavily overloaded homelab. One additional gotcha: the name you input at OVF deployment time is the name encoded in the SSL certificate, so if you input “veba01” as your hostname, you cannnot then reach it with

In part II of this series, I will demonstrate how I configured my laptop with the prereqs to get the first sample function working in VEBA.

2 thoughts on “vCenter Event Broker Appliance – Part I – Deployment

  1. Pingback: vCenter Event Broker Appliance – Part III – Tags and Clones | Patrick Kremer

  2. Pingback: vCenter Event Broker Appliance – Part II – Sample Code Prereqs | Patrick Kremer

Leave a Reply

Your email address will not be published. Required fields are marked *