AI Collab Score: 7 / 3

I am currently pursuing my degree in Artificial Intelligence, and one of the things I enjoy most about the coursework is taking what we are learning academically and testing it in my own AI lab.

This week, one of my classes focused on cloud-based AI platforms. We experimented with Amazon Rekognition and Google AI Studio to compare how cloud services can analyze images, what kinds of results they return, and how their approaches differ.

That naturally led me to another question:

What happens if I move that same general image-understanding capability out of the cloud and run it locally?

I already have a home AI lab built for exactly this kind of experimentation, so I decided to find out.

Figure 1. AI Lab Live Vision running locally on Ubuntu. Webcam frames are analyzed by a locally hosted Qwen vision-language model through Ollama and ROCm.

For the lab, I built a browser-based vision application that captures an image from a webcam and sends it to an AI model running entirely on my local workstation.

My current lab includes:

• Ubuntu Linux
• AMD Radeon AI PRO R9700 with 32 GB of VRAM
• ROCm for AMD GPU acceleration
• Ollama for hosting models locally
• OpenCV for webcam capture
• Flask for the browser-based application
• Qwen3-VL 4B
• Qwen3.5 27B
• Open WebUI for interacting with locally hosted models

​The basic architecture looks like this:

AI Collab Score: 7 / 3

How I used Ubuntu, OpenCV, Ollama, Gemma 3 Vision, and Python to build a local vision pipeline with memory, event filtering, and stability logic.

Most AI vision demos stop at image description.

A webcam captures an image, a vision model analyzes it, and the system prints something like: “A person is sitting at a desk.”

That is useful as a proof of concept, but it does not behave like an agent.

A real vision agent needs more than perception. It needs state. It needs memory. It needs event logic. It needs to know what changed, whether the change matters, and whether the change is stable enough to trust.

That became the goal of this lab.

I built a local AI Vision Agent that starts with a live webcam feed and evolves into a small event-driven vision system. It runs locally on Ubuntu using Python, OpenCV, Ollama, and Gemma 3 Vision.

By the current version, the agent can confirm events like:

• person entered
• person left
• phone appeared
• mug disappeared
• laptop appeared

​The important part is not just that the model can describe what it sees. The important part is the system built around the model that turns raw vision output into confirmed events.

AI Collab Score: 7 / 3

Last year, I documented my first NVIDIA AI Workbench installation on a repurposed workstation. That project was about validating CUDA, cuDNN, PyTorch, and GPU acceleration. It proved that an older workstation could become a capable local AI development platform.

This rebuild had a different purpose.

I did not want to recreate a collection of global Windows installs and hope every framework, runtime, and dependency remained compatible over time. I wanted to build a modular local AI lab that more closely resembles the technical layers enterprise teams must eventually design, secure, operate, and scale.

The result is a lean open-source AI stack built around Windows 11, WSL2, Docker Desktop, Ollama, and Open WebUI.
​
More importantly, it gave me a practical answer to a question many people have:

AI isn’t something you’ll “learn someday.” It’s already shaping college, careers, and the workplace.

If you’re preparing for college or entering the real world in the next few years, becoming AI-literate gives you a serious advantage.
​
The good news? You can start today — for free.

Colleges are integrating AI into research, writing, and analysis.
Companies expect employees to understand and work with AI tools.

​The future won’t belong to people who avoid AI.
It will belong to people who understand how to use it responsibly and effectively.

AI Collab Score: 9 / 2 ​

When it comes to scaling tenant-ready automation on VMware Cloud Foundation, every infrastructure team hits the same wall: onboarding new tenants is either too manual or too brittle. We built the Tenant Onboarding Workflow Builder to change that.

This drag-and-drop simulation tool lets you rapidly prototype and export tenant onboarding workflows—no PowerCLI experience or YAML syntax memorization required. Whether you're provisioning a namespace, configuring NSX segments, or triggering an ArgoCD sync, this tool helps you visualize the automation flow and export it into formats that plug directly into your GitOps pipelines.

This tool ties directly into the topics we’ve covered in the VCF Automation Blog Series, especially around:

• GitOps-based lifecycle automation
• Role-based access control for multitenant environments
• DevSecOps-ready onboarding blueprints for your platform team

