Skip to content

GNS3 on Apple Silicon M1/M2/M3/M4 Macs: what works

The GNS3 app runs on M-series Macs, but the x86 GNS3 VM doesn't. What the ARM64 VM can run, its limits, and when to use a remote server.

Published on 6 min read

You installed GNS3 on an M1, M2, M3 or M4 Mac, imported the GNS3 VM into VMware Fusion, and Fusion says This virtual machine cannot be powered on because it requires the X86 machine architecture, which is incompatible with this Arm machine architecture host. The standard GNS3 VM is built for Intel and AMD processors. Apple Silicon is Arm, so it can't run that VM, and most network appliances inside it are x86 too.

Why it happens

GNS3 has two halves. The app on your Mac draws the topology. A GNS3 server runs the nodes: routers, switches, containers, VMs. On Windows and macOS, the heavy nodes normally run in the GNS3 VM, an Ubuntu VM that gives them Linux and KVM acceleration.

On Apple Silicon each layer has its own limit:

  • The app runs natively. We checked the GNS3 2.2.61 DMG: the GUI and the bundled gns3server are universal binaries (Arm and Intel). The bundled dynamips, vpcs, ubridge and QEMU are Intel-only, so macOS runs them through Rosetta 2.
  • The standard GNS3 VM doesn't run. It is an x86_64 machine, and VMware Fusion on Apple Silicon only runs Arm guests.
  • There is an ARM64 GNS3 VM, but it is experimental. GNS3's maintainer built it in 2021 and attached it to releases as GNS3.VM.ARM64.<version>.zip. The setup guide in discussion #3261 says plainly: "Please note this is EXPERIMENTAL".
  • There is no KVM inside it. The ARM64 VM can't use hardware acceleration for nested VMs. Even with it, KVM on Arm only accelerates Arm guests, and, as the maintainer notes in issue #3257, most vendor appliances are x86_64.

What runs where

This is the state as of October 2026, from the maintainer's notes in discussion #3261 and issue #3257:

Node typeIn the ARM64 GNS3 VMNotes
VPCSYesBuilt for Arm, no known issue
Dynamips (c3725, c7200...)YesBuilt without JIT, may be slower
Dockerarm64 images onlyamd64 images fail with exec format error
IOU / IOLOnly with emulationx86 binaries, need qemu-user set up by hand
QEMU x86 appliances (IOSv, CSR 1000v, ASAv, Windows)Emulation onlyNo KVM, very slow, some never finish booting

On the Mac's local server, the app runs Dynamips and VPCS itself. QEMU nodes there fail with HAXM acceleration support is not installed on this host (com.intel.kext.intelhaxm extension not loaded), because GNS3's macOS acceleration check looks for Intel HAXM.

The ARM64 VM was not built for every release. It is attached to GNS3 2.2.27 through 2.2.54 (April 2025) and to 3.0.3 and 3.0.4, but not to 2.2.55 or later, nor to 3.0.5 and later (as of 3.1.0 alpha 6, September 2026). The gns3-vm repository now has ARM64 build scripts for the 3.x line, but no newer image has been published yet.

How to set it up

1. Install GNS3 and Rosetta 2

Download the GNS3 DMG and drag GNS3 to Applications. If Rosetta 2 isn't installed yet, install it so the bundled Intel tools can run:

softwareupdate --install-rosetta --agree-to-license

If you only need Dynamips routers and VPCS, you can stop here and use the local server.

2. Set up the ARM64 GNS3 VM in VMware Fusion

Because the app and the VM must match exactly (see GNS3 version mismatch), use GNS3 2.2.54 on the Mac with GNS3.VM.ARM64.2.2.54.zip from the 2.2.54 release. The zip holds two disks, gns3vm-disk1.vmdk and gns3vm-disk2.vmdk. Fusion can't import it as an OVA, so the guide in discussion #3261 builds the VM by hand:

  1. In Fusion, create a custom virtual machine and pick Ubuntu for Arm as the guest system.
  2. Choose to use an existing virtual disk, and select gns3vm-disk1.vmdk.
  3. In the VM's settings, add a second hard disk using gns3vm-disk2.vmdk.
  4. Set the first network adapter to Private to my Mac, and add a second adapter on NAT.
  5. Start the VM and note the IP and port on its information screen.

