The IT Hollow

This year I’ve totally revamped my home lab to focus on Red Hat technologies. I joined Red Hat in November of 2025 as a Solutions Architect and now its time to dust off my lab for some blogs related to my new endeavor. I’ve repurposed some old hardware, and bought a little bit more so that I can focus more on the OpenShift platform. I’m tracking those post in this series if you care to follow along. But this post focuses on the home lab running in the basement of my house. The rack is homemade.

This post is part of a series on OpenShift as a platform. We’re looking at the container foundation here, specifically what OpenShift adds on top of upstream Kubernetes and how Operators turn that into an extensible platform for everything else we’ll cover. Kubernetes is the Engine# Kubernetes is the most widely adopted container orchestration system in the world, and OpenShift is built on top of it. But “built on top of” understates what Red Hat has done.

This post is part of the Red Hat Platform series. If you want the full picture of what we’re building toward, start there. Here we’re focused on continuous deployment using OpenShift GitOps, which is Red Hat’s supported distribution of ArgoCD. This post is really about continuous deployments of our sample Brix Pizza application. In a previous post we build a CI/CD pipeline that built our container image automatically after we made changes to the source code and committed it to git.

We’ve now reached the era where our jobs might be replaced by artificial intelligence. None of us are really immune to the impacts that AI will have on our jobs but I wasn’t expecting it to hit my household quite so soon. No, it wasn’t my tech job that was replaced … yet. It wasn’t even my wife’s job, but instead it was my dog Charlie’s career that was impacted. Yes, that’s right.

Over the past several years, I worked in marketing and spent a lot of time trying to make technical demos more compelling. The goal was always to demonstrate a capability or product feature, but there’s no reason a demo can’t also be fun, memorable, and grounded in reality. “Hello World” gets the job done, but it doesn’t feel real. It doesn’t resemble how applications are actually built, deployed, or operated. And because of that, it’s easy to forget.

Maybe it’s bougie, but one of the reasons I purchased E200-8d Supermicro Servers for my home lab was because they had IPMI built into them. Being able to remote into my lab at night when I’m messing around with different configurations was a nice to have. When I was consulting and traveling a lot, being able to remotely start my servers up was really important. I tested out things many times in my lab so that customers wouldn’t have to spend time figuring it out themselves.

Virtual infrastructure has a lot of advantages, but one of the biggest time savers is being able to provision new virtual machines quickly from a template. As part of this series we’ve covered, how to deploy harvester, how to setup a new virtual network, how to create a new virtual machine, and how to backup and restore VMs. In this post we’ll take a look at how we can create templates and deploy harvester VMs from templates.

In our previous posts we , configured the network, and deployed our first VM. Here we will explore the backup and restore options available to us from the Harvester console. If you’re new to running virtual machines on Kubernetes, you’re probably questioning a few things, like will your current VM backup tool work? The answer is maybe, but only if it is able to backup a container since our VMs are now wrapped inside of a Kubernetes Pod thanks to Kubevirt.

The installation of Harvester starts with deploying your nodes. This process would be similar to deploying ESXi hosts in a VMware deployment. To start the process, download the latest stable harvester release from their github repository. You can then mount this ISO file from your bare metal server. After booting to the iso choose the version of Harvester to deploy from their GRUB list.

I have a very soft spot in my heart for VMware. Pretty early on in my career when I was a System Administrator I got the opportunity to convert my companies physical infrastructure to a virtual infrastructure on VMware vSphere. The version of VMware we moved to, is not relevant to this discussion other than to show how truly old I am, and in order to save the parties involved some embarrassment we’ll ignore this implementation detail.