If your laptop runs out of memory halfway through a CCNP topology, or you moved to an Apple Silicon Mac that cannot run x86 images at usable speed, you can move GNS3 onto a server in the cloud and keep using it from your own machine. There are three ways to run GNS3 in the cloud: build a cloud VM, rent a bare-metal server, or use hosted GNS3. The right choice depends on whether your images need KVM and how much of the server you want to look after. If you were looking for the GNS3 Cloud node, the one that connects a topology to a real network or the internet, that is a different feature; this guide covers running GNS3 itself on cloud infrastructure.
Table of contents
They differ on who provides KVM, who secures the server, and who fixes it when it breaks.
|
|
Cloud VM you build |
Bare-metal server you rent |
Hosted GNS3 |
|---|---|---|---|
|
Runs QEMU images with KVM |
Only on instance types with nested virtualization |
Yes, the server exposes the hardware directly |
Yes: Cisco UCS servers, as VMs or bare metal |
|
Who installs and upgrades GNS3 |
You |
You |
The provider sets it up |
|
Who secures access |
You: VPN, firewall rules |
You: VPN, firewall rules |
The provider sets up browser, VPN or jump-host access |
|
Where images come from |
You upload the images you are licensed to use |
You upload the images you are licensed to use |
You upload the images you are licensed to use |
|
Billing to watch |
Hourly, so stop it when you finish |
Usually a fixed term |
Monthly subscription, whether or not you lab that week |
|
Best fit |
Short labs, and engineers comfortable with cloud consoles |
Heavy labs you run for months |
Candidates and teams who would rather not run the server |
CloudMyLab sells the third option, so keep that in mind as you compare. Hosted GNS3 from CloudMyLab is a month-to-month subscription on Cisco UCS servers, set up for you, and you bring the images you are licensed to use. If you would rather own the server, the first two routes below are complete enough to follow.
Answer this before you pick a provider, because it decides which servers can run your lab at all.
GNS3 runs different node types in different ways. QEMU appliances, which include most modern images such as IOSv, Catalyst 8000V, Nexus 9000v and most non-Cisco virtual appliances, need KVM for practical speed; without it they run slowly or fail to boot. Dynamips (older IOS router images), IOU/IOL, VPCS and Docker containers do not use KVM, so they can run on a plain cloud VM. A lab built only from IOL and VPCS can run on a server that would fail with a Nexus 9000v.
GNS3's remote server guide warns that "most cloud providers (AWS, Azure...) block access to the CPU virtualization instructions and your VM will be slow and may not work when using Qemu". AWS, Azure and Google Cloud offer nested virtualization on some instance types, as the next section shows, but the warning still applies to some low-cost VPS plans. Check any server before you install anything:
grep -Ec '(vmx|svm)' /proc/cpuinfo # 0 means no virtualization extensions
ls -l /dev/kvm # must exist for KVMIf the first command prints 0 or /dev/kvm is missing, QEMU nodes will either fail or crawl. Once GNS3 is installed, start one QEMU node and confirm it boots at normal speed, because the flags alone do not prove the service can use KVM. The GNS3 installer has a --without-kvm option for servers without it, and its own help warns that this degrades performance.
For background on how the server side fits together, see our guide to what the GNS3 VM does. The GNS3 VM is the packaged appliance for desktop hypervisors; on a cloud server you normally install the GNS3 server software directly on Ubuntu.
AWS, Azure and Google Cloud offer nested virtualization on virtual instances, but only on specific types, and you often have to turn it on.
|
Provider |
What the vendor documents |
How to enable or check |
|---|---|---|
|
AWS |
Nested virtualization on virtual instances, with KVM as a supported hypervisor, on Intel families including M7i, M8i, C7i, C8i, R7i and R8i |
Launch with |
|
Azure |
"Nested Virtualization: Supported" on the feature table of size pages such as Ddsv7 |
Check the size page, then confirm |
|
Google Cloud |
Linux KVM as the hypervisor, excluding E2, memory-optimized, Arm and most AMD machine types |
Create the VM with |
Older tutorials that say AWS requires a bare-metal instance for KVM are out of date. AWS recommends evaluating bare metal for workloads that are performance sensitive, and Google warns that nested VMs "might experience a 10% or greater decrease in performance" on CPU-bound work, so expect a heavy topology to feel slower here than on bare metal.
Size the instance for the appliances, not the family. The smallest sizes in a supported family pass the KVM check but will not hold a QEMU-based CCNP lab, so add up the RAM each appliance's GNS3 template asks for and pick a size above that total.
Once you have an x86 instance with KVM confirmed, open only SSH and UDP port 1194 in the cloud firewall, then install GNS3 with the project's own script on a fresh Ubuntu LTS server, as root:
cd /tmp
curl https://raw.githubusercontent.com/GNS3/gns3-server/master/scripts/remote-install.sh > gns3-remote-install.sh
bash gns3-remote-install.sh --with-openvpn --with-iouThe script creates a gns3 user, sets the server to port 3080, and stores images under /opt/gns3/images. By default it installs from the GNS3 2.2 repository; add --custom-repository ppa-v3 if you want the 3.x line. Its Ubuntu LTS check does not run as written, so confirm you are on an LTS release yourself, and if apt install gns3-server fails during the script, the GNS3 repository has no build for that release. The --with-iou option also renames the host to gns3vm. Reboot when it finishes.
The catch with this route is billing. A cloud VM large enough for a real topology charges for every hour it runs, so stop the instance when you finish and check what you still pay for storage while it is stopped.
A dedicated server gives GNS3 the hardware directly, so KVM works without any nesting and heavy images run as well as the hardware allows. AWS bare-metal instances work this way, as do dedicated servers from hosting providers. The install is the same script as above.
Dedicated servers are usually rented for a fixed term, and you maintain the operating system and GNS3 yourself, so this route suits a lab you will use for months. Be careful with VPS plans sold at a similar level: some do not expose virtualization extensions at all, which is why the check above comes first.
If you already own a spare server, the same install and the same VPN approach work at home too.
A cloud server usually has a public address from its first minute, so lock it down before anything else.
GNS3's guide says: "If the server is exposed on the internet, you need to setup a VPN to avoid anybody taking control of your GNS3 and the emulators." It also explains that device consoles use telnet, which is why it says "we highly recommend to use a VPN to protect the access to the telnet console." Do not solve this by opening port 3080 and a range of console ports to the internet.
The --with-openvpn option sets up OpenVPN and moves GNS3 onto the VPN address, 172.16.253.1. It also publishes the client profile, which contains the VPN keys, on an HTTP server at port 8003. Leave port 8003 closed and copy the profile over SSH instead:
scp root@<server-ip>:/root/client.ovpn .Then remove the HTTP server with apt remove nginx-light, as the script's own output suggests. Import the profile into your OpenVPN client, connect, and point GNS3 at 172.16.253.1 on port 3080. If you already run another VPN, use that, and keep the cloud firewall closed to everything except the VPN port and your SSH access.
In the GNS3 GUI, set the cloud host as your main server, or add it as an extra compute resource, from the server preferences. GNS3 also serves a web UI on port 3080, which you reach over the same VPN. With the cloud host as the main server, your projects, templates and images live on it, so a lightweight laptop with a matching GUI can open the same work.
Keep the client and the server on the same release. GNS3's upgrade guide says the VM version "need to be the same version as the GNS3 client", and its troubleshooting guide lists a 3.x GUI against a 2.2 server as a known failure. An automatic update on one side can break this, so upgrade both together. Before you choose between 2.2 and 3.x, check which release GNS3 labels Latest on GitHub; GNS3 3.x pre-release builds are for testing, not for a lab you depend on. If several people will share the server, 2.2 has no user isolation, while 3.x adds users and roles, so check how the release you install isolates projects. Our EVE-NG vs GNS3 comparison covers what that means for teams.
GNS3 does not include Cisco images. Its documentation says you provide your own images and license file, and that is the same on a remote server. Some device images may require a valid license or subscription from the respective vendor, so check your own license terms before you upload them to a cloud provider. For what each Cisco option gives you, see GNS3 vs CML.
Add images through the GUI's new-template wizard and it uploads them to the server for you. For large images on a slow uplink, copy them to your home directory on the server first, then move them into place so the gns3 service can read them:
scp image.qcow2 <user>@<server-ip>:~/
sudo mkdir -p /opt/gns3/images/QEMU
sudo mv ~/image.qcow2 /opt/gns3/images/QEMU/
sudo chown gns3:gns3 /opt/gns3/images/QEMU/image.qcow2Then point the template at the file on the server. Consoles and the canvas run over your VPN, so expect some delay when you type.
Hosted GNS3 removes everything above except the images. With CloudMyLab's hosted GNS3, the server runs on Cisco UCS infrastructure as shared or dedicated virtual machines or dedicated bare metal, set up and managed by our team. You log in through a browser, VPN or jump host and work from a customized desktop with GNS3 ready to use, with 24/7 infrastructure support.
You still bring the images you are licensed to use, with onboarding and image-upload help included. The trade is control: you work in an environment the provider built rather than a server you administer. The subscription is month-to-month, so you can match it to a study plan or a project. Our free 24-hour trial covers hosted EVE-NG Pro and hosted CML, not GNS3, and it shows you how access to a hosted lab works before you commit.
Yes. Most network images are built for x86, so an Apple Silicon Mac cannot run them at usable speed locally. Put the server on an x86 cloud VM, a dedicated server or a hosted lab, and use the Mac only as the client. GNS3's 3.x pre-release builds add UTM for ARM64 on Apple Silicon, which does not make x86 appliances run at usable speed on a Mac, so a remote server is the practical answer.
If your lab fits in IOL, Dynamips and VPCS nodes, a small cloud VM is enough, and KVM does not matter. If you run QEMU images for a few sessions and you are comfortable with cloud consoles, build a cloud VM on a supported instance type and stop it when you finish. If you run a heavy topology for months and you are happy to maintain Linux and a VPN, rent a bare-metal server. If your study hours or your team's time are the scarce resource, use a hosted lab and leave the server to someone else.
If you are still deciding on the emulator as well, cloud network emulation platforms compares the wider options, and our guide to home and cloud labs covers when a lab at home is still the better answer. To go straight to a managed server, see hosted GNS3 from CloudMyLab.
Yes. You can install the GNS3 server on a cloud VM that supports nested virtualization, on a rented bare-metal server, or use a hosted GNS3 service. You then connect from the GNS3 GUI or web UI, ideally over a VPN.
Yes. AWS documents nested virtualization with KVM on virtual Intel instance families such as M8i, C8i and R8i, and you enable it when you launch the instance. Bare-metal instances also work. On x86 instance types without it, Dynamips, IOU and VPCS still run, but QEMU appliances will be slow or fail.
Only for QEMU appliances such as IOSv, Catalyst 8000V or Nexus 9000v on a cloud VM. Dynamips, IOU/IOL, VPCS and Docker nodes do not use KVM. A bare-metal server does not need nesting because it exposes virtualization directly.
GNS3 includes a web UI served by the GNS3 server on port 3080, so you can work in a browser once you have a server to connect to. GNS3 itself is software you host, not an online service. Hosted services such as CloudMyLab run the server for you and give you browser access to the lab.
No. GNS3 says that a server exposed on the internet needs a VPN to stop anybody taking control of it, and device consoles use telnet. Install with the OpenVPN option or use your own VPN, and keep the cloud firewall closed to everything else.