Building a Local Red Hat Lab for Learning and Testing: From Idea to Environment

1. Introduction and Context

Hands-on learning is one of the best ways to really understand how systems work. Red Hat Enterprise Linux (RHEL) can seem out of reach for new users because it usually sits behind subscriptions or enterprise environments, but with the free Red Hat Developer program, it’s completely possible to build your own local lab for learning and testing.

This guide walks through how to create a small, self-contained lab environment using Red Hat’s developer subscription. It’s perfect for anyone who wants to explore RHEL — from beginners learning the basics to engineers, administrators, or developers building and testing new configurations.

The best part is that this approach doesn’t rely on cloud providers like AWS or vCenter. Everything runs locally, so you can work offline or in environments where external access is limited.

2. Tools of the Trade

This lab uses three main tools that work together to automate and manage your environment: Packer, Vagrant, and VirtualBox.

Packer handles the image creation process. It installs RHEL automatically using a Kickstart file and prepares a clean base image that can later be used by Vagrant. Because Packer uses configuration files, you can easily version control them, share them, and rebuild images consistently.

Vagrant is what actually launches and manages the virtual machines. It takes the RHEL image that Packer builds and uses it to spin up one or more lab machines. It also supports provisioning tools like Ansible, though this guide focuses on getting the base environment running.

VirtualBox serves as the platform where all of this runs. Think of it as the vessel that holds your lab. Other providers can be used, but VirtualBox is the most accessible and works across Linux, macOS, and Windows hosts.

Packer and Vagrant both use plain-text configuration files, which makes them flexible and easy to adjust. You can make small or large changes, track them in version control, and share them with others without needing complex GUIs or manual steps.

Packer utilizes Kickstart files for RHEL, so anything you build here can easily be adapted for production installs or replicated in a larger environment.

3. Setting Up the Prerequisites

Before starting, make sure you have the required tools installed on your system.

Required Software

• Packer
• Vagrant
• VirtualBox
• Git (Git for Windows or standard package manager git for Linux/Mac OS)

You must also have a Red Hat Developer account to download RHEL and access software repositories. If you don’t already have one, you can create one for free at https://developers.redhat.com. Make sure to read and understand the terms and conditions before continuing.

NOTE: Windows requires a little more setup for Packer. A quick example will be shown in the getting started section below.

Tested Versions

This setup has been tested successfully with RHEL 8 and RHEL 9.

4. Getting Started with the Example Lab (labctl)

Now that everything is installed, it’s time to get hands-on and start building the lab environment.

For this walkthrough, we’ll use a small project called labctl. This is a project that I have created on GitHub based off of other more specific labs I’ve created in the past. The name came from the idea of having a simple control utility for managing a lab environment, something in the spirit of systemctl but for building and managing your own Red Hat lab. It’s not a product or framework, just a resource meant to show how easily a local RHEL lab can be built, rebuilt, and customized.

Windows Setup (skip for Linux/Mac OS)

It is assumed you have installed Vagrant, VirtualBox and Git for Windows. Packer downloads as an executable so you will need to extract the archive and then move the packer binary somewhere. Open Git Bash and you will use this for Windows for the rest of the steps in this blog.

# Extract packer archive
$ cd ~/Downloads && unzip packer_1.14.2_windows_amd64.zip
# Make directory for packer and mv binary to that path
$ mkdir -p ~/Packer/bin && mv packer.exe ~/Packer/bin/
# Set Packer in your path and source the file
$ echo "export PATH=\\"\\$PATH:/c/Users/$(whoami)/Packer/bin\\"" >> ~/.bash_profile && source ~/.bash_profile

NOTE: You should now be able to follow the rest of this tutorial with the bash type commands.

Cloning the Project

Clone the repository from GitHub and switch into the project directory.

git clone <https://github.com/notjustanyjoe/labctl.git>
cd labctl

The repository is organized into directories for Packer, Vagrant, and Ansible. Each part handles a specific stage of the lab setup: building images, creating virtual machines, and optionally provisioning them. Together, they make it easy to create, destroy, and rebuild your RHEL lab in a consistent way.

