This is Part 1 of the "Building a Local Lab for OCI Development" series.
☁️ Pre-Flight Checklist
This is a connecting flight. Before we taxi down the runway, here’s your flight plan. Keep this handy to navigate your flight path. Welcome aboard the cloud! ☁️
🌥️ Takeoff
⛅️ Cruising Altitude
- 5 Reasons to Use a Local VM for OCI Development
- Practical Guide: Setting Up an Ubuntu VM on Your M1/M2 Mac
🌤️ Landing & Taxi
Enjoy your flight! ☁️
As a cloud professional, you've likely encountered the dreaded phrase, "But it works on my machine!" This classic developer excuse often signals a painful debugging session ahead, typically caused by subtle differences between a local setup and the production cloud environment. For those of us working with Oracle Cloud Infrastructure (OCI), achieving true environment parity is not just a luxury—it's a necessity for efficient, reliable development.
The solution? Bringing the cloud to your local machine with a Virtual Machine (VM).
This article will explore why running a local Linux VM is a game-changing practice for any serious OCI professional. We'll cover the core concepts and provide a step-by-step guide to setting up your own local cloud environment on an M1/M2 Mac using UTM.
What is a VM and Why Does It Matter for OCI?
In the simplest terms, a virtual machine is a digital replica of a physical computer. It runs as an application on your host machine (like your Mac) but operates as a completely separate, isolated system with its own operating system (OS), storage, and networking.
Cloud platforms like OCI are built on the foundation of virtualisation. When you provision a VM.Standard.E4.Flex Compute instance in OCI, you are essentially renting a VM that runs on Oracle's massive, globally distributed hardware. This VM runs a server-grade OS, most commonly a distribution of Linux like Oracle Linux or Ubuntu.
By recreating a similar VM on your local machine, you build a sandboxed, production-mirroring environment. This local "micro-cloud" becomes your personal lab for testing, learning, and building with confidence.
5 Reasons to Use a Local VM for OCI Development
Let's break down the key advantages of integrating a local VM into your workflow.
1. Achieve True Environment Parity
This is the most critical benefit. Your local machine, no matter how powerful, is not your production environment.
On Your Mac (macOS): Your Mac is a Unix-like OS, but it's not Linux. It uses a different kernel, a unique file system (APFS), and its own set of system libraries. These differences can lead to unexpected behaviour in scripts and applications.
In the Linux VM (Ubuntu): You are running a true Linux environment, nearly identical to what your code will encounter on an OCI Compute instance.
Why It Matters for OCI: This drastically reduces the "it works on my machine" problem. You can be confident that if your automation scripts, application code, and dependencies work correctly in your local VM, they will behave predictably in the cloud.
2. Master Native Cloud Tooling
The way you manage software on your Mac is fundamentally different from how it's done on a cloud server.
On Your Mac (macOS): You probably use Homebrew to install tools. While excellent, Homebrew installs packages in its own directory structure (e.g.,
/opt/homebrew), which doesn't reflect a standard Linux server layout.In the Linux VM (Ubuntu): You use the apt package manager, the same tool used on Ubuntu servers in OCI. You learn the commands and dependency management system that is native to your target environment.
Why It Matters for OCI: This ensures your dependencies are identical. When your application requires a specific system library (like libpq-dev for PostgreSQL), apt in the VM installs it just as it would be on a production server, preventing compilation or linking errors down the line.
3. Isolate Your Workspace for Safety
A local VM is a disposable sandbox, offering complete isolation from your host machine.
On Your Mac (macOS): Every tool, SDK, and dependency you install lives on your main OS. A misconfigured script could interfere with your personal files, and managing conflicting software versions can become a nightmare.
In the Linux VM (Ubuntu): The VM is completely isolated. You can test potentially destructive scripts (like a Terraform plan that destroys resources), experiment with new tools, or even crash the entire OS with zero risk to your Mac.
Why It Matters for OCI: It enables fearless experimentation. You can test a script that modifies cloud resources without the anxiety of a typo causing it to target the wrong compartment. If you break the VM, you can delete it or restore it from a snapshot in minutes.
4. Guarantee a Clean, Reproducible State
Your personal machine's configuration evolves over time, making it difficult to guarantee a "clean slate" for testing.
On Your Mac (macOS): It's hard to know if a setup script works because it's well-written or because of a tool you happened to install months ago.
In the Linux VM (Ubuntu): You can start with a pristine, fresh OS at any time. Using snapshots, you can revert your VM to a known-good state in seconds.
Why It Matters for OCI: This ensures your automation is robust. You can validate that your setup scripts will work on a brand-new OCI instance, not just on your customized machine.
5. Simulate Real-World Networking
Cloud networking is complex. A VM allows you to mimic it locally.
On Your Mac (macOS): It's difficult to simulate cloud-specific networking rules, like OCI Network Security Groups (NSGs) or firewall configurations.
In the Linux VM (Ubuntu): The VM has its own full-featured Linux networking stack. You can use tools like iptables to precisely replicate the firewall rules your application will face in the cloud.
Why It Matters for OCI: You can test your application's resilience under realistic network conditions. For example, you can block a port to verify that your app handles connection errors gracefully—something you can't easily test otherwise.
Practical Guide: Setting Up an Ubuntu VM on Your M1/M2 Mac
Ready to build your local lab? Here’s a step-by-step guide using UTM (UTM + Ubuntu 24.04 ARM Desktop), a fantastic, free virtualisation tool for Apple Silicon.
Prerequisites
UTM installed from https://mac.getutm.app/
Ubuntu ARM ISO (e.g., ubuntu-24.04-desktop-arm64.iso) from Ubuntu downloads
UTM VM Configuration
General Settings:
| Setting | Value |
|---|---|
| Architecture | ARM64 (aarch64) |
| System | QEMU (Virtualize) |
| Memory (RAM) | 3.5–4 GB (3584–4096 MB) |
| CPU Cores | 4 |
| Display | Virtio-GPU (recommended) |
Drive Settings
- Disk interface: VirtIO
- Recommended disk size: 32 GB
Ubuntu Installation Steps
- Start VM → Select “Install Ubuntu”
- Disable the following during setup:
- Third-party drivers
- Software updates during install
- Encryption (use “No encryption”)
- Choose: Erase disk and install Ubuntu (This erases the virtual drive only)
- File system: use default ext4
- Set up your user:
- Name: e.g., Smyekh
- Username: smyekh
- Password: simple, e.g., 12345678
- Wait while it installs — can take 15–25 min
Troubleshooting During Install
-
Stuck on “Setting up system” for >20 min?
- Reason: Running out of memory or stuck on Snap installs
- Fix: Reduce VM RAM to 3.5 GB (give macOS breathing room), restart install without updates
-
gnome-settings-daemon killed or crashed?
- Cause: Ubuntu GUI crashed due to low RAM
- Fix: Lower VM RAM and avoid background tasks like Snap or updates
-
UTM/QEMU using high CPU% (e.g., 300%+)
- Normal during install
- If freezing: reduce RAM and CPU usage by macOS
Remove Installation Medium After Install
If you see:
“Please remove the installation medium, then press Enter.”
“Failed unmounting cdrom.mount”
Do this:
- Power off the VM
- Go to Edit → Drives
- Remove the USB Drive that points to ubuntu-24.04...iso
- Keep the VirtIO Drive (this is your installed system)
- Start the VM again — you should boot into Ubuntu normally
Clean-Up Tip
Remove the ISO file from your Mac (e.g., Downloads folder) after install — it doesn’t affect your VM
Optional Tools to Install Post-Boot
Once logged in, open the terminal and run:
sudo apt update && sudo apt upgrade -y
sudo apt install tilix zsh htop neofetch git curl
Opening the Terminal in Ubuntu
Here are 3 easy ways to open the terminal in Ubuntu Desktop:
1. Right-click on the desktop
- Right-click anywhere on the desktop or inside any folder
- Click “Open Terminal”
2. Use the keyboard shortcut
- Press
Ctrl + Alt + T
(The classic way to open the terminal on all Ubuntu versions)
3. Search via Applications Menu
- Click the “Show Applications” icon (bottom-left or bottom-center dock)
- Type “terminal” in the search bar
- Click Terminal (or GNOME Terminal)
What is apt in Ubuntu?
apt stands for Advanced Package Tool. It’s the default package manager used in Ubuntu and Debian-based systems.
Think of it as:
A command-line app store that installs, updates, and removes software safely and efficiently.
What You Can Do with apt
| Task | Command Example |
|---|---|
| Install software | sudo apt install neofetch |
| Update package list | sudo apt update |
| Upgrade installed apps | sudo apt upgrade |
| Remove a package | sudo apt remove neofetch |
| Search for packages | apt search terminal |
-
sudo= “superuser do” → gives you admin privileges - All packages are pulled from Ubuntu’s official repositories (like app stores)
Real-World Analogy
Imagine your Ubuntu terminal is like a phone.
-
apt install= downloading an app -
apt update= refreshing the app store -
apt upgrade= updating all your apps -
apt remove= uninstalling an app
Best Practices
- Always run
sudo apt updatebefore installing anything new - Use
sudo apt upgraderegularly to keep your system secure - Use
apt searchto explore what’s available
Shared Directory (Optional)
UTM may prompt:
“Optionally select a shared directory…”
- You don’t have to select this
- Works only after installing guest tools (like spice-vdagent)
- Can be skipped unless you need file sharing between macOS and your VM
You now have a fully functional Ubuntu desktop running locally! Open the terminal with Ctrl + Alt + T and start building.
Conclusion
Adopting a local VM workflow is a mark of a mature cloud professional. It moves you beyond simply using cloud services to deeply understanding the environment where your code lives. By embracing local virtualisation, you create a faster, safer, and more reliable development cycle, ensuring that when you deploy to OCI, it just works every time.
But a VM is only useful if you can interact with it efficiently. In the next articles in this series, we'll turn this isolated VM into a powerful, integrated development environment by:
Setting up a shared folder to sync code directly from your Mac.
Configuring port forwarding to access services like web servers and APIs running in the VM.
Let's get started.
Next Up: Part 2: The OCI Developer's Workflow: Bridging Your Mac and Local VM with a Shared Folder
Cover Photo by BoliviaInteligente on Unsplash
Top comments (0)