To run virtual nodes in a simulated network, the GNS3 open-source network simulator supports two virtualization technologies: Qemu and VirtualBox. The open-source routers we will use in a GNS3 simulated network must run on either a Qemu or a VirtualBox hypervisor. Depending on one’s requirements, one might choose either VirtualBox or Qemu.
Let me tell you why I prefer VirtualBox over Qemu when using GNS3 to simulate a network of Linux computers running open-source routing and switching software.
Qemu is an open-source hardware-emulation and virtualization platform. The GNS3 project provides filesystem images of Qemu-compatible Linux systems that have open-source routing software installed.
Qemu is available for the most common operating systems, Linux, Windows, and Mac OS. It supports virtualization of x86-compatible systems on hosts with x86-based CPUs and can emulate other types of microprocessors on an x86-based host computer (which is not relevant in my specific case).
Qemu cannot access hardware virtualization support — Intel’s VT-x or AMD’s AMD-V hardware-virtualization features — in most operating systems, except Linux, which results in slower performance. Qemu can access hardware virtualization support by using KVM in the Linux operating system but this only works if the guest filesystem image is the same architecture as the host operating system (for example: both the host and guest systems must be 64-bit operating systems). The Qemu appliances provided by the GNS3 project are all 32-bit systems (i686 architecture) but, in my case, I am running a 64-bit operating system (x86_64 architecture). So, when I use the Qemu appliances provided by the GNS3 project, I do not benefit from access to hardware virtualization support and I experience slow start times and high CPU utilization.
In GNS3, It is simple to set up Qemu and use the provided Qemu appliances. The user does not need to prepare all virtual nodes in advance. GNS3 Qemu virtual nodes can be created when they are needed – each will be based on a base filesystem image and Qemu sets up a separate copy-on-write filesystems for each virtual Qemu node that the user creates in a GNS3 project. One can use the same base Qemu appliance image in different projects and make changes to the virtual nodes in one project without impacting virtual nodes in another project.
When running GNS3 on a Linux host, I saw that Wireshark could not capture data passing between Qemu quest systems. But, capturing data with Wireshark and Qemu worked when I ran GNS3 in a the Microsoft Windows operating system. This appears to be a defect that affects the Linux version of GNS3. Since I am using Linux, this is a problem for me.
VirtualBox is another open-source virtualization technology available in the Linux, Windows, and Mac OS operating systems. VirtualBox is an open-source project but some extensions, while free of charge, are not open-source. The GNS3 project provides VirtualBox-compatible Linux filesystem images that have open-source routing software installed.
VirtualBox can access the hardware virtualization features — Intel’s VT-x or AMD’s AMD-V hardware-virtualization — in most modern PC microprocessors and this works consistently well in all operating systems that can run VirtualBox (Linux, Windows, and MacOS). VirtualBox only works on computers that run x86-compatible CPUs such as Intel and AMD but that limitation is not an issue in most use-cases where we also need to use GNS3 on a laptop or PC because most computers that will run either Linux, Windows, or Mac OS will use a CPU that is also compatible with VirtualBox.
Also, when using Wireshark to capture data running between nodes in the GNS3 simulation running in Linux, I encountered no issues. Data capture also works well when using GNS3 with VirtualBox in Windows.
One minor issue is that we must create a unique virtual machine disk image for every node that will be used in a simulation and, if we wish to save changes made to the nodes, we would not want to re-use these virtual machine disk images in other GNS3 projects because changes made in one project might change the behavior of the simulated network in another GNS3 project. For larger simulated networks, we may need to create many virtual machines in VirtualBox. Then, each of these needs to be set up separately in GNS3 before they can be used. These extra steps are not complicated but they do make it a bit less convenient to use VirtualBox, compared to using Qemu.
VirtualBox works consistently well and has better performance in my specific case. Qemu performs slower and has some issues in Linus when working with GNS3. The requirement to set up many virtual machines, each with its own disk image (or a clone of a master disk image) in VirtualBox is only a minor problem and does not outweigh the other benefits of using VirtualBox in my situation.
If I missed anything, I welcome your comments.