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!
- 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
- Native support for an AWS EventBridge stream processor which can benefit customers already using AWS Services but also VMware Cloud on AWS customers who can also take advantage of the native integration into various AWS Services using VEBA. For more details on how to use the various stream processors in VEBA, please refer to the documentation here
- Support for all vCenter Server event types (Event, EventEx and ExtendedEvent). In previous releases, only a subset of vCenter Server events were supported due to the underlying event processor which has now been replaced. You can find the complete list of "default" events in vCenter Server for vSphere 6.7 Update 3 (1,600+) as well as VMware Cloud on AWS 1.9 (1,900+) in this document here. If you wish to inspect your own vSphere environment to get the list of supported events, you can take a look at this blog post here for more details
- The complete vCenter Server event payload is also now available
- Specifying vCenter Server events has also been simplified. You no longer have to transform the event type (e.g. from DrsVmPoweredOnEvent to drs.vm.powered.on). You can now simply refer to the event type used in vCenter Server using either the list provided here or generating your own from here
- In the stack.yaml definition file, you can now subscribed to more than one vCenter Server event for a given function topic (e.g topic: DrsVmPoweredOnEvent, VmPoweredOffEvent)
- The VEBA event payload structure is now conforming to the Cloud Events specification, which is a Cloud Native Compute Foundation (CNCF) project for providing a consistent event format for the industry
- Simplified and restructured the OVF property for user input, including a new drop down menu for Network Prefix (CIDR) selection which had given some folks some challenges. For those interested in automated deployments of VEBA, I have also include two sample scripts here and here that uses OVFTool for deploying VEBA demonstrating both an OpenFaaS processor example as well as AWS EventBridge
- New statistics endpoint which provides resource usage of VEBA as well as stats on the various vCenter Server events that have been invoked including total number of events processed and rate of event ingestion. This information can be useful to understand how you are using VEBA and can also help during troubleshooting when engaging with the VEBA team. You can access this endpoint on VEBA by navigating to https://[VEBA]/stats and it does require authentication (user: admin) along with the root password you had configured earlier
- Updated Sample Functions
- All existing function examples have been updated to support VEBA v0.3
- Official VMware Docker Images are now built for example functions and no longer reference individual accounts. As new examples are submitted by community, they will go through a review process and if approved, they will get VMware Docker Image
- New Python "echo" function to help figure out what a specific payload would look like from vCenter Server and enabling better function development and debugging
- New vSphere datastore usage email notification function which has been a very common request for VMware Cloud on AWS customers
John Whittingham says
So timely, I have been looking for event driven scripting solutions over the past few days. A couple of questions:
1. What is the difference between Dispatch-Solo and VEBA? To me VEBA looks like a replacement and the stand-alone method to the more scalable vision of Dispatch.
2. What is the Internet needed for in the deployment and is there any way to deploy without an internet connection. i.e. deploy to an internet connected setup and then export/import to an non-internet connected infrastructure. We run secure vCloud services and this is a big blocker at the moment.
Keep up the great work.