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.
Practice on hands-on CCNA & CCNP labs.
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.
Deploying the CML appliance in Workstation: OVA import and networking
Importing is File → Open pointed at the .ova. Workstation validates the OVF descriptor first, and a compliance complaint on a vendor appliance is common enough that the dialog offers its own answer — a Retry that relaxes the OVF and virtual-hardware checks, which is the normal way this import finishes. Set memory and vCPU count before the first power-on rather than after: the OVA's defaults are sized for the smallest useful lab, and changing memory later means a full shutdown of the controller and everything running on it.
First boot lands in the appliance's own setup wizard, where the hostname, the sysadmin account and the network configuration are decided. Write down the address it prints, because that one address is the web UI, the SSH target and the host part of every API call you will ever make against this controller. Pin it — statically in the wizard, or as a DHCP reservation on your router — since bookmarks, SSH config entries and scripts all key off it.
The setting worth thinking about hardest is the appliance's network adapter, because it decides who can reach the lab, and the table below is the whole decision. If you choose Bridged on Windows, open Virtual Network Editor, click Change Settings to get administrator rights, and bind the bridge to the physical adapter you actually use instead of leaving it on Automatic. Automatic will cheerfully select a virtual adapter belonging to some other tool, and the appliance comes up with no usable address at all.
Bridging matters a second time one level further down, inside CML. A lab's External Connector in NAT mode rides the appliance's own NAT and needs nothing from VMware. In bridged mode, frames leave the appliance carrying the lab nodes' own MAC addresses, which means the virtual switch underneath has to forward traffic for addresses it never handed out. Over a wired bridged adapter that works. Over Wi-Fi it does not, because an access point will not relay frames for a MAC that never associated with it — so a lab you need externally reachable wants the host on Ethernet. If you later move the same appliance to ESXi, the identical requirement reappears as a port group that must permit Promiscuous Mode and Forged Transmits.
One habit is specific to running a lab on a desktop hypervisor: stop the labs before you suspend the VM or reboot the host. Suspending freezes the nested nodes mid-flight, and their clocks jump forward on resume — enough to flap routing adjacencies and hand you an hour of troubleshooting a problem you created by closing the lid.
# vmrun ships with Workstation and Fusion. Running the appliance headless
# keeps the lab up with no VMware window on screen.
$ vmrun -T ws start ~/vmware/cml-controller/cml-controller.vmx nogui
# What is powered on right now
$ vmrun -T ws list
Total running VMs: 1
/home/you/vmware/cml-controller/cml-controller.vmx
# The address the appliance actually got. Needs the guest tools; if it errors,
# read the address off the appliance console instead.
$ vmrun -T ws getGuestIPAddress ~/vmware/cml-controller/cml-controller.vmx
192.168.1.50
# Stop it cleanly. 'hard' is the equivalent of pulling the power on a
# controller with labs running, so always try 'soft' first.
$ vmrun -T ws stop ~/vmware/cml-controller/cml-controller.vmx soft
# On macOS the type changes, not the commands: vmrun -T fusion ...| Appliance network adapter | Bridged | NAT |
|---|---|---|
| Who can reach the CML UI | Anything on your LAN — drive the lab from a second laptop, a phone, or a terminal on another desk | Only the machine running Workstation, unless you add port forwarding in Virtual Network Editor |
| Where its address comes from | Your LAN's DHCP server, so the controller looks like any other device; reserve it by MAC so it stops moving | VMware's private vmnet8 DHCP, on a subnet only the host knows about |
| Reaching lab nodes from outside CML | An External Connector in bridged mode puts node traffic straight onto the LAN, so a PC on your desk can ping a lab router | Outbound works through two layers of NAT. Inbound needs a forward at both layers, and the port forwarding above only gets you as far as the appliance, so treat lab nodes as unreachable from outside |
| Host on Wi-Fi | The appliance itself is fine: Workstation translates the guest's MAC when it bridges over a wireless adapter. Lab traffic is what breaks — an External Connector in bridged mode sends the nodes' own MACs, and an access point will not relay frames for a MAC that never associated, so put the host on Ethernet if lab nodes must be reachable | Fine, because every packet leaves the host as the host |
| Office, campus or hotel networks | Can trip port security, NAC or DHCP snooping, and may get no address at all | Unaffected — it borrows the connection the host already has |
| Setup effort | Choose the right physical adapter in Virtual Network Editor (needs admin), then reserve the address | The default; nothing to configure |
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.
Now put it to work
You've got the tooling sorted. The part most study setups never cover is whether the config you wrote is actually right — so start with something that checks it.
Practice on real Cisco IOS
Edit a real Cisco config and get instant pass/fail grading — free in your browser, no account needed.