vdev_probe() fails when starting `pktgen` app in a docker container - docker

I am trying to start a Pktgen app in docker container using openvswitch virtual ports. The structure of my ideal system is shown as follows:
(1) Build dpdk-stable-17.11.4 and ovs-2.9.0, and create 4 virtual ports as follows:
Bridge "ovs-br0"
Port "vhost-user2"
Interface "vhost-user2"
type: dpdkvhostuser
Port "ovs-br0"
Interface "ovs-br0"
type: internal
Port "vhost-user3"
Interface "vhost-user3"
type: dpdkvhostuser
Port "vhost-user0"
Interface "vhost-user0"
type: dpdkvhostuser
Port "vhost-user1"
Interface "vhost-user1"
type: dpdkvhostuser
When I check the log of creating virtual ports, I find an error:
2019-01-27T15:59:23.346Z|00041|bridge|INFO|bridge ovs-br0: added interface ovs-br0 on port 65534
2019-01-27T15:59:23.375Z|00042|bridge|INFO|bridge ovs-br0: using datapath ID 000066b38a29f447
2019-01-27T15:59:23.375Z|00043|connmgr|INFO|ovs-br0: added service controller "punix:/usr/local/var/run/openvswitch/ovs-br0.mgmt"
2019-01-27T15:59:23.411Z|00044|dpdk|INFO|VHOST_CONFIG: vhost-user server: socket created, fd: 44
2019-01-27T15:59:23.411Z|00045|netdev_dpdk|INFO|Socket /usr/local/var/run/openvswitch/vhost-user0 created for vhost-user port vhost-user0
2019-01-27T15:59:23.411Z|00046|dpdk|INFO|VHOST_CONFIG: bind to /usr/local/var/run/openvswitch/vhost-user0
2019-01-27T15:59:23.411Z|00047|netdev_dpdk|WARN|dpdkvhostuser ports are considered deprecated; please migrate to dpdkvhostuserclient ports.
2019-01-27T15:59:23.411Z|00048|dpif_netdev|INFO|PMD thread on numa_id: 0, core id: 2 created.
2019-01-27T15:59:23.411Z|00049|dpif_netdev|INFO|There are 1 pmd threads on numa node 0
2019-01-27T15:59:23.412Z|00050|dpdk|ERR|RING: Cannot reserve memory for tailq
2019-01-27T15:59:23.424Z|00051|dpdk|ERR|RING: Cannot reserve memory for tailq
2019-01-27T15:59:23.434Z|00052|dpdk|ERR|RING: Cannot reserve memory for tailq
2019-01-27T15:59:23.443Z|00053|dpdk|ERR|RING: Cannot reserve memory for tailq
2019-01-27T15:59:23.458Z|00054|dpif_netdev|INFO|Core 2 on numa node 0 assigned port 'vhost-user0' rx queue 0 (measured processing cycles 0).
2019-01-27T15:59:23.458Z|00055|bridge|INFO|bridge ovs-br0: added interface vhost-user0 on port 1
2019-01-27T15:59:23.478Z|00056|dpdk|INFO|VHOST_CONFIG: vhost-user server: socket created, fd: 49
2019-01-27T15:59:23.478Z|00057|netdev_dpdk|INFO|Socket /usr/local/var/run/openvswitch/vhost-user1 created for vhost-user port vhost-user1
2019-01-27T15:59:23.478Z|00058|dpdk|INFO|VHOST_CONFIG: bind to /usr/local/var/run/openvswitch/vhost-user1
2019-01-27T15:59:23.478Z|00059|dpif_netdev|INFO|Core 2 on numa node 0 assigned port 'vhost-user0' rx queue 0 (measured processing cycles 0).
2019-01-27T15:59:23.479Z|00060|dpif_netdev|INFO|Core 2 on numa node 0 assigned port 'vhost-user1' rx queue 0 (measured processing cycles 0).
It says that RING: Cannot reserve memory for tailq. I have no idea about this error. I have already allocated some hugepages in DPDK.
(2) Build pktgen-3.5.0
(3) Write Dockerfile and start docker. The Dockerfile:
FROM ubuntu:latest
RUN apt update -y
RUN apt-get install -y numactl libpcap-dev
WORKDIR /root/dpdk
COPY dpdk-stable-17.11.4 /root/dpdk/.
COPY pktgen-3.5.0 /root/pktgen/.
RUN ln -s /root/pktgen/app/x86_64-native-linuxapp-gcc/pktgen /usr/bin/pktgen
ENV PATH "$PATH:/root/dpdk/x86_64-native-linuxapp-gcc/app/"
build the images:
sudo docker build -t pktgen-docker .
start the container:
sudo docker run -ti --privileged --name=pktgen-docker \
-v /mnt/huge:/mnt/huge -v /usr/local/var/run/openvswitch:/var/run/openswitch \
pktgen-docker:latest
(4) start pktgen app.
app/x86_64-native-linuxapp-gcc/pktgen -l 0-1 -n 3 --file-prefix=pktgen-docker --no-pci --log-level=8\
--vdev 'net_virtio_user0,mac=00:00:00:00:00:05,path=/var/run/openvswitch/vhost-user0' \
--vdev 'net_virtio_user1,mac=00:00:00:00:00:01,path=/var/run/openvswitch/vhost-user1' \
-- -T -P -m '1.[0-1]'
I simply use 2 lcores, lcore-1 is for rx/tx of 2 virtual port. I set up 2 --vdev using the ovs-dpdk ports, i.e., vhost_user0, vhost_user1.
However, the error come:
Copyright (c) <2010-2017>, Intel Corporation. All rights reserved. Powered by DPDK
sh: 1: lspci: not found
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 4 lcore(s)
EAL: Probing VFIO support...
EAL: Module /sys/module/vfio not found! error 2 (No such file or directory)
EAL: VFIO modules not loaded, skipping VFIO support...
EAL: Module /sys/module/vfio not found! error 2 (No such file or directory)
EAL: Setting up physically contiguous memory...
EAL: Trying to obtain current memory policy.
EAL: Hugepage /mnt/huge/pktgen-dockermap_1 is on socket 0
EAL: Hugepage /mnt/huge/pktgen-dockermap_2 is on socket 0
EAL: Hugepage /mnt/huge/pktgen-dockermap_3 is on socket 0
EAL: Hugepage /mnt/huge/pktgen-dockermap_4 is on socket 0
EAL: Hugepage /mnt/huge/pktgen-dockermap_5 is on socket 0
EAL: Hugepage /mnt/huge/pktgen-dockermap_6 is on socket 0
...
EAL: Hugepage /mnt/huge/pktgen-dockermap_167 is on socket 0
EAL: Hugepage /mnt/huge/pktgen-dockermap_0 is on socket 0
EAL: Ask a virtual area of 0x15000000 bytes
EAL: Virtual area found at 0x100000000 (size = 0x15000000)
EAL: Requesting 168 pages of size 2MB from socket 0
EAL: TSC frequency is ~2594018 KHz
EAL: Master lcore 0 is ready (tid=8f222900;cpuset=[0])
EAL: lcore 1 is ready (tid=8d5fd700;cpuset=[1])
vdev_probe(): failed to initialize net_virtio_user0 device
vdev_probe(): failed to initialize net_virtio_user1 device
EAL: Bus (vdev) probe failed.
Lua 5.3.4 Copyright (C) 1994-2017 Lua.org, PUC-Rio
Copyright (c) <2010-2017>, Intel Corporation. All rights reserved.
Pktgen created by: Keith Wiles -- >>> Powered by DPDK <<<
>>> Packet Burst 64, RX Desc 1024, TX Desc 2048, mbufs/port 16384, mbuf cache 2048
!PANIC!: *** Did not find any ports to use ***
PANIC in pktgen_config_ports():
*** Did not find any ports to use ***6: [app/x86_64-native-linuxapp-gcc/pktgen(_start+0x2a) [0x5592bd24d66a]]
5: [/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f5b8de20b97]]
4: [app/x86_64-native-linuxapp-gcc/pktgen(main+0xe67) [0x5592bd24a1e7]]
3: [app/x86_64-native-linuxapp-gcc/pktgen(pktgen_config_ports+0x170b) [0x5592bd277a4b]]
2: [app/x86_64-native-linuxapp-gcc/pktgen(__rte_panic+0xc5) [0x5592bd244bb7]]
1: [app/x86_64-native-linuxapp-gcc/pktgen(rte_dump_stack+0x2e) [0x5592bd2dcb3e]]
Aborted (core dumped)
I use IGB_UIO not VFIO.
I don't set --socket-mem, and lcore1 and lcore2 are both ready.
--vdev fails to initialize. I have checked /var/run/openvswitch, vhost-user0 and vhost-user1 exists.
Thank you for sharing your idea. Best wishes.

