On Monday, you are told to set up a cloud lab for the team, even though the first public-cloud VM attempt failed months ago and nobody can explain why. As you reopen that failed design, treat a cloud network emulation platform as the same emulators, EVE-NG, GNS3, and Cisco Modeling Labs, running on cloud or hosted infrastructure that you manage yourself or ask a provider to manage. The emulator is familiar. The operational constraints around it are where enterprise deployments usually go wrong.
Your requirements need to survive image licensing, procurement, topology behavior, and the first week when several engineers log in at once. Start by documenting what failed in the earlier attempt, including the host type, emulator edition, images, concurrent users, and access path. That record turns a vague request for a better lab into an infrastructure problem you can diagnose.
If you are still deciding among EVE-NG, GNS3, and Cisco Modeling Labs, use the cloud network emulation platform guide for that decision. If the shortlist is already down to two, use the EVE-NG and GNS3 comparison to settle the head-to-head question.
If you are validating a vendor product or release, follow the telecom vendor-QA workflow. Send control-plane and interoperability work to emulation, then keep the physical tests on physical equipment.
Emulation is faithful to configuration and control-plane behavior. It does not reproduce ASIC forwarding, line-rate throughput, optics, or exact hardware timing, because the virtual image is running control-plane software on a hypervisor and a general-purpose CPU, and the forwarding path that silicon would own is being approximated in software. A topology that passes every route-policy and failover check has validated exactly that: routing, policy, protocol state, and interoperability. Throughput, buffer behavior, and convergence timing under load are still open questions until real equipment answers them, so route those claims to hardware before you sign the change.
Vendor images carry their own entitlements, and your team remains responsible for obtaining and maintaining them. A hosting provider may purchase licenses on your behalf, but that service does not transfer ownership of the legal obligation or create redistribution rights for the underlying images.
This becomes visible when a lab host is ready but the project cannot load the required software. Someone assumed that paying for infrastructure included a licensed image library. EVE-NG and GNS3 deployments generally follow a bring-your-own-image model, where licensing allows, and Cisco Modeling Labs licenses must be acquired from Cisco rather than from the host.
Put each required image, version, source, entitlement owner, and renewal owner into the requirements record before provisioning. Treat licensing assistance as an administrative service, not as permission to use software your organization is not entitled to run.
Reopen the failed first attempt and the mechanism is usually sitting in the guest's CPU flags. EVE-NG is a KVM host; the GNS3 VM runs QEMU with KVM inside whatever outer hypervisor you gave it (VMware, VirtualBox, Hyper-V, or KVM); Cisco Modeling Labs is KVM underneath. All three need the processor's virtualization extensions, Intel VT-x or AMD-V, visible inside the machine they run on. Put that stack inside a general-purpose cloud VM and the outer hypervisor may not pass those flags through at all, in which case QEMU can fall back to software emulation (TCG), or the emulator refuses to start nodes at all: the first two IOSv routers limp up, the fifth hangs at boot, and adding vCPUs changes little because the bottleneck is instruction translation, not core count. Where the flags are passed through, you still pay for nested page-table exits on every appliance. Not every image is a full virtual machine, and non-VM nodes such as IOL (a native Linux binary) or cEOS (a container) escape most of this, but the heavyweight vendor VMs that make an enterprise lab realistic (IOSv, ASAv, a firewall image) are exactly the ones that need real KVM. Before you buy compute anywhere, confirm the host exposes VT-x or AMD-V to your emulator, and prefer bare metal or a provider that states it does over any large cloud VM you have not tested.
Two different knobs get flattened into "set the bandwidth," and each bites separately. On Cisco IOS, OSPF cost is reference bandwidth divided by interface bandwidth and the default reference bandwidth is 100 Mbps, so every virtual link at or above 100 Mbps costs 1 and your lab's 1G, 10G, and 100G paths become indistinguishable. The fix is auto-cost reference-bandwidth, set process-wide to at least the fastest link in the design (100000 for 100G) and identically on every OSPF speaker, not per interface. EIGRP is worse: its default composite metric uses bandwidth and delay, and virtual Ethernet keeps a stock delay after you correct the bandwidth, so an EIGRP topology can still prefer the wrong path with bandwidth perfectly aligned. Set both, and keep both with the topology definition so every reset restores the same routing assumptions. None of this makes the interface forward at that rate; a bandwidth statement is control-plane metadata for the routing calculation and nothing more.
Multi-user capability is an edition and licensing property, not an automatic benefit of putting an emulator in the cloud. Hosting a single-user edition on a larger server does not create private workspaces, role controls, or separate lab instances.
The mistake surfaces during the first shared week. The administrator account becomes a team login, engineers overwrite one another's state, or nobody can give a second engineer a private copy. EVE-NG Freemium is limited to 7 nodes and admin-only access. Per-user lab instances and role-based access arrive with EVE-NG Professional, subject to its license. Cisco Modeling Labs supports multi-user operation in Enterprise and Education editions, while Personal is single-user.
Write the required user model before choosing the license: named users, concurrent users, private versus shared topologies, and administrative roles. Match that model to the emulator edition instead of asking the hosting layer to compensate for a licensing boundary.
One engineer restores a GNS3 project snapshot on Wednesday and expects every device disk to come back to Tuesday's state; it does, if the nodes were stopped when the snapshot was taken, and not reliably otherwise. Down the hall a colleague wipes a Cisco Modeling Labs node, and the next person to open that lab inherits day-zero plus whatever startup configuration was defined, not Tuesday's golden config, because wipe destroys the node disk and returns it to the image. Neither of them did anything wrong; they were using different primitives and calling both "reset." EVE-NG has its own: stop the node, delete its overlay, and boot the base image again, which exists on Freemium as well as Professional. What Professional adds is not a reset at all but isolation, per-user lab instances that keep one person's wipe from taking the shared lab with it. Decide, per platform, which primitive is your recovery path and what "clean" means (image, bootstrap, or a golden config you keep yourself), then rehearse the restore with the real images before the first cohort or change window.
Access mechanics vary by emulator, and secure entry is a separate layer from the emulator interface. EVE-NG topologies open in a browser, while GNS3 commonly pairs a desktop client with a remote server. Console sessions can tolerate modest connections, but the path to the platform still needs to be designed.
A deployment can look healthy from the administrator's network and fail for the people expected to use it. Desktop-client restrictions, blocked console traffic, identity controls, and remote access rules can each break a different part of the path. Adding a VPN with MFA protects entry, but it does not change whether an emulator needs a browser, a client, or console connectivity.
Test the full journey with a normal user account from the networks your engineers actually use. Record the client requirements, authentication path, console behavior, and support boundary before calling access complete.
Ask it before anyone plugs a topology into anything "for updates." The convenience bridge is the blast radius: EVE-NG's management cloud (pnet0) commonly sits on the host's management NIC, a GNS3 Cloud or NAT node lands on whichever adapter it was pointed at, and a CML External Connector rides a Linux bridge that may already carry a default route. Any of those, plus a duplicated subnet, a leaked BPDU, or a test route, is a path from the lab into a network the lab was supposed to be isolated from. A label such as "lab" enforces nothing; check those three objects, keep production networks out of topologies, and when a provider hosts the environment, ask how tenant separation and external connectivity are implemented and verify the delivered design against your isolation requirement.
Capacity has two independent limits: the number of people licensed to use the platform and the compute available to run their topologies. Heavyweight virtual appliances consume memory and CPU, and every infrastructure plan eventually reaches a resource ceiling.
The edition can look correct on paper while the shared experience still fails. A team has enough user access, but simultaneous boots exhaust memory, CPU contention slows nodes, or several private copies multiply the footprint beyond the host allocation. Conversely, spare compute does not grant additional licensed users.
Size the environment from the actual image mix, topology size, expected concurrency, and startup pattern. Validate the busiest realistic session before rollout, because an edition alone cannot produce a private, responsive topology for every user.
Managed hosting of a cloud network emulation platform changes who operates it, not what the emulator can reproduce. Patching, image hosting, capacity management, monitoring, and support hours may move to a provider, while your topology design, content, and image entitlements remain your responsibility.
Confusion starts when "managed" is read as "the provider owns every outcome." The provider can keep the host available and help operate the emulator, but cannot turn a virtual appliance into forwarding silicon, decide which configuration represents your production intent, or assume your software rights. You also give up some direct control in exchange for another team carrying the operational pager.
Name the tasks that move to the provider and the tasks that remain with your engineers. Self-hosting is a legitimate choice when you want maximum control and have the people to operate it; managed hosting fits when you want those people focused on network work.
| Operating fact | Self-hosted on your servers | DIY on public-cloud VMs | Managed hosting |
| Fidelity | Same emulator and image fidelity boundary | Same emulator and image fidelity boundary | Same emulator and image fidelity boundary |
| Nested-virtualization exposure | Avoidable with bare metal or a correctly configured host | Depends on whether the selected VM family exposes virtualization extensions | Depends on provider architecture; confirm bare metal or exposed extensions |
| Who patches | Your team patches the host and emulator | Your team patches the host and emulator; the cloud provider maintains underlying infrastructure | Provider responsibility to the scope stated in the service |
| Multi-user | Edition-dependent | Edition-dependent | Edition-dependent |
| Reachable without internet | Yes on your local network, though licensed EVE-NG Professional needs to reach its license server, and CML needs Smart Licensing reach unless you use a license reservation | No; access depends on internet or private wide-area connectivity | No; access depends on connectivity to the provider |
| Support | Your staff, plus platform vendor or community channels | Your staff for the emulator, plus cloud support for infrastructure | Provider support for the contracted service, with platform and licensing boundaries still applicable |
The meaningful difference is operational ownership. Assign each row to a named team before you buy the host, then confirm that the chosen infrastructure exposes the virtualization, access, and isolation controls the emulator needs.
CloudMyLab is one managed option alongside self-hosting and other providers. Its hosted emulator service covers EVE-NG, GNS3, and CML 2.0 environments managed by certified engineers on virtual machines or bare metal servers. Customers bring their own images where licensing allows, and the team can assist with license purchases, while CML licenses still come directly from Cisco.
CloudMyLab publishes 24/7/365 priority support, no long-term contract, and isolated, secure testing infrastructure on the hosted emulator service. The separate automation environment includes Ansible, GitLab Community Edition, and pre-built playbooks. Lab as a Service adds a dedicated account manager, Cisco AnyConnect with DUO MFA, and SIEM event-log analysis.
You still own topology intent, content, and entitlements, while CloudMyLab takes on the contracted operating work. If that division matches your requirements, use the free trial to test the actual images, access path, and concurrent workload you plan to run.
There are no published retention statistics to point to. A 2026 Frontiers in Education study of a university lab running GNS3 and EVE-NG on university-hosted infrastructure reported a 25-percentage-point mean gain in post-lab scores, and 92% of participants rated usability good or excellent. It measured learning outcomes and usability, not student retention. The study used a single-cohort pre/post design with no control group, and its authors describe an association rather than causation. Removing local setup and access barriers is a plausible way to help students keep participating, but that mechanism has not been proven to improve retention. Use the evidence to support an accessible lab design, not a retention forecast.
EVE-NG, GNS3, and Cisco Modeling Labs are the main emulators in this landscape. Each can be self-hosted, placed on cloud infrastructure, or operated through a managed provider, and several providers exist. Evaluate the deployment against fidelity limits, image rights, virtualization support, licensed user access, reset behavior, secure entry, isolation, compute capacity, and operational ownership rather than accepting a brand ranking. CloudMyLab hosts all three, but it is not the only hosting path.
Multi-vendor emulators such as EVE-NG and GNS3 suit the control-plane and interoperability part of vendor product testing. Line-rate performance, conformance, hardware timing, and physical-layer behavior still require physical test systems. Use the vendor product-testing workflow to decide where each test belongs instead of expecting one hosted platform to replace both environments.
No. Hosting can improve operational consistency, capacity planning, access, and support, but the emulator retains the same boundary around ASIC forwarding, line-rate throughput, optics, and hardware timing. Choose managed hosting when you want to transfer defined operating tasks, not when the requirement is to make virtual results behave like a physical performance benchmark.