Bug 1251538 - [RFE] Allow docker to report the veth interface used by a container
[RFE] Allow docker to report the veth interface used by a container
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker (Show other bugs)
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Antonio Murdaca
: Extras, FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2015-08-07 11:39 EDT by Jake Hunsaker
Modified: 2016-06-03 15:02 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-06-03 15:02:34 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jake Hunsaker 2015-08-07 11:39:58 EDT
Proposed title of this feature request

Allow easy discovery of which veth interface a given container is using.

 What is the nature and description of the request?

Currently there is not a reliable and easy way to determine which veth interface a container is using. Docker inspect will report the bridge and other networking information, but reporting which veth interface is in use directly would be beneficial.

 Why does the customer need this? (List the business requirements here)

In their own words:

"We're trying to use tc and netem in conjunction with docker containers to create self-contained "nightmare networks" for code testing purposes."

 How would the customer like to achieve this? (List the functional requirements here)

Being able to retrieve this from a 'docker inspect' would be acceptable. 

 Is there already an existing RFE upstream or in Red Hat Bugzilla?


 Does the customer have any specific time-line dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?


 List any affected packages or components.

Comment 5 smahajan@redhat.com 2015-10-15 10:28:44 EDT
Issue opened upstream.


Comment 6 Daniel Walsh 2015-10-29 11:56:56 EDT
https://github.com/docker/docker/pull/16729 is also related.
Comment 7 Daniel Walsh 2015-12-01 17:21:10 EST
Shishir what do you think of https://github.com/docker/docker/pull/16729#issuecomment-145259919
Comment 8 Antonio Murdaca 2015-12-02 04:20:19 EST
Pretty sure a PR based on https://github.com/docker/docker/pull/16729#issuecomment-145259919 would be good to re-start the discussion (it doesn't seem a big patch)
Comment 9 Antonio Murdaca 2015-12-12 06:23:06 EST
Asked upstream to include the veth name here https://github.com/docker/docker/pull/18559#issuecomment-164139816
Comment 10 Daniel Walsh 2016-01-06 14:45:26 EST
Since this is merged can we close this as fixed in docker-1.10?
Comment 11 Antonio Murdaca 2016-01-06 15:48:56 EST
It didn't end up in that PR upstream. I'll work out a patch tomorrow and send it upstream.
Comment 12 Antonio Murdaca 2016-01-14 07:01:12 EST
no plan in docker upstream to expose veths (veth's names generation now lives in libcontainer also). Work should start in libnetwork first.

libnetwork maintainers wish to have a generalized way to expose additional data for network drivers (no sense to expose veth names if using OVS driver was their argument)

After that it will be exposed in docker inspect
Comment 15 Antonio Murdaca 2016-05-24 06:18:10 EDT
Jake, one possible way of getting the veth used by a container is (this is fine when using the bridge network driver, which is the default and I'm assuming you need this):

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                           NAMES
08b1a5b42aa9        nginx               "nginx -g 'daemon off"   2 hours ago         Up 2 hours          443/tcp,>80/tcp   elated_euler

$ sudo docker inspect --format='{{.NetworkSettings.SandboxKey}}' 08b1a5b42aa9

$ sudo nsenter --net=/var/run/docker/netns/aea8f5968946 ethtool -S eth0
NIC statistics:
     peer_ifindex: 308

$ sudo ip link | grep 308:
308: vetha0c705b: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default

They're still not interested in exposing this in docker inspect because it breaks the abstraction built on network drivers.

Note You need to log in before you can comment on or make changes to this bug.