RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1251538 - [RFE] Allow docker to report the veth interface used by a container
Summary: [RFE] Allow docker to report the veth interface used by a container
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.1
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Antonio Murdaca
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-07 15:39 UTC by Jake Hunsaker
Modified: 2019-11-14 06:51 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-03 19:02:34 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Jake Hunsaker 2015-08-07 15:39:58 UTC 
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?

No

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

No


 List any affected packages or components.

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

https://github.com/docker/docker/issues/17064

Shishir
Comment 6 Daniel Walsh 2015-10-29 15:56:56 UTC 
https://github.com/docker/docker/pull/16729 is also related.
Comment 7 Daniel Walsh 2015-12-01 22:21:10 UTC 
Shishir what do you think of https://github.com/docker/docker/pull/16729#issuecomment-145259919
Comment 8 Antonio Murdaca 2015-12-02 09:20:19 UTC 
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 11:23:06 UTC 
Asked upstream to include the veth name here https://github.com/docker/docker/pull/18559#issuecomment-164139816
Comment 10 Daniel Walsh 2016-01-06 19:45:26 UTC 
Since this is merged can we close this as fixed in docker-1.10?
Comment 11 Antonio Murdaca 2016-01-06 20:48:56 UTC 
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 12:01:12 UTC 
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 10:18:10 UTC 
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, 0.0.0.0:8090->80/tcp   elated_euler

$ sudo docker inspect --format='{{.NetworkSettings.SandboxKey}}' 08b1a5b42aa9
/var/run/docker/netns/aea8f5968946

$ 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.