Preparing the RHEL ISO

Next, you’ll need a RHEL installation ISO to use as the base for your build.

1. Download the RHEL DVD ISO and copy the checksum for your desired version (8 or 9) from https://access.redhat.com/downloads/content/rhel Click on “Show details” and then copy the SHA-256 Checksum.
2. Create a directory for the ISO and move it into place. mkdir -p packer/iso mv ~/Downloads/rhel-9.*-x86_64-dvd.iso packer/iso/
3. Copy one of the example variable files and edit it for your version. cd packer cp rhel9.pkrvars.hcl.example rhel9.pkrvars.hcl # Edit iso_path and iso_checksum to match your downloaded ISO vim rhel9.pkrvars.hclcd ..

These variable files make it easy to switch between RHEL versions or adjust settings without touching the main configuration.

One-Time Vagrant Registration Setup

When the lab machines come online, they need to register with Red Hat’s Content Delivery Network (CDN) so they can access the BaseOS and AppStream repositories. To make that happen automatically, we need to set a few variables that include your Red Hat Developer Organization ID and Activation Key.

The setup script takes care of this step by prompting for those values and then creating a configuration file that works with the vagrant-registration plugin. Once configured, this allows every new Vagrant machine to register automatically with your developer subscription when it boots.

If you don’t already have an activation key:

1. Go to https://console.redhat.com/insights/connector/activation-keys
2. Log in with your Red Hat Developer account
3. Create a new key and set the following:
   • Role: Red Hat Enterprise Linux Workstation
   • SLA: Self-Support
   • Usage: Development/Test
4. Note your Organization ID and Activation Key name, as you’ll need them for the next step.

Now run the registration setup script to generate your global Vagrant configuration.

# WINDOWS ONLY must run this command first to convert the file to LF
sed -i 's/\\r$//' vagrant-plugins.list

# Run Script for setup
./scripts/setup-vagrant-registration.sh

Note: You only need to do this once unless your Organization ID or Activation Key changes.

Once this is done, you’re ready to build your RHEL base image with Packer.

5. Building the Base Image with Packer

With the RHEL ISO and registration settings ready, we can build the first image. Packer will handle the heavy lifting here by automating the installation process using a Kickstart file.

Inside the packer directory, there’s a main configuration file called rhel.pkr.hcl. This file tells Packer what builder to use, where the ISO is located, how much memory and CPU to assign, and what scripts to run after installation. The Kickstart file under packer/http/ks.cfg defines the actual installation steps, including creating the vagrant user and enabling SSH access.

To start the build process, run the following commands from inside the packer directory:

cd packer
packer fmt .
packer init .
packer validate -var-file=rhel9.pkrvars.hcl rhel.pkr.hcl
packer build -var-file=rhel9.pkrvars.hcl rhel.pkr.hcl

# Windows May get a prompt for allowing networking. Not selecting this can cause the build to fail

Packer will boot the virtual machine using the RHEL ISO and automatically go through the installation defined in the Kickstart file. Once installation is complete, the prepare and cleanup scripts will run, finalizing the system and packaging it as a Vagrant box.

When the build completes, you’ll find the finished box file under packer/builds/. This file contains the complete RHEL image that Vagrant will use to launch lab machines.

If you ever want to make changes, you can edit the Kickstart file or one of the scripts and rebuild. Since everything is configuration-driven, you can quickly test changes and keep everything version controlled.

6. Spinning Up the Lab with Vagrant

Now that Packer has finished building the RHEL image, the next step is to bring the lab online with Vagrant. This is where everything starts to feel real, as you’ll finally see your RHEL machines boot up and become accessible.

Inside the vagrant directory, you’ll find the Vagrantfile that defines what machines to create, how much memory and CPU to assign, and what network they will use. The default setup creates a small two-machine lab that includes a control node and a managed node. The hostnames and IP addresses are set in the Vagrantfile, so you can easily modify them if you want to expand the lab or fit it into a specific network layout. You can also increase CPU, memory, or disk allocations if your system has the resources to handle it.

