WilliamLam.com

Victron Venus OS on ESXi-Arm

by // 14 Comments

Over the weekend I received an interesting inquiry from a customer who had been playing with the ESXi-Arm Fling and wanted to know if it could run Victron Venus OS? I had never heard of Venus OS before, but a quick search online lead me to the company called Victron Energy which produces and sells various types of electrical chargers and they also have their own operating system to manage their software called Venus OS:

Venus OS is the software running on our Cerbo GX monitoring system, as well as its predecessors the Color Control GX, Venus GX and more. Also, it is in the GX versions of our MultiPlus-II  and EasySolar-II inverter/chargers.


Venus OS can be installed on a Raspberry Pi (rPI) and the customer attempted to run it as a VM using ESXi-Arm on rPI using the techniques shared here and here but found that it was unable to boot with a message stating no kernel installed.

Given this was beyond my skillset, I pinged Cyprien, who works on ESXi-Arm at VMware to see if he had any ideas? In less than 30 minutes, he not only found out the reason the previous techniques could not be used but also came up with a quick workaround. Venus OS is a 32-bit OS and is not based on Debian and this is why you can not simply boot using the Debian Installer. The solution requires a custom Arm64 linux kernel that includes UEFI support to be built and installed to be able to boot Venus OS running as a VM on ESXi-Arm. For more information, please see the detailed instructions below and big thanks to Cyprien for his help over the weekend!

[Read more...]

Publishing and consuming custom events with VMware Event Broker Appliance (VEBA)

by // Leave a Comment

One of the really exciting features that will be included in the upcoming release of the VMware Event Broker Appliance (VEBA) v0.7 release (currently in Tech Preview) is the support for incoming webhooks! This will allow customers to easily build event-driven automation for non-vSphere based events and even non-VMware events while still maintaining a consistent consumption experience. If you are interested in learning more about the upcoming VEBA v0.7 release, Michael Gasch and myself will be doing a LIVE VMworld Session - VEBA Revolutions - Unleashing the Power of Event-Driven Automation #CODE2773 that you should definitely add to your schedule builder!

Webhook support can easily be enabled during the initial VEBA appliance deployment using a few new OVF properties or configured through the VMware Event Router configuration when deploying to an existing Kubernetes cluster using kubectl or Helm. Once the webhook endpoint is running, users can simply publish their custom events as a conformant CloudEvent and VEBA will ensure these custom events are immediately available for consumption by function authors. This means any product and/or service that can construct a custom HTTP payload including headers will be able to take advantage of this new VEBA feature! I also want to mention that this is NOT the only way to produce custom events that VEBA can ingest, but is certainly one simple way.

To help make this concept more concrete, I wanted to see how we could integrate VMware Cloud events into VEBA by using this new webhook mechanism and using the VMware Cloud Notification Gateway. Below is a diagram to help illustrate what is happens when a VMware Cloud event is generated and how it can be consumed by VEBA. The beauty of this type of a solution is the "Event Producer" does not have to know anything about the "Event Consumer" or how they might consume the data. The producer simply pushes events into VEBA and if there is a consumer who cares about a specific event and wishes to do something about it, they can create a function that will listen for a specific event(s) and perform an operation like sending to Slack as an example.

  1. Event is produced by VMware Cloud and pushed by the VMware Cloud Notification Gateway (NGW)
  2. A conformant CloudEvent payload is constructed from VMware Cloud event by NGW service
  3. NGW forwards the custom CloudEvent to VEBA's webhook endpoint (https://[VEBA-FQDN]/webhook)
  4. VEBA functions can now react to these custom CloudEvents (e.g. SDDC Provisioned Event)

[Read more...]

Quick Tip - How to deploy NSX Advanced Load Balancer (NSX-ALB) with a single Service Engine

by // 1 Comment

I saw an interesting question today from Robert Kloosterhuis in the private vExpert App Modernization Slack Channel who working with vSphere with Tanzu using NSX Advanced Load Balancer (NSX-ALB) and wanted to know if it was possible to deploy NSX-ALB with just a single Service Engine (SE)?

The default behavior of NSX-ALB is to deploy two SE for availability purpose but for testing and/or homelab usage, it could certainly help with resources and time to spin up an environment using NSX-ALB. I was also curious if this was possible and reached out to NSX-ALB Engineering team and within a few minutes, I got a response that not only was this possible to do but pretty easy to configure.

To modify this default behavior, we need to update the Service Engine group prior to SE VMs being deployed. To do so, login to NSX-ALB UI and under Infrastructure->Service Engine Group and then click on the Advanced tab and change the default Buffer Service Engines value of 1 to 0 which will will have NSX-ALB deploy just a single SE VM rather than the default two.


To confirm that our NSX-ALB have been configured correctly, I have enabled vSphere with Tanzu using NSX-ALB and as you can see from the screenshot below, only a single SE VM has been deployed rather than the default behavior of two SE.