Then connect GNS3 to it, either as a remote server at that IP and port (as the guide does), or in the GNS3 VM preferences with VMware as the engine. If GNS3 waits forever for the VM to start, the maintainer's fix in issue #3675 is to install open-vm-tools in the VM (the 2.2.54 image already includes the fix).

3. Let QEMU nodes start without KVM

QEMU templates require hardware acceleration by default, so they refuse to start in the ARM64 VM. If you accept emulation speed, choose Configure in the GNS3 VM menu and add:

[Qemu]
enable_hardware_acceleration = False
require_hardware_acceleration = False

Reboot the VM. The same check boxes in GNS3's own QEMU preferences only affect the local server on the Mac. For a single template, you can instead add -machine accel=tcg in its Advanced tab, under Additional settings, Options.

4. Run Docker and IOU in the VM

Pick Docker images that publish an arm64 variant, as Ubuntu and Alpine do. For IOU, the maintainer's instructions in discussion #3261 install qemu-user-binfmt and i386 libraries in the VM so the x86 binaries run under emulation. They date from 2021 and change the VM's APT sources, so snapshot the VM first.

5. Use a remote x86 server for heavy appliances

For IOSv, IOSvL2, CSR 1000v, ASAv, vendor firewalls or Windows nodes, the reliable answer is an x86_64 Linux machine with KVM: a spare PC, a home server, or a bare-metal host. Install the GNS3 server there with the remote server guide and connect the app to it. That guide warns that most cloud VMs hide the CPU's virtualization instructions, so QEMU may be slow there too.

How to check it worked

In GNS3, the Servers Summary panel should show the ARM64 VM or your remote server in green, with the same version as Help, About. Then start one node of each type you plan to use. A VPCS node should answer show ip at once. A Docker node's console should open a shell; if its log says exec format error, the image has no arm64 build.

If it still fails

  • The selected server does not support KVM. A Linux server or the GNS3 VM running in VMware is required. The appliance wizard checks for KVM before it installs a QEMU appliance on a server. The ARM64 VM has none. Install the appliance on a remote x86 server, or create the template by hand after step 3. More in KVM support available: False.
  • The VM never goes green. See Cannot connect to compute 'GNS3 VM'.
  • You want IOL without a VM. Marc Weisel describes on the GNS3 community forum how he runs the GNS3 server in an OrbStack Linux machine with Rosetta. By his account it runs IOL, Dynamips, VPCS and Docker, but not QEMU, Cloud or NAT nodes. It is a community setup, not supported by GNS3.

The GNS3 troubleshooting guide covers the other errors.

A lighter way to build the lab on a Mac

If your lab is Linux hosts, services and an open-source router, you may not need a GNS3 VM on the Mac at all. Isothrum's editor runs in the browser with no account and exports the lab as a Docker Compose file: containers from any Docker image, plus an automatic router or FRR. Choose images with arm64 builds and it runs on Docker on the Mac. It does not solve the x86 problem: IOSv, CSR 1000v and Catalyst 8000v need KVM wherever they run, so they still need an x86 Linux host.

Related articles

GNS3 alternatives compared as of October 2026: EVE-NG, Containerlab, Cisco CML, Kathará, netlab and Isothrum. Licensing, what they run, and who each fits.
GNS3 appliance stuck on Missing files or This is not the correct file? Match the MD5, put the image where the wizard looks, and finish the import.
GNS3 can't reach the server inside the GNS3 VM. Find the VM's IP, test port 3080, fix the host-only network, versions and firewall.