What does "KVM support available: False" mean in the GNS3 VM?

The GNS3 VM runs the kvm-ok check when it shows its information screen. False means Linux inside the VM sees no hardware virtualization, so QEMU appliances like IOSv, CSR 1000v or ASAv cannot use KVM acceleration. Dynamips, IOU, VPCS and Docker nodes do not need KVM and keep working.

Can I ignore it and run QEMU appliances anyway?

You can turn off hardware acceleration in the GNS3 VM's server configuration, and QEMU will start in pure emulation. Expect boot times many times longer, and some appliances will time out or never finish booting. It is a stopgap, not a fix.

Why did KVM stop working after a Windows update?

Windows features such as Memory integrity (Core isolation), WSL 2 or Windows Sandbox start the Windows hypervisor. VMware and VirtualBox then run on top of it, and that mode does not pass VT-x or AMD-V through to a guest. Turning those features off and restarting usually brings KVM back.

Does KVM work in the GNS3 VM on an Apple Silicon Mac?

No. The x86 GNS3 VM cannot run on Apple Silicon at all, and the experimental ARM64 GNS3 VM has no KVM for x86 appliances. Use a remote x86 server for QEMU appliances, or stick to Dynamips, VPCS and arm64 Docker images on the Mac.

GNS3 "KVM support available: False": how to fix it

The GNS3 VM boots, its blue information screen shows KVM support available: False, and your QEMU appliances refuse to start or take forever to boot. It means Linux inside the GNS3 VM cannot see the CPU's hardware virtualization (Intel VT-x or AMD-V), so QEMU has no KVM acceleration.

Why it happens

The GNS3 VM is a virtual machine that runs other virtual machines. For QEMU appliances to run at full speed inside it, your hypervisor must pass the CPU's virtualization instructions through to the GNS3 VM. That is called nested virtualization, and every layer has to allow it.

The value on the information screen comes from kvm-ok, a small check the GNS3 VM runs (you can read it in welcome.py in the gns3-vm repository). The GNS3 troubleshooting page lists the usual reasons it fails:

The CPU has no VT-x or AMD-V, or it is turned off in the BIOS or UEFI.
The hypervisor doesn't expose virtualization to this VM.
On Windows, Hyper-V or virtualization-based security (VBS) holds the CPU, so VMware or VirtualBox runs on top of the Windows hypervisor and cannot pass VT-x through.
The GNS3 VM runs somewhere nested virtualization is off: an ESXi host, a cloud VM, or an Apple Silicon Mac.

Only QEMU nodes need KVM. Dynamips, IOU, VPCS and Docker nodes run fine without it.

How to fix it

Work through the steps in order. Power the GNS3 VM off (not suspended) before you change its settings, and close GNS3 so it doesn't restart the VM behind your back.

1. Check the CPU and the BIOS or UEFI

On Windows, open Task Manager, go to Performance, then CPU, and look for Virtualization: Enabled. On a Linux host, count the virtualization flags:

grep -E -c '(vmx|svm)' /proc/cpuinfo

A result of 0 means the feature is missing or disabled in firmware. Reboot into the BIOS or UEFI setup and enable the option, often called Intel Virtualization Technology, VT-x, SVM Mode or AMD-V. The name depends on the board vendor.

2. On Windows, free the CPU from Hyper-V

This is the most common cause on Windows 10 and 11. Broadcom's article Virtualized Intel VT-x/EPT is not supported on this platform gives the procedure for VMware Workstation:

Open Windows Security, then Device security, then Core isolation, and turn off Memory integrity.
In "Turn Windows features on or off", untick Hyper-V, Virtual Machine Platform, Windows Hypervisor Platform and Windows Sandbox.
In an administrator prompt, stop the hypervisor from loading at boot, then restart:

bcdedit /set hypervisorlaunchtype off

To confirm, start the GNS3 VM once and search its vmware.log for Monitor Mode. CPL0 means VMware has the CPU to itself. Any other value means it still runs on top of Hyper-V.

Note the trade-off: WSL 2 and Docker Desktop's WSL 2 backend need Virtual Machine Platform. If you need them, run the GNS3 VM in Hyper-V instead (step 5).

3. VMware Workstation or Fusion

