VEBA

VEBA + Knative + k3s on ESXi-Arm

01/26/2021 by William Lam Leave a Comment

In response to a customer request to add Arm64 support for our VMware Event Router, I have been spending some more time playing with k3s (lightweight Kubernetes distribution for Arm) running on ESXi-Arm using a Raspberry Pi. Not only was this a good learning experience that exposed to me to the broader Arm ecosystem, which is still maturing but it also took me down several 🐰🕳️ which got me exploring new tools that I had never used before such as Buildpacks and Docker buildx to name a few.

This past weekend, I was finally successful in setting up our VMware Event Router for Arm using the Knative processor on a k3s cluster using ESXi-Arm running on a Raspberry Pi 4b 8GB model! As of writing this, the following versions were used:

Knative Serving v0.20.0
Knative Net Contour v0.20.0
Knative Eventing v0.20.1
RabbitMQ Cluster Operator v0.5.0

Made some more progress w/@KnativeProject + @VMWEventBroker on k3s on @esxi_arm

✅ Knative Serving & Eventing
✅ @RabbitMQ Operator & Eventing
✅ @projectcontour
✅ @VMware Event Router

Just need to figure out @buildpacks_io for Arm64 - https://t.co/ChdkMLSXMp looks promising pic.twitter.com/XFWDiGONSB

— William Lam (@lamw) January 24, 2021

In addition, I was able to also convert the Knative python echo function that was originally created by my colleague Michael Gasch and build an Arm64 version of the Knative python echo function which demonstrates the integration of VEBA with the Knative processor connected to a vCenter Server as my event source.

🥳 Successfully deployed & verified my arm64 python echo func w/@VMWEventBroker (Event Router) using the @KnativeProject processor!

Awesome for lightweight testing/development purposes on small VM w/k3s on @esxi_arm

Heck, don’t even need real vCenter, can run vcsim locally! pic.twitter.com/DuI16fvXfs

— William Lam (@lamw) January 24, 2021

For those interested in just the VMware Event Router Arm64 image, you can access it here and we plan to make that an official image shortly. For those interested in setting up a fully functional Arm deployment of VEBA and Knative processor, you can find the detailed instructions below.

VMware Event Broker Appliance (VEBA) v0.5.0

12/16/2020 by William Lam 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.

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

07/09/2020 by William Lam 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.

New VEBA release, new website and new mascot!

05/12/2020 by William Lam 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.

New VEBA Direct Console UI (DCUI)
New Incident Management example functions
New Golang example function
Deploy VEBA to a existing Kubernetes Cluster (documentation)
Updated VEBA base OS to latest Photon OS 3.0 Rev2
Replace Weave with Antrea CNI
Support customization of Docker bridge network (default: 172.17.0.1/16) via OVF property
Monitor VEBA Appliance using vRealize Operations (documentation)

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 to @Allan_Kjaer on finding the first hidden 🐣#EasterEgg in latest #VEBA release. Type “pride” to activate/deactivate new color scheme

Very impressive Allan, as I thought this would have taken longer & was a nice nod to original @VMwareFusion Easter Egg 😊 pic.twitter.com/d06skOglj5

— William Lam (@lamw) May 13, 2020

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.

Congrats @bib_ds on finding the last and final #VEBA #EasterEgg which is dedicated to our new mascot #OttoTheOrca

I’m sure colleagues will take a second look when they see 🐳 in the VM Summary page 😉 https://t.co/JaDUFkQ7fi

— William Lam (@lamw) May 13, 2020

Integrating vCenter Event Broker Appliance (VEBA) with vRealize Orchestrator

03/19/2020 by William Lam 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

03/10/2020 by William Lam 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