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.
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
gns3serverare universal binaries (Arm and Intel). The bundleddynamips,vpcs,ubridgeand 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 type | In the ARM64 GNS3 VM | Notes |
|---|---|---|
| VPCS | Yes | Built for Arm, no known issue |
| Dynamips (c3725, c7200...) | Yes | Built without JIT, may be slower |
| Docker | arm64 images only | amd64 images fail with exec format error |
| IOU / IOL | Only with emulation | x86 binaries, need qemu-user set up by hand |
| QEMU x86 appliances (IOSv, CSR 1000v, ASAv, Windows) | Emulation only | No 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:
- In Fusion, create a custom virtual machine and pick Ubuntu for Arm as the guest system.
- Choose to use an existing virtual disk, and select
gns3vm-disk1.vmdk. - In the VM's settings, add a second hard disk using
gns3vm-disk2.vmdk. - Set the first network adapter to Private to my Mac, and add a second adapter on NAT.
- 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.