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
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
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.
Conclusion
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.
nice review, thanks dude!
Thank you for the review. Really helpful.
Question
If I dont recall have installed QEMU… why would run on my computer? thanks
Pingback: Capture data on open source router interfaces in GNS3 | Open-Source Routing and Network Simulation
Nice review dude.
VirtualBox works great for me (running 64-bit windows). just remember that you can use one machine in VirtualBox and create as many clone of that machine as needed, especially linked clone as they don’t take much storage.
Also you can use “snapshots” in VirtualBox to save a virtual machine settings so you can use it in another without losing those setting, you can create as many as you need and restore to whichever you want, that give the user endless possibilities.
Sorry for my English.
Hi Khalid
Thanks for your comment. I agree with your point about Linked Clones and Snapshots. These are very useful features. Please see my post about using VirtualBox linked clones with GNS3 for my overview of that feature.
–Brian