I think /var/run/openswitch should be /var/run/openvswitch.
sudo docker run -ti --privileged --name=pktgen-docker -v /mnt/huge:/mnt/huge -v /usr/local/var/run/openvswitch:/var/run/openswitch pktgen-docker:latest

OVS creates the virtio-user sock in the directory as it is running in server mode. The pktgen is also started with virtio-user mode. This conflicts as both are running in server mode.
The correct way is to start pktgen in client mode using virtio_userx. If the goal is to have packet transfer between Docker-1 Pktgen and Docker-2 that is connected by OVS-DPDK one has to use net_vhost and virtio_user pair.
Docker-1 Pktgen (net_vhost) <==> OVS-DPDK port-1 (virtio_user) {Rule to forward} OVS-DPDK port-2 (virtio_user) <==> Docker-2 Pktgen (net_vhost)
In the current setup, you will have to make the following changes
start DPDK pktgen in Docker-1 by changing from --vdev 'net_virtio_user0,mac=00:00:00:00:00:05,path=/var/run/openvswitch/vhost-user0' to --vdev 'net_vhost0,iface=/var/run/openvswitch/vhost-user0'
start DPDK testpmd by changing from --vdev
start DPDK pktgen in Docker-2 by changing from --vdev 'net_virtio_user0,mac=00:00:00:00:00:05,path=/var/run/openvswitch/vhost-user0' to --vdev 'net_vhost1,iface=/var/run/openvswitch/vhost-user1'
then start DPDK-OVS with --vdev=virtio_user0,path=/var/run/openvswitch/vhost-user0 and --vdev=virtio_user1,path=/var/run/openvswitch/vhost-user1
add rules to allow the port to port forwarding between Docker-1 pktgen and Docker-2 pktgen
Note:
please update the command line for multiple ports.
explained in comments. This is more of a usage problem

