Bug 1251538

Summary:	[RFE] Allow docker to report the veth interface used by a container
Product:	Red Hat Enterprise Linux 7	Reporter:	Jake Hunsaker <jhunsaker>
Component:	docker	Assignee:	Antonio Murdaca <amurdaca>
Status:	CLOSED WONTFIX	QA Contact:	atomic-bugs <atomic-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1	CC:	amurdaca, dwalsh, jamills, lans.carstensen, lsm5, smahajan
Target Milestone:	rc	Keywords:	Extras, FutureFeature
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-06-03 19:02:34 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.