[How To] - Troubleshoot GNS3 Qemu
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.
Start qemuwrapper.py script from Linux terminal console.
The script is located in a in the GNS3 root directory, in the directory ./qemuwrapper
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
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
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.
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.
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.
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.
Qemu hosts connected through e0 interfaces
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.
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:
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.
Links:
http://brezular.wordpress.com
Subscribe to:
Post Comments (Atom)
Nice post to read. Thanks for sharing with us. Keep up the great work i’ll be visiting to your blog.
create firefox toolbar
@crookedalley: Thanks & appreciate you response.