GNS3 Qemu Troubleshooting

Many GNS3 users use Qemu emulator to run various network OS installed on Qemu images – for example Olive, ASA, Vyatta and many others. Some users complain about not having a network connections between these devices or a console window appears and disappears  after the short time. In both cases Qemu hosts are not started properly and Qemu images don’t work.

This issues are typically caused by entering a wrong parameter in GNS3 setting.  For instance  when user checks a box “Use kvm” in GNS3 settings and CPU doesn’t support kvm or kvm is not enabled in BIOS, it ends with warning message “unknown parameter kvm” and Qemu image is not started. Please remember that  kvm is not supported by Windows so you shouldn’t have  “Use kvm” checked if GNS3 is installed on Windows.

Another issue mainly occurs on Linux and Mac OS and it is caused by using unpatched Qemu binary. GNS3 create UDP tunnels in order to make connection between Qemu devices  and that is why  Qemu source have to be patched for UDP tunnels, compiled and installed by user. Although many Linux distributions already have Qemu installed in /usr/bin/ directory, this version of Qemu is unlikely to be patched for UDP tunnels. For this reason the Qemu doesn’t understand parameter -net type udp and it is halted after its start.

As long as patched Qemu binary is included in GNS3 all-in-one package, the Windows users  don’t need to patch, compile and install Qemu by themselves.

Except of the wrong parameters I have already mentioned there can be another problems which  prevent Qemu  starting successfully.  If you find Qemu difficult to start you should consider to do following troubleshooting to find out the reasons why Qemu doesn’t work.

1/ Start qemuwrapper.py script from Linux terminal console.  The script is located in a in  the GNS3 root directory, in the directory ./qemuwrapper

sudo /home/brezular/Download/GNS3-files/GNS3/Stable/GNS3-0.7.3-src/qemuwrapper/qemuwrapper.py

Qemu Emulator Wrapper (version 0.7.3)
Copyright (c) 2007-2010 Thomas Pani & Jeremy Grossmann

Unpacking pemu binary.
Qemu TCP control server started (port 10525).
Listenning on all network interfaces

The script has started Qemuwrapper server on TCP port 10525.

2/ Start GNS3 application

Create a new blank project and save it. Drug two Qemu hosts or Junipers from left panel and drop them in to the GNS3 Desktop (Figure 1). You should see a warning message – Qemu is already running on port 10525, it will not be shutdown after you quit GNS3.  It simply means that GNS3 has tried to start Qemu wrapper server on TCP port 10525 but another Qemuwrapper server is running on this port. We started it by ourselves with qemuwrapper script.

It is time to make connection between nodes . Connect them with Ethernet link and  start both Qemu hosts.

Figure 1. Qemu hosts connected through e0 interfaces

3/ Check the output of qemuwrapper script in console window. It should look like this:

Qemu path is now /usr/bin/qemu
Qemu-img path is now /usr/bin/qemu-img
!! QEMU1.console = 3000
!! QEMU1.netcard = e1000
!! QEMU1.image = /home/brezular/Download/GNS3-files/PC/Microcore/Stable/Host/3.4/linux-microcore-3.4.img
!! QEMU1.ram = 48
!! QEMU1.options = -no-acpi -nographic
!! QEMU2.console = 3001
!! QEMU2.netcard = e1000
!! QEMU2.image = /home/brezular/Download/GNS3-files/PC/Microcore/Stable/Host/3.4/linux-microcore-3.4.img
!! QEMU2.ram = 48
!! QEMU2.options = -no-acpi -nographic
command: ['/usr/bin/qemu', '-name', 'QEMU1', '-m', '48', '/tmp/QEMU1/FLASH', '-hdb', '/tmp/QEMU1/SWAP', '-net', 'nic,vlan=0,macaddr=00:aa:00:18:6c:00,model=e1000', '-net', 'udp,vlan=0,sport=20003,dport=20002,daddr=127.0.0.1','-net', 'nic,vlan=1,macaddr=00:00:ab:da:3d:01,model=e1000', '-net', 'nic,vlan=2,macaddr=00:00:ab:c3:46:02,model=e1000', '-net', 'nic,vlan=3,macaddr=00:00:ab:e9:c9:03,model=e1000', '-net', 'nic,vlan=4,macaddr=00:00:ab:77:f1:04,model=e1000', '-net', 'nic,vlan=5,macaddr=00:00:ab:f2:3c:05,model=e1000', '-serial', 'telnet::3000,server,nowait', '-no-acpi', '-nographic']
Invalid -net type ‘udp’
pid: 30268
Renicing to 19
30268: old priority 0, new priority 19
command: ['/usr/bin/qemu', '-name', 'QEMU2', '-m', '48', '/tmp/QEMU2/FLASH', '-hdb', '/tmp/QEMU2/SWAP', '-net', 'nic,vlan=0,macaddr=00:aa:00:98:21:00,model=e1000', '-net', 'udp,vlan=0,sport=20002,dport=20003,daddr=127.0.0.1', '-net', 'nic,vlan=1,macaddr=00:00:ab:09:1d:01,model=e1000', '-net', 'nic,vlan=2,macaddr=00:00:ab:26:50:02,model=e1000', '-net', 'nic,vlan=3,macaddr=00:00:ab:25:86:03,model=e1000', '-net', 'nic,vlan=4,macaddr=00:00:ab:6d:a3:04,model=e1000', '-net', 'nic,vlan=5,macaddr=00:00:ab:53:34:05,model=e1000', '-serial', 'telnet::3001,server,nowait', '-no-acpi', '-nographic']
Invalid -net type ‘udp’
pid: 30367
Renicing to 19
30367: old priority 0, new priority 19

The green lines refer to Qemu1 device. They are several parameters there such as RAM , console port, netcard type and path to  the base image. Please, notice QEMU1.options  parameters – no-acpi and -nographic.  If you have any problems with Qemu it is probably a good idea to leave this Qemu option box blank in GNS3 setting. Likewise blue lines refer to QEMU2 device.

As you can see from Figure 1 QEMU1 and QEMU2 are connected together via their eth0 interfaces.  They both use UDP tunnels for traffic transferred between them – QEMU1 sends all the traffic destined for QEMU2 to IP address 127.0.0.1,  destination UDP port 20002. QEMU2 is listening to traffic from QEMU1 on its source UDP port 20002. Likewise QEMU2 sends traffic destined for QEMU1 to IP address 127.0.0.1, destination UDP port 20003 and QEMU1 is listening to traffic from QEMU2 on its source port 20003.

If the Qemu had been properly patched for UDP tunnels a network connection would have been working between Qemu hosts.  For this demonstration  unpatched qemu binary in /usr/bin/ directory is used thus Qemu is stopped with  an error message Invalid -net type ‘udp’. If I edit .net file and set qemu path to /usr/local/bin/qemu ,  hosts will be started correctly because version of Qemu located in /usr/local/bin/ directory  is patched for UDP tunnels.

4/ Conclusion

You should have now a brief  idea of Qemu  troubleshooting for GNS3.  At least you know how to get an output of qemuwrapper and post it on GNS3 forum.  More about Qemu patching is on GNS3 blog:

http://blog.gns3.net/2009/10/olive-juniper/2/

In addition to stable UDP and multicast patch which is available for download in GNS3 Download section there is continuously  updated  patch for almost each new Qemu version in the  GNS3 Development section.  As I wrote Windows users don’t need to patch source by themselves due to the fact that GNS3 all-in-one package contains patched Qemu version.

About these ads