​Let’s walk through how it works—and how it can help you simplify tenant activation, reduce manual error, and enforce governance from day one.

VCF Automation Series:

• This Is the Missing Piece in Your VCF 9.0 Automation Strategy: Red Hat Ansible
• STOP Deploying VCF Wrong: Unlocking Tenant-Ready Workflows with GitOps & CI/CD
• STOP! Your VCF Automation Is a Security Time Bomb (Unless You Do THIS)

AI Collab Score: 9 / 3 

Part 3 of our VCF 9.0 Automation Series

VMware Cloud Foundation (VCF) 9.0 has redefined private cloud automation. With full-stack automation powered by Ansible and orchestrated through vRealize Orchestrator (vRO), and version-controlled deployments driven by GitOps and CI/CD pipelines, teams can build infrastructure faster than ever.

Enter RBAC and policy enforcement.
This third and final installment in our automation series focuses on how to secure and govern multi-tenant environments in VCF 9.0 with role-based access control (RBAC) and layered identity management.

AI Collab Score: 10 / 2 ​

If you're running VMware Cloud Foundation without GitOps and CI/CD integration, you're not operating a cloud platform — you're operating a cluster.

VCF 9.0 Automation gives us a powerful foundation for multi-tenant self-service infrastructure. But to operate like a true internal platform-as-a-service, we need:

• Version control of blueprints and workflows
• Consistent deployment across environments
• Integrated approval and testing processes

This is where GitOps and CI/CD pipelines come in. By storing VCF Automation blueprints, Aria Orchestrator workflows, and even Ansible playbooks in Git—and connecting them to your CI/CD tooling—you bring repeatability, collaboration, and traceability into the heart of your private cloud.

For those who prefer a high-level walkthrough, I’ve created a short video explaining the operating model shift outlined in this article.
​
Watch the overview below, or continue reading for the detailed architecture discussion.

AI Collab Score: 10 / 2 

​Part of the VCF Automation Series: Tenant-Ready Workflows at Scale

VMware Cloud Foundation 9.0 marks a major leap toward a true private cloud platform—with built-in multi-tenancy, automated provisioning, and extensible workflows via external Orchestrator instances. But there's still one critical gap many platform teams face:

That’s where Red Hat Ansible becomes the missing piece.
This post shows how to integrate Ansible with VCF 9.0 Automation to deliver:

• Full-stack automation from VM to application
• Tenant-scoped workflows via external vRO instances
• Post-deployment actions like patching, agent installation, and OS hardening
• GitOps-friendly, repeatable playbook execution
• RBAC and policy enforcement across tenants

If you're building a cloud platform on VCF 9.0, this integration is not just nice-to-have—it's essential.

Provisioning automation alone does not create a stable platform.
​
I created a companion video to explain how Red Hat Ansible integrates into VMware Cloud Foundation 9.0 as the lifecycle governance layer — enforcing state, validating compliance, and stabilizing Day-2 operations.

Watch the overview below, or continue reading for the full discussion of the architecture.

In any VMware environment, snapshots are powerful but risky tools. They're great for backups or quick rollback points during updates, but leaving them for too long can seriously degrade performance, consume excessive datastore space, and even cause backup failures.

Tools like RVTools give you visibility into your snapshots, but wouldn’t it be better if you could automate the process and be proactively alerted when snapshots become a problem?

​That’s exactly what we’ll do in this blog—let’s build a PowerCLI script that checks for old snapshots and alerts you automatically.

Snapshots are meant to be temporary. VMware recommends deleting them within 24–72 hours in most production environments. However, admins often forget to clean them up—especially in environments with multiple teams or large numbers of VMs.

Leaving snapshots too long can result in:

• Slower VM performance
• Datastores filling up unexpectedly
• Failed backup jobs
• Risky system state assumptions

​VMware Cloud Foundation 5.2.1 brings a suite of enhancements aimed at making lifecycle management more efficient, improving flexibility in cluster upgrades, and preparing your infrastructure for AI and modern apps. If you're running a hybrid environment, or prepping for GPU-enabled workloads, this is a release you’ll want to master.