VMware Workstation for Cisco Labs (Now Free for Personal Use)
For years the honest answer to 'what should I run my Cisco lab on' was 'VMware, but it costs money.' That changed — VMware's desktop hypervisors are now free for personal use, which makes the platform most emulators are tuned for the easy default. If you're choosing where to host CML, EVE-NG, or GNS3, this is usually where to start.
Workstation is now free for personal use
VMware Workstation (Windows and Linux) and VMware Fusion (macOS) are now offered free for personal, non-commercial use, and the old 'Player' vs 'Pro' split has collapsed into one product. That removes the historical reason people reached for VirtualBox instead. Licensing terms do shift, so confirm the current 'personal use' conditions on VMware's site before relying on it for anything beyond home study.
Like VirtualBox, Workstation is a type-2 hypervisor you install on top of your existing OS — the difference is in how well it runs the demanding, nested workloads a network emulator throws at it.
Why emulators prefer it
Cisco Modeling Labs is validated to run on VMware (ESXi, Workstation, and Fusion), so if CML is your goal, Workstation is the supported desktop path, not VirtualBox. EVE-NG and GNS3 also publish VMware appliances and generally run their nested device images more smoothly on VMware than on VirtualBox.
The reason is nested virtualization: VMware's implementation is more mature and faster, so the virtual routers and switches running inside your emulator VM boot more reliably and feel snappier. On a big topology that difference is the gap between 'usable' and 'painful'. Turn on 'Virtualize Intel VT-x/EPT or AMD-V/RVI' in the VM's Processor settings so the guest can nest.
VMware vs VirtualBox, in one line each
VMware Workstation/Fusion: free for personal use now, best nested-virtualization performance, and the officially supported host for CML — the safe default for serious study.
VirtualBox: also free and truly cross-platform, perfectly fine for EVE-NG and GNS3, and a fine first hypervisor — just not a CML host.
The Apple Silicon caveat applies to both: the classic Cisco images are x86, and ARM Macs can't run them at native speed. Fusion runs on Apple Silicon but its x86 nested support is limited, so on an M-series Mac a cloud lab or a separate x86 machine is usually more practical than local virtualization.
The bottom line
If you can run VMware Workstation or Fusion, do — it's free for home use, it's what CML expects, and it handles nested labs best. Keep VirtualBox in your back pocket for EVE-NG/GNS3 or non-Cisco work. Once your hypervisor is up and an emulator is running, every Goldfish Networks lab imports the same way: build the topology on real Cisco IOS, then grade your configuration against the answer key.
Sizing the host: RAM, CPU, and nested settings that actually matter
The single biggest reason a local CML or EVE-NG lab feels 'painful' isn't the hypervisor brand — it's under-provisioning the outer VM. Every emulated router and switch is a full VM running inside your CML VM, and each one reserves real host memory whether or not it's busy. A comfortable starting point is a host with at least 16 GB of RAM, giving the CML appliance 8 GB, and stepping up to 32 GB before you attempt large multi-node topologies. IOSv nodes are light (roughly 512 MB each); IOSvL2 switches and especially IOS-XE (CSR/Cat8000v) nodes are far heavier, so a 'small' six-node lab can quietly demand more memory than a 'big' lab built from lightweight images.
CPU allocation and nested acceleration are the other half. Give the CML VM multiple vCPUs and, critically, tick 'Virtualize Intel VT-x/EPT or AMD-V/RVI' in the VM's Processor settings so the guest can hardware-accelerate the devices running inside it. Without that box, nested nodes either refuse to boot or fall back to painfully slow software emulation. On Windows, be aware that enabling Hyper-V, Windows Sandbox, WSL2, or Core Isolation / Memory Integrity claims the VT-x extensions for the Windows hypervisor and can block VMware from passing them through — you may need to disable those features (or use the newer VMware/Windows-hypervisor coexistence mode) to get nesting back.
One practical habit saves a lot of grief: don't power on every node at once. Start the core of your topology, let it stabilize, then bring up edge and host nodes. This keeps peak memory and boot-storm CPU in check on a modest laptop and makes the difference between a lab that boots in a minute and one that thrashes swap for five.
A worked example: verifying a lab is really running before you configure
Once the hypervisor is up and your CML/EVE-NG VM is booted, resist the urge to start configuring immediately. A two-minute sanity check on the underlying network saves you from chasing 'bugs' that are really just an appliance still coming online. The pattern below assumes a simple two-router lab where R1 (Gi0/0 = 10.0.12.1/30) connects to R2 (Gi0/0 = 10.0.12.2/30), a layout you'll rebuild constantly for OSPF, EIGRP, and static-routing practice.
First confirm the interface actually came up and negotiated an address and line protocol, then prove reachability across the link. If the interface is administratively down you'll see it here long before a routing protocol 'mysteriously' fails to form an adjacency. Checking the data plane (ping) before the control plane (routing) is the habit that separates fast troubleshooters from slow ones.
The verification below is deliberately ordered: link state, then IP, then reachability. If any step fails you stop and fix that layer rather than piling routing config on top of a broken L1/L2 path — the same discipline the Goldfish grader rewards when it checks your running configuration against the answer key.
R1# show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 10.0.12.1 YES manual up up
R1# show interfaces gig0/0 | include line protocol
GigabitEthernet0/0 is up, line protocol is up
R1# ping 10.0.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
! Link and L3 reachability confirmed — now it is safe to add routing.
R1(config)# router ospf 1
R1(config-router)# network 10.0.12.0 0.0.0.3 area 0Frequently asked questions
Can I install Cisco Modeling Labs directly on Windows or macOS like a normal app?
No. CML ships as a virtual appliance (an OVA or ISO), so you run it inside a hypervisor rather than installing it natively on your desktop OS. On a personal machine that hypervisor is VMware Workstation on Windows/Linux or VMware Fusion on macOS, and CML boots as a guest VM that then hosts your nested routers and switches.
Why can't I just use VirtualBox to host CML instead of paying attention to VMware?
VirtualBox is a fine free hypervisor for EVE-NG and GNS3, but Cisco does not validate or support it as a CML host. CML is only supported on VMware (ESXi, Workstation, and Fusion), and VirtualBox's weaker nested-virtualization support tends to make the emulated IOS devices boot unreliably or run slowly. Use VMware for CML and keep VirtualBox for non-CML emulators.
My nested routers won't boot or the emulator says VT-x is unavailable — how do I fix it?
This almost always means nested virtualization isn't exposed to the guest. In the VM's Processor settings enable 'Virtualize Intel VT-x/EPT or AMD-V/RVI' so the CML/EVE-NG/GNS3 VM can run hardware-accelerated guests inside it. Also confirm virtualization (VT-x/AMD-V) is enabled in your host's BIOS/UEFI, and on Windows that conflicting features like Hyper-V or memory integrity aren't holding the VT-x extensions.
Is Packet Tracer graded the same way as Goldfish or CML labs?
Not the same way. Packet Tracer is a lightweight simulator, not real IOS, but it can grade inside pre-authored .pka activity files that ship with an answer/activity key. CML and Goldfish labs instead run genuine Cisco IOS/IOS-XE images and grade your actual running configuration against a rubric, so the CLI behavior and edge cases match production more closely.
I have an Apple Silicon (M-series) Mac — can I run CML and the classic Cisco images locally?
Practically, no. The classic CML device images are x86, and Apple Silicon is ARM, so Fusion's limited x86 nested support can't run them at usable speed. On an M-series Mac a cloud-hosted lab or a separate x86 machine is usually more practical than local virtualization for Cisco study.
Practice on real Cisco IOS
A fresh, graded Cisco Modeling Labs scenario every day — start with the free sample.