The default lab includes the following machines:

To start the lab, run:

cd ../vagrant
vagrant up

# Windows May get a prompt for allowing networking. Not selecting this can cause vagrant to fail

Vagrant will import the RHEL box that was built by Packer, create each virtual machine, and configure their network settings. During this process, the vagrant-registration plugin will automatically register the systems with your Red Hat Developer subscription so they can reach the BaseOS and AppStream repositories.

Once the machines are up, you can check their status with:

vagrant status

Once the lab is running, both machines should be registered, reachable by hostname, and ready for use. From here, you can test configuration management tools, practice with RHEL administration, or even build your own small automation environment. Once logged into the machine(s), you can elevate and do any type of install, configuration change and testing that you want.

To connect to one of the machines, use:

vagrant ssh <hostname>

7. Cleaning Up and Rebuilding

Once you’ve finished experimenting in your lab, you can easily tear it down and rebuild it from scratch. This makes it safe to test configurations or changes without worrying about breaking anything permanently.

When you’re ready to remove the current environment, run:

cd vagrant
vagrant destroy -f

This command removes all of the virtual machines defined in the Vagrantfile. The vagrant-registration plugin will automatically unregister the systems from your Red Hat Developer subscription during cleanup, so your account stays tidy.

If you ever want to start fresh, bring the environment back up with the same command as before:

vagrant up

Since everything is defined in configuration files and built with automation, the entire lab can be recreated in just a few minutes. You can rebuild it as many times as you want without needing to reinstall anything manually.

This repeatable workflow is one of the main benefits of having your own local lab. You can try something new, break it, learn from it, and then rebuild it cleanly whenever you’re ready to start over.

8. Lessons Learned and Next Steps

Building a small, local lab like this might seem simple at first, but it offers a lot of practical value. Whether you are just starting with Red Hat Enterprise Linux or you work with it every day, having a space to safely test ideas can make a huge difference.

By combining tools like Packer, Vagrant, and VirtualBox, you’ve created a fully reproducible environment that can be built, used, and rebuilt on demand. Everything is defined as code, which means you can version control it, share it, and make changes without starting over. It’s a lightweight but realistic setup that mirrors many of the same patterns used in enterprise automation and infrastructure management.

This kind of environment is a great starting point for learning configuration management, testing Kickstart files, or trying out new system configurations before deploying them to production. It also provides a place to experiment freely with RHEL without worrying about downtime, broken configurations, or limited cloud resources.

If you want to take this further, here are a few directions you can explore:

• Add more machines to simulate multi-node environments
• Customize the Kickstart file for more complex installations
• Experiment with other providers such as VMware or Libvirt
• Integrate additional automation tools like Ansible or Puppet
• Automate DISA STIG items using the official DISA Ansible roles for RHEL to test compliance and hardening procedures

No matter how far you decide to go, the process you’ve set up here lays a solid foundation for ongoing learning and experimentation. The goal is not just to have a working lab, but to have a place where you can keep improving, testing, and discovering new ways to use RHEL in your own workflow.

9. Closing Thoughts

Setting up a local Red Hat lab doesn’t have to be complicated or expensive. With a few tools, a bit of patience, and some curiosity, you can build a reliable environment that helps you learn, test, and explore at your own pace.

The goal of labctl isn’t to reinvent the wheel, but to make it easier for anyone to get started with RHEL — whether you’re a student, an admin, or an engineer looking for a place to test changes before they go live. By using freely available tools like Packer, Vagrant, and VirtualBox, you can build an environment that feels professional but stays fully under your control.

It’s easy to forget how much can be learned just by breaking things, fixing them, and trying again. That’s the real value of having a lab like this — a safe space to experiment, learn, and build confidence without risk or cost.

If this walkthrough helped you get started, explore the project, make it your own, and share what you build. Every improvement or experiment adds to what others can learn too.