Closed harunaadoga closed 3 years ago
Thank you for reaching out with your environment. If I'm not mistaken /dev/hugepages
does not exist on Ubuntu 18.04. It only exists on 20.04 (which is our stable version). I think the main problem is the incompatibility between your host 18.04 Ubuntu and the OpenNetVM latest
container version 20.04 on Docker. What you could potentially do is change (in docker.sh
) here into sdnfv/opennetvm:19.07
so that Docker pulls the 19.07 onvm version (which used ubuntu 18.04).
Thank you for reaching out with your environment. If I'm not mistaken
/dev/hugepages
does not exist on Ubuntu 18.04. It only exists on 20.04 (which is our stable version). I think the main problem is the incompatibility between your host 18.04 Ubuntu and the OpenNetVMlatest
container version 20.04 on Docker. What you could potentially do is change (indocker.sh
) here intosdnfv/opennetvm:19.07
so that Docker pulls the 19.07 onvm version (which used ubuntu 18.04).
Thank you @kevindweb thanks for your response. I modified the docker.sh script to pull sdnfv/opennetvm:19.07, which pulls successfully after running the script. However, I still get the same error message (the NF wouldn't start from the container). Please what other suggestions would you recommend for fixing this? Do you think upgrading my host machine to 20.04 might fix this? or maybe not necessary to do so?
Thank you for reaching out with your environment. If I'm not mistaken
/dev/hugepages
does not exist on Ubuntu 18.04. It only exists on 20.04 (which is our stable version). I think the main problem is the incompatibility between your host 18.04 Ubuntu and the OpenNetVMlatest
container version 20.04 on Docker. What you could potentially do is change (indocker.sh
) here intosdnfv/opennetvm:19.07
so that Docker pulls the 19.07 onvm version (which used ubuntu 18.04).
Hello @kevindweb I upgraded my host machine to Ubuntu 20.04 (now seeing /dev/hugepages directory on host machine), pulled the latest sdnfv/opennetvm Docker image, but I still get the same error message when I try running an NF in the container. If you could assist with this, it will be appreciated, thanks.
@harunaadoga that is very weird that it's now at Ubuntu 20.04 and it still doesn't work.
Maybe try instead of this
sudo ./docker.sh -h /mnt/huge -o /home/openNetVM -n Basic_Monitor_NF -D /dev/uio0,/dev/uio1
doing this
sudo ./docker.sh -h /dev/hugepages -o /home/openNetVM -n Basic_Monitor_NF -D /dev/uio0,/dev/uio1
It maybe a problem with mapping the incorrect volume?
@harunaadoga that is very weird that it's now at Ubuntu 20.04 and it still doesn't work.
Maybe try instead of this
sudo ./docker.sh -h /mnt/huge -o /home/openNetVM -n Basic_Monitor_NF -D /dev/uio0,/dev/uio1
doing thissudo ./docker.sh -h /dev/hugepages -o /home/openNetVM -n Basic_Monitor_NF -D /dev/uio0,/dev/uio1
It maybe a problem with mapping the incorrect volume?
Thanks @kevindweb it works now after changing /mnt/huge to /dev/hugepages. Was trying to find out if running NFs from the containers gives a higher/lesser packet processing rate, this seem to be same as running them on the host machine (at least so far). Will try this with different NFs to observe the behaviour.
Thanks once again for helping out!
Container NF Error
Current Behavior Starting a new NF from a container gives memory(hugepage) initialisation error.
[Press Ctrl-C to quit ...] EAL: Detected 6 lcore(s) EAL: Detected 1 NUMA nodes EAL: Multi-process socket /var/run/dpdk/rte/mp_socket_42_1b777dfeca48bc EAL: Selected IOVA mode 'PA' EAL: Probing VFIO support... EAL: VFIO support initialized EAL: sync_existing(): Cannot open '/dev/hugepages': No such file or directory EAL: Could not map memory from primary process EAL: FATAL: Cannot init memory EAL: Cannot init memory EAL: Error - exiting with code: 1 Cause: Failed ONVM init
Expected behavior/code The container (secondary) process should be able to access the shared memory on the host machine.
Steps to reproduce
Environment
Possible Solution Not sure if this is a bug at this point, but mapping hugepages between the host machine and container might solve this problem.
Additional context/Screenshots NFs work fine on the host machine but wouldn't start within a container.