If you run VMware Cloud Foundation 9.1 nested in a homelab, VCF Automation (VCFA) is the appliance that will make your host fans spin. It ships as a single “one size fits all” deployment sized at a minimum of 24 vCPU + 96 GB RAM, and internally it’s a full Kubernetes platform. Drop that onto a modest nested host and you’ll see high CPU, contention, and – if you start “optimizing” the wrong things like me – a spectacular cascade of failures. In this blog I’ll describe my journey to get a stable and performing VCFA appliance in my homelab.
Category: VMware Page 1 of 15
In my previous blog post, I mapped out the service runtime and the army of pods that make up the prelude namespace in VCF Automation 9.1, and covered how to get a shell on the runtime. Today I put that to work on a real problem, and dig into one of the most interesting pods in the namespace.
Recently, I had a customer, where I needed to get detailed logs why a user login into a VCFA tenant organization didn’t work. There’s no button in the UI for “explain why this login failed,” so the only way forward was to get onto the box that runs Automation, find the right service, and read its logs. That service is the so-called tenant-manager.
If you’ve moved to VCF Automation 9 and gone looking for the old Aria Automation 8.x style standalone appliance you used to SSH into, you’ll have noticed that it is now a fleet-level component on a dedicated VCF services runtime, lifecycle-managed by VCF Operations. And the product does substantially more than either predecessor, i.e. it merged Aria Automation’s automation/self-service with VMware Cloud Director’s tenancy, and added cloud-native (VKS/container) consumption. Which is a lot of moving parts consolidated into one place – and it is not obvious where everything now runs. So I sat down and mapped it out in this short blog post.
A while ago my lab got itself into a properly broken state, and the quickest way out was to reinstall ESX on all the hosts and start fresh. So I did exactly that – wiped the OS, reinstalled ESX 9.1, and went straight into preparing the hosts for a new VMware Cloud Foundation deployment. And that’s where I ran into a wall: the fresh install refused to play nicely with the old vSAN disks. Errors like “vSAN partition found”, “found zero SSD devices for SSD cache tier” and disks stuck at “Ineligible for use by VSAN” kept showing up.
In this blog post, I’ll demonstrate how to quickly remove old vSAN data from an ESX host.
When you open VCF Operations, the home page greets you with a world map – and no matter where you are in the world, the map in the VCF Operations dashboard always defaults to showing the United States. For a VCF administrator running an estate in Vienna, Frankfurt, or anywhere outside the US, that can be a quiet little annoyance: the very first thing you see is a map of somewhere your kit isn’t. It is not showing your infrastructure yet; it is just the default view, asking “so where is your kit?” Telling it is a small, cosmetic-but-satisfying task, and it earns its keep the moment you run more than one site: at a glance you see which physical data centers exist and how many cloud accounts hang off each one.