Some bugs in 2.0.5-12-PRO

Features you'd like to see in the upcoming version of EVE-NG

Moderator: mike

Post Reply
Posts: 6
Joined: Mon Aug 14, 2017 5:37 pm

Some bugs in 2.0.5-12-PRO

Post by viets » Fri Jun 07, 2019 5:59 pm


first thank you for a very good software, which is very helpful in testing out several things in my work and for studying.

I'm running baremetal 2.0.5-12-PRO on ubuntu 16.04.

But I found some minor bugs, I'ld to report and hope you'll fix them in the future.

1. if you create multiple vmx-vcp in a row, all of them end up with the same base-mac address, which lead to errors if you do lacp bundeling (all have same system-id).

Code: Select all

root> show chassis mac-addresses
MAC address information:
  Public base address      2c:6b:f5:c5:36:00
  Public count             1984
  Private base address     2c:6b:f5:c5:3d:c0
  Private count            64
If you create every vmx-vcp on your own, this problem doesn't exists, so I think there is a mistake in the base-mac creation. Would be cool if this can be fixed. I'm not aware if other image have this problem as well.

2. If you use the HTML Wireshark, only packets till 1518 will be seen, higher packet length will not be seen, reason is because the docker eth has an mtu of 1500.

I changed the /opt/dockers-src/eve-wireshark/Dockerfile


Code: Select all

echo "setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' /usr/bin/dumpcap" >> /etc/my_init.d/

Code: Select all

echo "setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' /usr/bin/dumpcap" >> /etc/my_init.d/ &&\
echo "/sbin/ip link set dev eth0 mtu 9000" >> /etc/my_init.d/
and rebuild the docker container, then it's working. I'm not sure if 9000 is the max mtu, at least for me this was ok. Could this be integrated in the container?

3. As I already described in this forum post: viewtopic.php?f=3&t=908&p=3366#p3366

I noticed the vmx had a high cpu load on qemu. Thanks to this site: I was able to drop the vmx cpu usage a lot by changing the file /etc/modprobe.d/kvm.conf to:

Code: Select all

options kvm halt_poll_ns=0
To be honest I've no idea what it does and why it's not default, but at least for me it saved a huge amount of cpu cycles and I didn't noticed any problems at all.

4. I tried to create another linux vm with libvirt. As long as no eve-ng image is running the libvirt vm is stable, but as soon I start one machine, the machine will be exited with code 15 and one restart it will fail after 10 seconds. Unfortunately I don't know how to troubleshoot this. If I start the machine by hand with qemu it works fine.

5. At least for my installation about 3 weeks ago, the qemu-3.1 is missing, there is non under /opt

Lastly a some nice to have things as feature request:
a. store a default config in template folder which can be attached directly to the vm. really cool would be with some variables like ip addresses.

b. define a standard cloud for the management interface in a template. I usally connect the fxp to cloud0 for oob access. It would be nice if this could be default.

c. please add https to the forum ;)

I think thats all from now on. Looking forward to hearing from you and thanks in advance

Posts: 515
Joined: Wed Mar 15, 2017 1:54 pm

Re: Some bugs in 2.0.5-12-PRO

Post by ecze » Sat Jun 08, 2019 5:19 am


Thank you very much for your report.

some answers...

1. I will review the code to fix this.
2. Indeed, you are right , but to not force everybody to rebuild the docker, I will add this setting in the creation of the container on the fly as well.
3. Very nice catch. we will test impact on other nodes as well.
4. Libvirt is not supported and not advised. EVE API handle kvm nodes itself
5. qemu 3.1 require some api modification due to arguments depreciation so it is still in progress
6. https is already active fort both and sub-site ( forum )

Kind regards,


Posts: 6
Joined: Mon Aug 14, 2017 5:37 pm

Re: Some bugs in 2.0.5-12-PRO

Post by viets » Mon Jun 17, 2019 12:18 pm

Hi ecze,

thank you for the changes.

I'ld like to start one vm right of the start of eve. I thought I could use libvirt for this, but as described it always kills my vm.