Related

Unable to mount hugetlbfs in non-root docker container

Trying to run a dpdk app in a container without the --privileged option to docker run.
I've created the hugetlbfs mounts on the host machine (e.g., mount -t hugetlbfs nodev /tmp/mnt/huge)
# mount | grep huge
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,hugetlb)
nodev on /tmp/mnt/huge type hugetlbfs (rw,relatime,seclabel)
However, within the container I get:
EAL: Selected IOVA mode 'VA'
EAL: 64 hugepages of size 1073741824 reserved, but no mounted hugetlbfs found for that size
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL: Failed to get current mempolicy: Operation not permitted. Assuming MPOL_DEFAULT.
EAL: set_mempolicy failed: Operation not permitted
EAL: set_mempolicy failed: Operation not permitted
EAL: Failed to get current mempolicy: Operation not permitted. Assuming MPOL_DEFAULT.
EAL: set_mempolicy failed: Operation not permitted
EAL: set_mempolicy failed: Operation not permitted
EAL: error allocating rte services array
EAL: FATAL: rte_service_init() failed
EAL: rte_service_init() failed
I've tried both setting the ownership of the mount point to the non-root-user as well as trying to bind the mount point in various ways (e.g., -v /mnt/huge:/mnt/huge -v /dev/hugepages:/dev/hugepages). I've even tried non-standard mountpoints and passing --huge-dir non/standard/mountpoint to the eal_args.
One stackoverflow answer suggested using the --device option (e.g., --device /dev/hugepages), but for /dev/hugepages or /dev/hugetlbfs I get the following error:
/usr/bin/docker-current: Error response from daemon: linux runtime spec devices: error gathering device information while adding custom device "/dev/hugepages": not a device node.
I've also passed in a lot of syscaps like sys_rawio, sys_admin, sys_resource, but doubt those are the issue.
It seems like people have been able to do it in the past. Not sure if there are new features in docker that lock down memory further in containers preventing what I'm trying to do. Any suggestions?

Why DHT can't find resource when to download with a trackerless torrent?

