OcNOS in Containerlab – Part 2: Platform Analysis for Linux, Windows, and MacOS

If you’re building labs with Containerlab, you’ve probably run into the same platform challenges I have. My previous guide, Containerlab + OcNOS home lab, focused on a budget-friendly Linux mini-PC. Since publishing that, I’ve fielded questions from readers about Mac support, Windows workflows, and hybrid setups like WSL2 or Colima.

Over the July 4th weekend, I systematically tested every major platform combination available as of July 2025, documenting what works for OcNOS labs—and where you’ll hit a wall. Here’s a technical breakdown, grounded in hands-on results.

TL;DR:

• Native Linux (bare metal or VM with nested virtualization): Best option; all virtualization features work out of the box.
• Windows (Ubuntu VM in VMware/VirtualBox): Supported if nested virtualization is enabled.
• macOS (Colima/Docker Desktop): Works for basic containers, but has major limitations for vrnetlab-based network emulation.

(See details and error logs below.)

What I Tested

I tested three scenarios on each platform:

1. Running OcNOS as a VM
2. Running OcNOS as a vrnetlab container
3. Full orchestration with Containerlab

Here’s what I found.

1. Windows: VMs, WSL2, and Containerlab

Running OcNOS VM in VMware Workstation/VirtualBox

This is the most reliable option on Windows. To summarize the process:

Step 1: Convert Image (if needed)

qemu-img convert -O vmdk image.qcow2 image.vmdk

(Skip if you already have a .vmdk.) OcNOS .vmdk (VirtualBox/VMware) and .qcow2 (KVM) available for download here.

Step 2: Create a VM

• Launch VMware Workstation/Player.
• Create a new VM (Custom/Advanced).
• Choose Linux → Debian 10/11 (64-bit).
• Assign 4–8 CPU cores and 8–16 GB RAM.
• Attach your .vmdk as an existing disk.

Step 3: Tune Settings

• Enable CPU virtualization/IOMMU.
• Set networking to Bridged or Host-only.
• Optionally, connect the serial output to a console.

Step 4: Boot and Login

• Start VM; OcNOS should boot in 1–2 minutes.
• Login: ocnos/ocnos.

Containerlab + WSL2: A Cautionary Tale

Many asked if you can skip the VM and just run Containerlab in WSL2 on Windows. I tried everything. Here’s the sequence:

• Install WSL2 and Ubuntu:
  wsl –install -d Ubuntu
• Enable Docker Desktop with WSL2 integration.
• Install Containerlab via curl and bash (needed to install missing dependencies).
  • The VRNetLab distribution I use for all my experiments is available here.
• Prepare and copy your OcNOS image into the WSL2 home directory
  • If using /mnt/c/ as recommended for some WSL2 applications, it leads to file permission errors and slow I/O.
• Build vrnetlab image and create a simple yml topology. The following errors were faced:
  • Failed to Statfs “/proc/0/ns/net”: no such file or directory
  • Containers are stuck in the “restarting” state.
  • Warnings about missing iptables, bridge group, etc.
  • No ports exposed (docker ps shows empty PORTS).

The problem:
Containerlab deployments fail, containers are stuck restarting, and QEMU is failing.

Root cause:
WSL2 supports nested virtualization only on Windows 11 and above. Per May 2025 release of WSL-containerlab this should work:
https://github.com/srl-labs/wsl-containerlab/tree/0.68.0-1.0

Conclusion:
Containerlab + vrnetlab is not supported on WSL2 with Windows as of now. Use a full Linux VM with nested virtualization instead.

2. macOS: Colima, Docker Desktop, and Apple Silicon

I was eager to make this work, especially as a Mac fan. Unfortunately, reality didn’t cooperate.

Initial setup (Colima, Docker Desktop, QEMU):

• Colima can launch containers with QEMU emulation, but hardware acceleration (hvf) doesn’t work.
• tcg emulation results in 100% CPU usage, even with a single container.
• Privileged mode solves some permission issues, but not all.

Snapshot of Issues: