Install a Linux Server VM in VirtualBox or VMware
You will install a headless Ubuntu Server virtual machine you can break and rebuild freely, the safe foundation for every other server lab. By the end you will have a reachable VM with a clean snapshot to roll back to.
Learning Objectives
- Create and boot a Linux server VM from an ISO.
- Configure bridged networking so the VM is reachable over SSH.
- Capture a clean snapshot you can restore in seconds.
- Time: ~1 hour · Difficulty: Beginner · Prereqs: a host with 4GB+ free RAM and virtualization enabled in BIOS.
Architecture Overview
Environment Setup
You will need:
- VirtualBox 7.x (virtualbox.org) or VMware Workstation.
- The Ubuntu Server 22.04 ISO.
- Virtualization (VT-x/AMD-V) enabled in your host BIOS.
Before you begin: confirm you have 4GB+ free RAM and 20GB free disk.
Prerequisites
- VirtualBox or VMware installed on a host with virtualization extensions enabled.
- An Ubuntu Server 22.04 (or similar) ISO image downloaded.
- At least 2 vCPU, 4 GB RAM, and 20 GB disk to allocate to the guest.
- A LAN with DHCP if you want bridged networking in step 4.
Step-by-Step Execution
createvm alone only registers an empty VM definition: no RAM, no CPUs, no NIC, no storage controller, no disk, and no boot order. Each of those must be provisioned explicitly, which is what the commands below do.
REGISTER THE VM DEFINITION
VBoxManage createvm --name ubuntu-srv --ostype Ubuntu_64 --registerExpected output:
Virtual machine 'ubuntu-srv' is created and registered.
UUID: 7d2e9a41-...Give the VM its hardware: 2 vCPUs, 4 GB RAM, a bridged NIC using the paravirtualized virtio adapter, and a boot order that tries the DVD before the disk. List the host adapters first and substitute your active physical NIC for the placeholder.
ASSIGN CPU, RAM, NETWORK, AND BOOT ORDER
VBoxManage list bridgedifs | grep -i "^Name:"
VBoxManage modifyvm ubuntu-srv --memory 4096 --cpus 2 \
--nic1 bridged --bridgeadapter1 "Intel(R) Ethernet Connection" \
--nictype1 virtio --boot1 dvd --boot2 disk --boot3 none --boot4 noneCreate the SATA storage controller and the 20 GB virtual disk, then attach the disk to it. Dynamically allocated is the default variant, so the .vdi starts small and grows to at most 20 GB (--size is in megabytes).
CREATE THE SATA CONTROLLER AND 20 GB DISK
VBoxManage storagectl ubuntu-srv --name SATA --add sata --controller IntelAhci
VBoxManage createmedium disk --filename "$HOME/VirtualBox VMs/ubuntu-srv/ubuntu-srv.vdi" --size 20480 --format VDI
VBoxManage storageattach ubuntu-srv --storagectl SATA --port 0 --device 0 --type hdd --medium "$HOME/VirtualBox VMs/ubuntu-srv/ubuntu-srv.vdi"What this teaches: createvm registers the definition; modifyvm, storagectl, createmedium, and storageattach provision the actual hardware. Skipping the controller is why a bare createvm followed by storageattach fails.
Attach the ISO as a virtual DVD on the SATA controller created in step 01 (there is no IDE controller, so the old --storagectl IDE form fails). Then start the VM headless and run the guided Ubuntu installer, where you set hostname, user, and OpenSSH.
VBoxManage storageattach ubuntu-srv --storagectl SATA --port 1 --device 0 --type dvddrive --medium /path/to/ubuntu-22.04-live-server.iso
VBoxManage startvm ubuntu-srv --type gui
What this teaches: the guided installer needs a console, so start the VM with the GUI frontend (--type gui, the default). Headless mode (--type headless) shows no window and is only useful after installation, once you reach the guest over SSH; starting headless here would leave you with no way to see the installer.
Expected output:
(no output on success; confirm with: VBoxManage showvminfo ubuntu-srv | grep -i "SATA")What this teaches: Attaching the ISO as a virtual DVD makes the firmware boot the installer (boot1 dvd was set in step 01); the guided flow sets hostname, user, and OpenSSH in one pass.
After the installer finishes and the VM powers off, detach the ISO so the next boot uses the virtual disk instead of returning to the installer:
DETACH THE ISO AFTER INSTALL
VBoxManage storageattach ubuntu-srv --storagectl SATA --port 1 --device 0 --type dvddrive --medium noneConfirm the release so later commands match your Debian-family tooling.
cat /etc/os-release | head -2
Expected output:
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"What this teaches: /etc/os-release is the canonical distro identifier; confirming the family now prevents apt/dnf confusion in every later lab.
The NIC was attached to bridged mode in step 01. Here you confirm the guest picked up its own LAN address from DHCP, so you can SSH in from your host.
Expected output:
What this teaches: Bridged mode puts the VM on the physical LAN with its own DHCP address, so SSH from the host works exactly like a real server.
A snapshot lets you undo any future mistake instantly, which is what makes a VM a safe learning sandbox.
VBoxManage snapshot ubuntu-srv take clean-base --description "fresh install"
Expected output:
0%...10%...100%
Snapshot taken.What this teaches: A named snapshot of the fresh install is the undo button for the whole series; every later lab can break things safely.
VMware Workstation Equivalents
The steps above use VirtualBox CLI commands. The same lab on VMware Workstation uses the GUI; the concepts map one to one:
| VirtualBox step | VMware Workstation GUI equivalent |
|---|---|
| Step 01: createvm + modifyvm (2 vCPU, 4 GB RAM, bridged virtio NIC) | File > New Virtual Machine > Typical > Installer disc image file; then Customize Hardware: Memory 4096 MB, Processors 2, Network Adapter set to Bridged |
| Step 01: 20 GB dynamically allocated disk | In Customize Hardware: Hard Disk 20 GB, "Split virtual disk into multiple files" for the grow-as-needed equivalent |
| Step 02: attach ISO and boot | CD/DVD set to the Ubuntu Server ISO with "Connect at power on"; Power On This Virtual Machine |
| Step 04: bridged IP via DHCP | Same bridged adapter from the hardware step; the guest gets a LAN address automatically |
| Step 05: snapshot the clean base | VM > Snapshot > Take Snapshot, named clean-base |
VMware names its paravirtual network adapter VMXNET3; pick it in the adapter type dropdown for the same performance role virtio plays above. VMware Tools is the Guest Additions equivalent and is likewise optional for a headless server.
How It Works
A type-2 hypervisor like VirtualBox runs on your host OS and uses CPU virtualization extensions to execute guest instructions nearly natively. The guest's disk is a file on the host, its NIC is a virtual adapter bridged or NATed onto your network, and its console is a window. This faithful-enough emulation is why a VM is the standard lab substrate.
Bridged networking deserves attention because it changes the VM's identity: instead of hiding behind NAT, the VM gets its own LAN address from your DHCP server and is reachable by every host on the segment. That reachability is what makes SSH practice realistic, and it is also why bridged VMs inherit your LAN's security posture.
Snapshots implement copy-on-write checkpoints over the virtual disk. The base image freezes, new writes go to a differencing file, and restore simply discards the differences. Understanding this mechanism explains both the instant rollback and the disk growth you will see as labs accumulate changes.
Progress So Far
Testing & Validation
Run this final check from your host:
ssh [email protected] 'uname -a && uptime'You should see the VM's kernel string and uptime. If all checks pass, you have a working, reachable, restorable Linux server.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Installer reports no bootable medium | ISO not attached to the virtual optical drive | Reattach with storageattach and confirm the boot order puts optical first |
| Guest gets no IP in bridged mode | Wrong host adapter selected or DHCP blocked | Pick the active physical NIC in the bridge settings and check DHCP on the LAN |
| VM is sluggish | Under-provisioned RAM/vCPU | Raise the allocation; keep the virtio NIC from step 01. Guest Additions are optional on a headless server |
| Cannot SSH into the guest | OpenSSH not installed or host firewall blocks it | Install openssh-server in the guest and allow port 22 |
| Snapshot chain consumes host disk | Each snapshot's differencing file grows with writes | Delete stale snapshots to merge, keeping only the clean base |
| VT-x unavailable error | Hyper-V or another hypervisor holds the extensions | Disable competing hypervisors or enable nested support in firmware |
Troubleshooting
- No 64-bit OS option: enable VT-x/AMD-V in host BIOS, then restart VirtualBox.
- SSH connection refused: confirm OpenSSH was selected during install (
sudo systemctl status ssh). - No LAN IP: switch the adapter from NAT to Bridged and re-run the installer's network step.
Extension Ideas
- Try the Post-Installation Configuration lab to harden this base.
- Convert the VM to a KVM guest in Creating Nested VMs with KVM.
- Read the Ubuntu Server install docs for autoinstall (cloud-init) automation.
Key Results
- Stood up a reachable Linux server VM in under 1 hour.
- Confirmed SSH access over a bridged LAN IP.
- Captured a snapshot enabling sub-minute rollback.
- Created a disposable base reused across 11 server labs.
Key Takeaways
- Script VM creation with VBoxManage for repeatability.
- Bridged networking gives the VM a real LAN identity for SSH practice.
- /etc/os-release confirms the distro family before you run package commands.
- Snapshot the clean base before any experiment.
- Snapshots are copy-on-write; they grow with changes and merge on delete.
Practice Challenges
Challenge 1: Unattended install
Goal: perform the whole install with zero GUI interaction using an autoinstall seed, then snapshot.
Hint: VBoxManage unattended install consumes a user-data file.
Challenge 2: Two-VM network
Goal: boot two guests on bridged networking and get them pinging and SSHing to each other by hostname.
Hint: avahi or /etc/hosts entries solve name resolution.