Please do as i do in your vps and then maybe the issue reproduced,replace the variable $vps_ip with your real vps ip during the below steps.
wget https://saimei.ftp.acc.umu.se/debian-cd/current/amd64/iso-cd/debian-10.4.0-amd64-netinst.iso
transmission-create -o debian.torrent debian-10.4.0-amd64-netinst.iso
Create a trackerless torrent ,show info on it:
transmission-show debian.torrent
Name: debian-10.4.0-amd64-netinst.iso
File: debian.torrent
GENERAL
Name: debian-10.4.0-amd64-netinst.iso
Hash: a7fbe3ac2451fc6f29562ff034fe099c998d945e
Created by: Transmission/2.92 (14714)
Created on: Mon Jun 8 00:04:33 2020
Piece Count: 2688
Piece Size: 128.0 KiB
Total Size: 352.3 MB
Privacy: Public torrent
TRACKERS
FILES
debian-10.4.0-amd64-netinst.iso (352.3 MB)
Open the port which transmission running on your vps.
firewall-cmd --zone=public --add-port=51413/tcp --permanent
firewall-cmd --reload
Check it from your local pc.
sudo nmap $vps_ip -p51413
Host is up (0.24s latency).
PORT STATE SERVICE
51413/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 1.74 seconds
Add the torrent and seed it with transmission's default username and password on your vps(with your own if you already change it):
transmission-remote -n "transmission:transmission" --add debian.torrent
localhost:9091/transmission/rpc/ responded: "success"
transmission-remote -n "transmission:transmission" --list
ID Done Have ETA Up Down Ratio Status Name
1 0% None Unknown 0.0 0.0 None Idle debian-10.4.0-amd64-netinst.iso
Sum: None 0.0 0.0
transmission-remote -n "transmission:transmission" -t 1 --start
localhost:9091/transmission/rpc/ responded: "success"
Get the debian.torrent from your vps into local pc.
scp root#$vps_ip:/root/debian.torrent /tmp
Now to try download it in your local pc.
aria2c --enable-dht=true /tmp/debian.torrent
06/08 09:28:04 [NOTICE] Downloading 1 item(s)
06/08 09:28:04 [NOTICE] IPv4 DHT: listening on UDP port 6921
06/08 09:28:04 [NOTICE] IPv4 BitTorrent: listening on TCP port 6956
06/08 09:28:04 [NOTICE] IPv6 BitTorrent: listening on TCP port 6956
*** Download Progress Summary as of Mon Jun 8 09:29:04 2020 ***
===============================================================================
[#a34431 0B/336MiB(0%) CN:0 SD:0 DL:0B]
FILE: /tmp/debian-10.4.0-amd64-netinst.iso
-------------------------------------------------------------------------------
I wait about one hour ,the download progress is always 0%.
If you're using DHT, you have to open a UDP port in your firewall and then, depending on what you're doing, you can specify that port to aria2c. From the docs:
DHT uses UDP. Since aria2 doesn't configure firewalls or routers for port forwarding, it's up to you to do it manually.
$ aria2c --enable-dht --dht-listen-port=6881 file.torrent
See this page for some more examples of using DHT with aria2c.

Docker not seeing usb /dev/ttyACM0 after unplugging and then replugging

I'm running a Docker container Ubuntu 18.04 which I use to compile code and flash IOT devices, I use this command: docker run --privileged --device=/dev/ttyACM0 -it -v disc_vol1:/root/zephyr zephyr
To run the docker container, which allows me to see the usb devices. However if I for some reason need to unplug and replug the devices, whilst the container is still running, docker no longer sees them, until I restart the container.
Is there a solution for this problem?
DMESG after unplugging and then replugging:
[388387.919792] usb 3-3: USB disconnect, device number 47
[388387.919796] usb 3-3.1: USB disconnect, device number 48
[388387.957792] FAT-fs (sdb): unable to read boot sector to mark fs as dirty
[388406.517953] usb 3-1: new high-speed USB device number 51 using xhci_hcd
[388406.666047] usb 3-1: New USB device found, idVendor=0424, idProduct=2422
[388406.666051] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[388406.666415] hub 3-1:1.0: USB hub found
[388406.666438] hub 3-1:1.0: 2 ports detected
[388407.881910] usb 3-1.1: new full-speed USB device number 52 using xhci_hcd
[388407.986919] usb 3-1.1: New USB device found, idVendor=0d28, idProduct=0204
[388407.986924] usb 3-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[388407.986927] usb 3-1.1: Product: DAPLink CMSIS-DAP
[388407.986929] usb 3-1.1: Manufacturer: ARM
[388407.986932] usb 3-1.1: SerialNumber: 1026000015afe1e800000000000000000000000097969902
[388407.987898] usb-storage 3-1.1:1.0: USB Mass Storage device detected
[388407.988131] scsi host10: usb-storage 3-1.1:1.0
[388407.991188] hid-generic 0003:0D28:0204.00A9: hiddev0,hidraw3: USB HID v1.00 Device [ARM DAPLink CMSIS-DAP] on usb-0000:00:14.0-1.1/input3
[388407.991926] cdc_acm 3-1.1:1.1: ttyACM0: USB ACM device
[388409.014753] scsi 10:0:0:0: Direct-Access MBED VFS 0.1 PQ: 0 ANSI: 2
[388409.015336] sd 10:0:0:0: Attached scsi generic sg2 type 0
[388409.015632] sd 10:0:0:0: [sdb] 131200 512-byte logical blocks: (67.2 MB/64.1 MiB)
[388409.015888] sd 10:0:0:0: [sdb] Write Protect is off
[388409.015892] sd 10:0:0:0: [sdb] Mode Sense: 03 00 00 00
[388409.016103] sd 10:0:0:0: [sdb] No Caching mode page found
[388409.016109] sd 10:0:0:0: [sdb] Assuming drive cache: write through
[388409.045555] sd 10:0:0:0: [sdb] Attached SCSI removable disk
[388482.439345] CIFS VFS: Free previous auth_key.response = 00000000df9e4b01
[388521.789341] CIFS VFS: Free previous auth_key.response = 0000000071020f34
[388554.099064] CIFS VFS: Free previous auth_key.response = 000000002a3aa60b
[388590.132004] CIFS VFS: Free previous auth_key.response = 000000009bed9fb5
[388606.372288] usb 3-1: USB disconnect, device number 51
[388606.372292] usb 3-1.1: USB disconnect, device number 52
[388606.415803] FAT-fs (sdb): unable to read boot sector to mark fs as dirty
[388622.643954] usb 3-3: new high-speed USB device number 53 using xhci_hcd
[388622.792057] usb 3-3: New USB device found, idVendor=0424, idProduct=2422
[388622.792061] usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[388622.792451] hub 3-3:1.0: USB hub found
[388622.792479] hub 3-3:1.0: 2 ports detected
And when I do ls /dev/ttyACM0 or /dev/ttyACM1 nothing changes when it is plugged or unplugged. The problem is that I cannot flash or see the devices with for example pyocd, when I do pycod list the devices wont show up until I restart the container.
Problem
The problem lies in device node creation mechanism.
As you can read in LFS docs, in 9.3.2.2. Device Node Creation:
Device files are created by the kernel by the devtmpfs filesystem.
By comparing mount entries in host:
$ mount
...
udev on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=16259904k,nr_inodes=4064976,mode=755,inode64)
...
...and in container:
# mount
...
tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755,inode64)
...
...you can notice that /dev filesystem in the container isn't the same thing as it is in the host.
It seems to me that privileged docker container recreates /dev structure while staring. Later, kernel does create device node in devtmpfs, but as long as the container uses separate filesystem for devices, the node isn't created there. As a confirmation, you can notice that after unplugging the device (the one that was connected before container started), its node still persists inside container, but disappears from the host.
Solution
You can workaround it by creating the node manually. In this example I plugged in /dev/ttyUSB1 while container was running.
On the host machine find major and minor device number:
$ ls -la /dev/ttyUSB*
crw-rw----+ 1 root plugdev 188, 0 gru 5 15:25 /dev/ttyUSB0
crw-rw----+ 1 root plugdev 188, 1 gru 5 15:26 /dev/ttyUSB1
# ^^^^^^ major and minor number
And create corresponding node inside container:
# ll /dev/ttyUSB*
crw-rw---- 1 root plugdev 188, 0 Dec 5 14:25 /dev/ttyUSB0
# mknod /dev/ttyUSB1 c 188 1
# ll /dev/ttyUSB*
crw-rw---- 1 root plugdev 188, 0 Dec 5 14:25 /dev/ttyUSB0
crw-r--r-- 1 root root 188, 1 Dec 5 15:16 /dev/ttyUSB1
The device should work.
Enhancement
You can also automate node creation by installing udev and writing some custom nodes inside container.
I found this repo that successfully sets up udev instance inside container - udevadm monitor correctly reflects udev events compared to host.
The last thing is to write some udev rules that will automagically create corresponding nodes inside the container:
ACTION=="add", RUN+="mknod %N c %M %m"
ACTION=="remove", RUN+="rm %N"
I haven't tested it yet, but I can see no reason that it will not work.
Better enhancement
You don't neet to install udev inside the container. You can run mknod there from script that runs on host machine (on host's udev trigger), as it's described here. It would be good to handle removing nodes as well.

ceph mount failed with (95) Operation not supported

I installed ceph on servers "A" and "B" and I would like to mount it from "C" or "D" servers.
But I faced below error.
ceph-fuse[4628]: ceph mount failed with (95) Operation not supported
My server configuration is as follow.
A Server: ubunt16.04(ceph-server) 10.1.1.54
B Server: ubuntu16.04(ceph-server) 10.1.1.138
C Server: AmazonLinux(clinet)
D Server: ubuntu16.04(client)
and ceph.conf
[global]
fsid = 44f299ac-ff11-41c8-ab96-225d62cb3226
mon_initial_members = node01, node02
mon_host = 10.1.1.54,10.1.1.138
auth cluster required = none
auth service required = none
auth client required = none
auth supported = none
osd pool default size = 2
public network = 10.1.1.0/24
Ceph is also installed correctly.
ceph health
HEALTH_OK
ceph -s
cluster 44f299ac-ff11-41c8-ab96-225d62cb3226
health HEALTH_OK
monmap e1: 2 mons at {node01=10.1.1.54:6789/0,node02=10.1.1.138:6789/0}
election epoch 12, quorum 0,1 node01,node02
osdmap e41: 2 osds: 2 up, 2 in
flags sortbitwise,require_jewel_osds
pgmap v100: 64 pgs, 1 pools, 306 bytes data, 4 objects
69692 kB used, 30629 MB / 30697 MB avail
64 active+clean
An error occurred when using the ceph-fuse command.
sudo ceph-fuse -m 10.1.1.138:6789 /mnt/mycephfs/ --debug-auth=10 --debug-ms=10
ceph-fuse[4628]: starting ceph client
2017-11-02 08:57:22.905630 7f8cfdd60f00 -1 init, newargv = 0x55779de6af60 newargc=11
ceph-fuse[4628]: ceph mount failed with (95) Operation not supported
ceph-fuse[4626]: mount failed: (95) Operation not supported
I got an error saying "ceph mount failed with (95) Operation not supported"
I added an option "--auth-client-required=none"
sudo ceph-fuse -m 10.1.1.138:6789 /mnt/mycephfs/ --debug-auth=10 --debug-ms=10 --auth-client-required=none
ceph-fuse[4649]: starting ceph client
2017-11-02 09:03:47.501363 7f1239858f00 -1 init, newargv = 0x5597621eaf60 newargc=11
Behavior changed, There is no response here.
I got an below error if ceph-fuse command is not used.
sudo mount -t ceph 10.1.1.138:6789:/ /mnt/mycephfs
can't read superblock
Somehow, it seems necessary to authenticate with client even with "auth supported = none"
In that case, how could you pass authentication form servers "c" or "d"?
Please let me know, If there is possible cause other than authentication.
I thought that you need more steps such as format the file system, so
you should check again your installation steps for your purposes, Ceph has multiple components for each services, such as object storage, block storage, file system and API. And each service was required its configuration steps.
This installation gude is helpful for your cases.
https://github.com/infn-bari-school/cloud-storage-tutorials/wiki/Ceph-cluster-installation-(jewel-on-CentOS)
If you want to build the Ceph file system for testing, you can build the small size CephFS as following installation steps.
I'll skip the details of the steps and CLI usages, you can get more information from the official documents.
Environment informations
Ceph version: Jewel, 10.2.9
OS: CentOS 7.4
Prerequisite before installation of Ceph file system.
Required this configuration 4 nodes,
ceph-admin node: deploy monitor, metadata server
ceph-osd0: osd service
ceph-osd1: osd service
ceph-osd2: osd service
Enabling NTP - all nodes
The OS user for deploying ceph compnents required escalation privileges setting (e.g. sudoers)
SSH public key configuration (directions: ceph-admin -> OSD nodes)
Installation of ceph-deploy tool on ceph-admin Admin node.
# yum install -y ceph-deploy
Deploying the required the Ceph components for the Ceph file system
Create the cluster on ceph-admin Admin node using normal OS user (for deploying ceph components)
$ mkdir ./cluster
$ cd ./cluster
$ ceph-deploy new ceph-admin
modify the ceph.conf into the cluster directory.
$ vim ceph.conf
[global]
..snip...
mon_initial_members = ceph-admin
mon_host = $MONITORSERVER_IP_OR_HOSTNAME
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx
# the number of replicas for objects in the pool, default value is 3
osd pool default size = 3
public network = $YOUR_SERVICE_NETWORK_CIDR
installing monitor and osd services to related nodes.
$ ceph-deploy install --release jewel ceph-admin ceph-osd0 ceph-osd1 ceph-osd2
initiate monitor service
$ ceph-deploy mon create-initial
Create the OSD devices
ceph-deploy osd list ceph-osd{0..2}:vdb
Adding metadata server component for Ceph file system service.
Adding metadata server (this service just required only Ceph file system)
ceph-deploy mds create ceph-admin
check the status
ceph mds stat
create the pools for cephFS
ceph osd pool create cephfs_data_pool 64
ceph osd pool create cephfs_meta_pool 64
Create the ceph file systems
ceph fs new cephfs cephfs_meta_pool cephfs_data_pool
Mount the Ceph file system
Required ceph-fuse package on the node for mounting.
mount as the cephFS
ceph-fuse -m MONITOR_SERVER_IP_OR_HOSTNAME:PORT_NUMBER <LOCAL_MOUNTPOINT>
End...
I solved this problem by fixing three settings.
1.
The auth settings in ceph.conf returned as follows
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
2.
public network was wrong.
public network = 10.1.1.0/24
↓
public network = 10.0.0.0/8
my client ip address was 10.1.0.238...
It was a stupid mistake.
3.
I changed secret option to secretfile option and everything was fine.
In this case, it was failed.
sudo mount -t ceph 10.1.1.138:6789:/ /mnt/mycephfs -o name=client.admin,secret=`sudo ceph-authtool -p /etc/ceph/ceph.client.admin.keyring`
output:
mount error 1 = Operation not permitted
but in this case, It was success.
sudo mount -vvvv -t ceph 10.1.1.138:6789:/ /mnt/mycephfs -o name=admin,secretfile=admin.secret
output:
parsing options: rw,name=admin,secretfile=admin.secret
mount: error writing /etc/mtab: Invalid argument
※ Invalid argument The error seems to be ignored.
Apparently, Both are the same key.
sudo ceph-authtool -p /etc/ceph/ceph.client.admin.keyring
AQBd9f9ZSL46MBAAqwepJDC5tuIL/uYp0MXjCA==
cat admin.secret
AQBd9f9ZSL46MBAAqwepJDC5tuIL/uYp0MXjCA==
I don't know reason,but I could mount using secretfile option.

I am running DPDK packet Gen application. The application does not find any ports by itself and even If I try to add one it doesnt work?

http://pktgen.readthedocs.org/en/latest/running.html
This is the pktgen dpdk application. The screenshot in that link shows how ports are configured. But For me it doesnt configure at all. I am looking for help as a beginner
First, as you may know, pktgen is an application that use the DPKD framework, thus, you should have bind at least one NIC to DPDK. Check the documentation about DPDK: DPDK building instructions. You should see your NIC correctly bound with this command:
# path/to/DPDK/tools/dpdk_nic_bind.py --status
Then, you can run pktgen. The ports you want to use are specified with the -p option (It's a specific pktgen option so it's after the --). It's a port mask, so for instance, if you want only the first port (port 0) you can use -p 0x1.
Then, the -m option permit you to choose which core will handle which DPDK port. The syntax is not really obvious, I suggest you to read the doc of pktgen about this option: pktgen command line options.
For example, to be short, the option -m "[1:3].0" says you want that CPU core 1 handle "RX port 0", and CPU core 3 handle "TX port 0".
A simple command line for pktgen, if you use only one port running on two cores could be:
./app/pktgen -c 0x7 -n 3 -- -p 0x1 -P -m "[1:2].0"
In that case CPU core 1 and 2 (possible because of the "-c 0x7 option") will be used to handle respectively RX and TX of port 0 (configured with "-p 0x1"). Note that -P is for promiscuous mode.

Resources