I tried to run it directly in qemu and got the same result (ended with error code 15). I was only get it to work, when I stopped the eve services (didn't test which one was responsible):

1673 ? Ss 0:11 php /opt/unetlab/scripts/cpulimit_daemon.php > /opt/unetlab/data/Logs/cpulimit.log 2>&1
4690 ? Ssl 1:49 /opt/janus/bin/janus -o
5014 ? Sl 0:28 /usr/lib/jvm/default-java/bin/java -Djava.util.logging.config.file=/var/lib/tomcat8/conf/ -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC -Djava.endorsed.dirs=/usr/share/tomcat8/endorsed -classpath /usr/share/tomcat8/bin/bootstrap.jar:/usr/share/tomcat8/bin/tomcat-juli.jar -Dcatalina.base=/var/lib/tomcat8 -Dcatalina.home=/usr/share/tomcat8 org.apache.catalina.startup.Bootstrap start

For me it looks like one of these processes is killing my qemu. Is this expected as some kind of job running to prevent running other vms? Is this a bug, or simply not supported?

It would be very nice to have a possibility to run one vm at startup. I'ld like to do some disk passthrough and I wasn't able to do this in eve directly. Just to make sure I'm now testing with a standard ubuntu image, no passthrough involved, so it's not the trigger.

Furthermore I know that this is even more unsupported, but I tried to run virtualbox or vmware workstation on this box, but It failed always with:

Code: Select all

make[2]: *** [/tmp/modconfig-hJQay6/vmnet-only/vnetUserListener.o] Error 1
In file included from ./include/linux/compat.h:16:0,
                 from ./include/linux/ethtool.h:17,
                 from ./include/linux/netdevice.h:41,
                 from /tmp/modconfig-hJQay6/vmnet-only/userif.c:29:
./include/linux/if.h:28:54: fatal error: sys/socket.h: No such file or directory
Even though I've installed kernel headers, I wasn't able to find root cause yet, do you have an idea? Is there something missing in the kernel-headers? Ubuntu kernels work fine.

Is the eve-ng kernel source available, there is no deb-src mirror?

kind regards

Site Admin
Posts: 5
Joined: Wed Mar 15, 2017 12:53 pm

Re: Some bugs in 2.0.5-12-PRO

Post by eveadmin » Mon Jun 17, 2019 4:10 pm

Running VM outside control of EVE is not permitted.

To manage VM, EVE check and kill unmanaged Qemu VMs



Posts: 6
Joined: Mon Aug 14, 2017 5:37 pm

Re: Some bugs in 2.0.5-12-PRO

Post by viets » Mon Jun 17, 2019 6:43 pm


Is there a reason why it's prohibited? I'ld understand that if you like to protect your license for example. But I have a valid license and it is checked regulary. So I don't understand why it should not be allowed. Even more this should also prevent this howto (didn't tested yet): ... li-routers

Could you please bring some light into this?

To be honest I don't like the loss of this option because I wanted to do more with my server than eve-ng.

kind regards

Site Admin
Posts: 5
Joined: Wed Mar 15, 2017 12:53 pm

Re: Some bugs in 2.0.5-12-PRO

Post by eveadmin » Mon Jun 17, 2019 9:27 pm

Because we see eve-ng pro as an appliance.
We give support and it will be a nightmare to manage customization.

Our vision is like CUCM CallManager: It is a Redhat system but only Cisco stuff and needed daemons , tools runs on it.

Linux OS does not mean we support to use it as any linux distribution.
Pro will get more and more features like ram/cpu/disk usage limit per user. The be able to offer such, EVE APi will control all the qemu processes to brings the best performance for EVE services only.

The goal is to brings a well managed solution.

Use a seperate server to runs other services than those offered by EVE.
If some features are needed, as you saw previously, we are open to discussion and to include new stuff if we thing that it is a benefit for majority of users....

None of the services janus , cpulimit or tomcat is involved in this limitation/control.

node's qemu options permit to add fancy stuff..... starting a VM at boot time could be achieved using API calls from a script..... ( login, the start a node from a lab..... )



Posts: 82
Joined: Tue Jun 27, 2017 8:51 am

Re: Some bugs in 2.0.5-12-PRO

Post by Chris929 » Fri Aug 23, 2019 3:16 pm

In regards to point 3:

Care should be taken when setting the halt_poll_ns module parameter as a
large value has the potential to drive the cpu usage to 100% on a machine which
would be almost entirely idle otherwise. This is because even if a guest has
wakeups during which very little work is done and which are quite far apart, if
the period is shorter than the global max polling interval (halt_poll_ns) then
the host will always poll for the entire block time and thus cpu utilisation
will go to 100%.

So setting this to 0 should be fine and should DRASTICALLY improve Juniper (and others) on EVE-NG
( ... olling.txt)

Tested all my JNCIE Labs with this and the improvement is fascinating - no issues so far

Posts: 4
Joined: Fri Feb 14, 2020 2:23 am
Location: USA

Some bugs in 2 0 5 12 PRO

Post by FrotaBreato » Mon Feb 24, 2020 2:42 am

Below are 3 screenshots of what seemed to be skin bugs to me. I think the screenshots which were all taken the with ShareazaOS skin enabled and the file comments are self-explanatory, but of course, if I wasnt clear enough for something feel free to drop a reply.

Hope its useful in some way.

Post Reply