Tools: Build Your Own Lab: Virtualization for DevOps Beginners

Tools: Build Your Own Lab: Virtualization for DevOps Beginners

What We'll cover?

Setting Up a Lab on Your Laptop

What Is a Home Lab, and What Can You Do in It?

Virtualization software

Installing VirtualBox on Linux Mint 22.3 (Zena)

Setting Up Your First VM in VirtualBox

Connecting to Your VM

Three Ways to Start a VM

SSH Into a Linux VM

Networking: Bridged vs NAT There are two main options for practicing DevOps: set up a lab on your local machine, or spin up cloud VMs on AWS, Azure, or GCP. We will focus on the home lab — using a laptop or desktop you already own. It gives you full control, costs nothing extra, and you can use virtualization software like VirtualBox to create and manage virtual machines right on your hardware. Imagine your laptop is a studio apartment. Now imagine you're trying to run a full restaurant kitchen, a woodworking shop, and a recording studio — all in that same apartment. Things are going to get messy. That's what happens when you install every DevOps tool directly on your machine: Git, Jenkins, Docker, Kubernetes, Ansible, Python, Java, Node.js, Apache, Nginx, MySQL, MongoDB, AWS CLI, Ubuntu, CentOS... they all start stepping on each other. Different versions conflict. Something breaks. You don't know what you did. You're afraid to change anything. Virtual machines are the solution. Think of each VM as a separate apartment in the same building. Same physical hardware underneath, but completely isolated from each other. If one apartment burns down (a VM breaks), the others are fine. You just rebuild that one. Virtualization software (also called a hypervisor) sits between your physical hardware and your virtual machines, letting multiple operating systems run on the same machine simultaneously. Type 1 — Bare-metal Hypervisor: This runs directly on the hardware, with no host OS underneath. Think of it as the hypervisor being the operating system. Examples: VMware ESXi, Microsoft Hyper-V, Xen. These are used in enterprise environments where you need high performance and dozens (or hundreds) of VMs. They're powerful, but expensive and complex. Type 2 — Hosted Hypervisor: This runs on top of your regular OS (host) — like any other application you install. Examples: Oracle VirtualBox, VMware Workstation, Parallels Desktop. These are perfect for home labs and development environments. Easier to set up, free or cheap, and more than capable for learning. However, they may have performance overhead due to running on top of a host operating system. Reference: https://www.facebook.com/photo/?fbid=122115084969253388&set=gm.1847442505941341&idorvanity=192962784722663 We will be using Type 2 hypervisor, specifically Oracle VirtualBox, for our home lab environment. Here's a quick comparison if you're choosing between the two popular options: For Windows and macOS installation, refer to the YouTube video in the Reference section below. I use Linux Mint, so I'll walk through that. You can check your OS details with: Linux Mint 22.3 is based on Ubuntu 24.04 LTS (noble), so we use the noble VirtualBox repository. Step 1 — Add the Oracle VirtualBox repository key: Step 2 — Add the repository: Step 3 — Install VirtualBox: Step 4 — Verify the installation: For the latest version and other Linux distributions, check the official site: https://www.virtualbox.org/wiki/Linux_Downloads Click New to create a virtual machine. Follow the prompts — choose your OS, allocate memory (at least 2GB recommended for Linux, though 1GB works for lightweight setups), and set up a virtual hard disk. You have two options here: install the OS manually via an ISO (like inserting a CD), or use a pre-configured VM image that already has the OS installed. I prefer the second approach — it saves time. You can find pre-built images at osboxes.org. Download the .7z file from osboxes.org, extract it, and you'll get a .vmdk file — that's the virtual hard disk. When the wizard asks for a hard disk, select "Use an existing virtual hard disk file" and point it to the .vmdk file you extracted. Before starting the VM, right-click it → Settings → Network → set the adapter to Bridged Adapter. This allows the VM to connect to the same network as your host machine and enable the VM to have its own IP address and access the internet. Once the virtual machine is created, start in Normal Start. Log in with the default credentials from osboxes.org (username: osboxes, password: osboxes.org). Now your VM is running. But how do you actually talk to it? Think of VMs like tenants in a building. Just because they share the same physical building (your laptop) doesn't mean they can walk into each other's apartments freely. They need proper addresses and open doors. Normal Start — Opens a console window with the VM's UI. Closing the window shuts down the VM. Good for initial setup. Headless Start — VM runs in the background with no window. You access it only via SSH or remote desktop. This is the DevOps way. Detachable Start — Like Normal Start, but closing the console window doesn't shut down the VM. It keeps running in the background. For Linux guest VMs, SSH is your main tool. For Windows guests, you'd use Remote Desktop (RDP). Even the vms are within our laptop (host) think of them as separate machines connected to the same network so whatever you need for one system to connect to another system you would need these vms configured with ip addresses and the relevant services must be configured and running on. On windows, the remote desktop service needs to be running and on linux the ssh service needs to be running so make sure ssh server is installed and is in a running state in the vm (guest system). If configured you can ssh into the vm from the host system using the terminal on the host and the ip address of the remote vm. To SSH in from your host machine: If you can't connect, check these first: This is where a lot of beginners get confused. Let's use an analogy. Bridged Adapter is like giving your VM its own room in the house with its own doorbell. It gets a real IP address on your network. Anyone on your local network can reach it. SSH is straightforward: NAT (Network Address Translation) is like the VM living in a back room with no direct doorbell — it can call out (access the internet), but nobody outside can call in directly. If you have multiple NAT VMs, they're also isolated from each other (they all get the same internal IP and can't see each other). To SSH into a NAT VM, you need port forwarding — you tell VirtualBox: "whenever someone knocks on my host machine's port 2222, forward that knock to port 22 on the VM." Set it up in VirtualBox:

Settings → Network → Advanced → Port Forwarding → Add Rule (We use port 2222 on the host because port 22 is already used by the host's own SSH service.) This is part of my DevOps Prerequisite series: Disclaimer: I have used GH copilot for writing the topics, Gemini Nano Banana for image generation, ChatGPT for the html snippet & other concepts and Claude for fine tuning the entire blog. Reference:💡 Want a visual walkthrough?

This video does a great job explaining the basics covered here. Use it as a supplement—not a replacement: Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse

Command

Copy

$ cat /etc/os-release cat /etc/os-release cat /etc/os-release -weight: 500;">wget -O- https://www.virtualbox.org/download/oracle_vbox_2016.asc | \ -weight: 600;">sudo gpg --yes --output /usr/share/keyrings/oracle-virtualbox-2016.gpg --dearmor -weight: 500;">wget -O- https://www.virtualbox.org/download/oracle_vbox_2016.asc | \ -weight: 600;">sudo gpg --yes --output /usr/share/keyrings/oracle-virtualbox-2016.gpg --dearmor -weight: 500;">wget -O- https://www.virtualbox.org/download/oracle_vbox_2016.asc | \ -weight: 600;">sudo gpg --yes --output /usr/share/keyrings/oracle-virtualbox-2016.gpg --dearmor echo "deb [arch=amd64 signed-by=/usr/share/keyrings/oracle-virtualbox-2016.gpg] https://download.virtualbox.org/virtualbox/debian noble contrib" | \ -weight: 600;">sudo tee /etc/-weight: 500;">apt/sources.list.d/virtualbox.list echo "deb [arch=amd64 signed-by=/usr/share/keyrings/oracle-virtualbox-2016.gpg] https://download.virtualbox.org/virtualbox/debian noble contrib" | \ -weight: 600;">sudo tee /etc/-weight: 500;">apt/sources.list.d/virtualbox.list echo "deb [arch=amd64 signed-by=/usr/share/keyrings/oracle-virtualbox-2016.gpg] https://download.virtualbox.org/virtualbox/debian noble contrib" | \ -weight: 600;">sudo tee /etc/-weight: 500;">apt/sources.list.d/virtualbox.list -weight: 600;">sudo -weight: 500;">apt-get -weight: 500;">update -weight: 600;">sudo -weight: 500;">apt-get -weight: 500;">install virtualbox-7.1 -weight: 600;">sudo -weight: 500;">apt-get -weight: 500;">update -weight: 600;">sudo -weight: 500;">apt-get -weight: 500;">install virtualbox-7.1 -weight: 600;">sudo -weight: 500;">apt-get -weight: 500;">update -weight: 600;">sudo -weight: 500;">apt-get -weight: 500;">install virtualbox-7.1 virtualbox --help virtualbox --help virtualbox --help # Check SSH -weight: 500;">status on the VM -weight: 500;">service sshd -weight: 500;">status # Start SSH if it's not running -weight: 500;">service sshd -weight: 500;">start # Check SSH -weight: 500;">status on the VM -weight: 500;">service sshd -weight: 500;">status # Start SSH if it's not running -weight: 500;">service sshd -weight: 500;">start # Check SSH -weight: 500;">status on the VM -weight: 500;">service sshd -weight: 500;">status # Start SSH if it's not running -weight: 500;">service sshd -weight: 500;">start ssh username@ip_address ssh username@ip_address ssh username@ip_address ssh username@vm_ip_address ssh username@vm_ip_address ssh username@vm_ip_address ssh [email protected] -p 2222 ssh [email protected] -p 2222 ssh [email protected] -p 2222 - Setting up your lab (laptop vs cloud) - Virtual Box Deploying VMs - Deploying VMs - Deploying VMs - Run different OS versions (Ubuntu, CentOS, Red Hat) side by side - Isolate tools and projects so they never interfere - Snapshot a working state and roll back if something goes wrong - Delete and recreate freely — no fear - Open VirtualBox from your applications menu. - Click New to create a virtual machine. - Follow the prompts — choose your OS, allocate memory (at least 2GB recommended for Linux, though 1GB works for lightweight setups), and set up a virtual hard disk. You have two options here: -weight: 500;">install the OS manually via an ISO (like inserting a CD), or use a pre-configured VM image that already has the OS installed. I prefer the second approach — it saves time. You can find pre-built images at osboxes.org. - Download the .7z file from osboxes.org, extract it, and you'll get a .vmdk file — that's the virtual hard disk. - When the wizard asks for a hard disk, select "Use an existing virtual hard disk file" and point it to the .vmdk file you extracted. - Before starting the VM, right-click it → Settings → Network → set the adapter to Bridged Adapter. This allows the VM to connect to the same network as your host machine and -weight: 500;">enable the VM to have its own IP address and access the internet. - Once the virtual machine is created, -weight: 500;">start in Normal Start. - Log in with the default credentials from osboxes.org (username: osboxes, password: osboxes.org). - Normal Start — Opens a console window with the VM's UI. Closing the window shuts down the VM. Good for initial setup. - Headless Start — VM runs in the background with no window. You access it only via SSH or remote desktop. This is the DevOps way. - Detachable Start — Like Normal Start, but closing the console window doesn't shut down the VM. It keeps running in the background. - An IP address assigned - SSH -weight: 500;">service running Use the console window to do your initial configuration first — get the IP set, -weight: 500;">start SSH. After that, you can switch to your host terminal for everything else. - Does the VM have an IP address? - Are you using the correct IP? - Is the SSH -weight: 500;">service running on the VM? - DevOps Prerequisite #1: Linux Basics You Actually Need - Build Your Own Lab: Virtualization for DevOps Beginners (this post) - Why Vagrant Still Matters (and When It Doesn’t) (next) - Networking for DevOps: The Only Concepts You Need - YAML Explained for Future DevOps Engineers