In Workstation, open the GNS3 VM's settings, select Processors, and tick Virtualize Intel VT-x/EPT or AMD-V/RVI. On an Intel Mac with Fusion, the option is Enable hypervisor applications in this virtual machine, under Processors & Memory, Advanced options.

GNS3 also writes this setting itself: when it starts the GNS3 VM, it adds the following line to the .vmx file if it is missing.

vhv.enable = "TRUE"

If you see VMware ask "Virtualized Intel VT-x/EPT is not supported on this platform. Continue without virtualized Intel VT-x/EPT?", answering Yes starts the GNS3 VM without virtualization, which leads to KVM support available: False. Go back to step 2.

4. VirtualBox

VirtualBox supports nested virtualization since 6.0 on AMD and 6.1 on Intel, and GNS3 refuses to start the GNS3 VM with older versions. GNS3 turns the option on each time it starts the VM from power off. You can set it yourself too, as described in the VirtualBox nested virtualization docs:

VBoxManage modifyvm "GNS3 VM" --nested-hw-virt on

In the VirtualBox Manager, the same setting is the Enable Nested VT-x/AMD-V check box on the Processor tab of the VM's settings.

5. Hyper-V

GNS3 enables nested virtualization on the Hyper-V GNS3 VM only when Allocate vCPUs and RAM is ticked in its GNS3 VM preferences. Otherwise, with the VM off, run this on the host, as in Microsoft's nested virtualization guide:

Set-VMProcessor -VMName "GNS3 VM" -ExposeVirtualizationExtensions $true

Microsoft supports this on Intel CPUs with VT-x and EPT, and on AMD EPYC or Ryzen with Windows 11 or Windows Server 2022 and later.

6. A Linux host

If the GNS3 VM runs in KVM or VMware on Linux, check that the host's KVM module allows nesting (kernel docs). Use kvm_amd on AMD:

cat /sys/module/kvm_intel/parameters/nested

Y or 1 means it is on. On Linux you can also skip the GNS3 VM and run the GNS3 server on the host, where QEMU uses /dev/kvm directly.

How to check it worked

Start the GNS3 VM and read the information screen. It should now say KVM support available: True. For the details, choose Shell in the GNS3 VM menu and run:

kvm-ok

A working VM prints INFO: /dev/kvm exists and KVM acceleration can be used. If it says INFO: Your CPU does not support KVM extensions, the hypervisor still isn't passing virtualization through. Finally, start a QEMU appliance in GNS3: it should boot without the hardware acceleration errors listed below.

If it still fails

ESXi. Edit the GNS3 VM's CPU settings in the vSphere Client and tick Expose hardware assisted virtualization to the guest OS.
A cloud VM. Most cloud instances hide VT-x from guests. Use a bare-metal server, or an instance type your provider documents as supporting nested virtualization.
An Apple Silicon Mac. The GNS3 VM is an x86 machine and Apple Silicon cannot provide KVM for x86 guests. See GNS3 on Apple Silicon.
Wrong error, same cause. On a remote Linux server, a QEMU node may fail with KVM acceleration cannot be used (/dev/kvm doesn't exist). It is possible to turn off KVM support in the gns3_server.conf by adding enable_kvm = false to the [Qemu] section. The appliance wizard says The selected server does not support KVM. A Linux server or the GNS3 VM running in VMware is required. Both mean the server has no /dev/kvm.
Last resort: run without KVM. In the GNS3 VM, choose Configure in the menu and add these lines, then reboot the VM. QEMU will run in software emulation, which is very slow.

[Qemu]
enable_hardware_acceleration = False
require_hardware_acceleration = False

The same two settings in GNS3's Edit, Preferences, QEMU page only change the local server, not the GNS3 VM. If the GNS3 VM then fails to connect at all, see Cannot connect to compute 'GNS3 VM'. The GNS3 troubleshooting guide covers the other common errors.

Or skip the nested hypervisor

If your lab is mostly Linux hosts and services, you may not need a VM inside a VM at all. Isothrum's editor runs in your browser with no account and exports the lab you draw as a Docker Compose file. A lab of containers runs on Docker directly, with no GNS3 VM and no nested virtualization. It won't give the GNS3 VM its KVM back, and router images such as IOSv or CSR 1000v still need KVM wherever they run.