Where this started - From Concept to Reality

This post builds directly on Monitoring Virtual Machines with Knative Eventing, an article I co-authored with my colleague Matthias Weßendorf on the official Knative blog a while ago. That post lays out the “what” and “why” nicely and concisely. Consider this one the deeper, hands-on, OpenShift-flavored companion with reproducible manifests you can copy-paste straight into your own cluster, plus a new addition that wasn’t part of the original article at all.

From an Inherited Session in Hamburg to This Post

Last week I stood on stage at ContainerDays 2026 in beautiful Hamburg with a talk titled “Bootable Containers: An entire OS as a Containerfile”, a session I “only” inherited from my esteemed colleagues Cedric Clyburn and Paulo Menon, who unfortunately couldn’t make it to the event. I promised them I’d give it my very best 😅, and I shared the story on LinkedIn if you want the full context.

Why Disconnected OpenShift

Not every customer environment gets to talk to the internet. Highly regulated industries, air-gapped data centers, or simply a customer’s security policy can mean that an OpenShift cluster has to be built and operated without any direct internet connectivity at all.

OpenShift is designed to perform many automatic functions that depend on an internet connection, such as retrieving release images from a registry or retrieving update paths and recommendations for the cluster. Without a direct internet connection, you must perform additional setup and configuration for your cluster to maintain full functionality in the disconnected environment.

I'm looking back on my first year at Red Hat. I feel genuinely grateful to be part of something that’s not only big in scale, but truly meaningful in impact. Red Hat isn’t just “another tech company” to me! It’s a place where open source, community, and collaboration aren’t slogans on a slide deck, but the way we actually work every day.

Avi Portal - Bad Service

Oh my! I wasn’t expecting a three-part series as an outcome of my recent homelab crash, but here we are 😄 Check out my recent posts Database Resurrection - Reviving vPostgres DB on VMware vCenter Server and Fixing vCenter Postgres Archiver Service - Dead Postgres Replication Slot on my made experiences with recovering the vCenter Server database.

Actually, I thought I was “out of the woods” with fixiing the broken but unfortunately my Avi Controller was also affected from the outage.

Of course I run Backups 🤥

This time I had luck with the outcome of my recent homelab crash. If I weren’t able to fix my broken vCenter Server, as described in my previous article, I would have had to reinstall my vSphere (+ vSAN, + Tanzu) environment basically from scratch again.

Is this actually true?

Actually NO! Because if I would have configured my vSphere environment correctly, vCenter Server file-based backup were configured properly and I wouldn’t have had to worry about the consequences in the end.