In a process within a container you have to connect the IP stack to the outside world, using a veth connection. But you don’t have to do this with a normal process i.e. a process not running in a container but in the actual linux o.s. A normal process is automatically connected to the NIC. So how come a normal processes IP data structure allows access to the NIC but the IP data structure in the container is not, given that neither process ‘knows’ it is running in a container and both processes have the same set of data structures?

I don't know what you mean by "automatically".

Processes connect to NICs if they are programmed or configured to do so. For example, the Apache web server uses the Listen directive in its configuration file to bind to a certain IP address. The process "sleep 1234 &" isn't connected to any NIC.

Can you provide an example of a process that automatically connects?
And of a process that doesn't when it runs in a container?

Thanks for that, Berndbausch. Thinking about it more, I need to reframe the question. I think the question is really about the linux image used to run the container. So say if I write a c program that has a socket call with SOCK_DGRAM param and a call to the bind function. When I run this program on a linux o.s. the program can send UDP packets over the NIC. But if I run this program as a container, the program will not work unless the Linux image in the container has run the veth command. I basically understand what the veth command does. That is not the question. The question is the LINUX O.S. does not have to run the veth command in order for the program to work, but the linux image in the container does. Why is that? What bits of LINUX is the container image missing that prevents it from having access to the NIC?

What kind of container is that? Linux Container, LXD, Docker, Virtuozzo, something else... ? If and how a container is connected to the network depends on its configuration.

I am not aware of a veth command.

The veth command is standard linux cf. http://man7.org/linux/man-pages/man4/veth.4.html
Re ‘what kind of container’. Linux container. There is an example of a container being built (using veth etc) in this talk by Jérôme Petazzoni,
https://www.youtube.com/watch?v=sK5i-N34im8
Note my question is not about veth. My question is what is missing in the linux image used in the container that means you have to use veth to allow your containerized process to connect to the NIC. The socket and bind functions will allows a c program to connect to the NIC when run as a linux process but not when run as process in a container.

veth is not a command. It's a network interface. You need a veth device in the container's network namespace because the host's physical NICs are not in the container's network namespace.

Remember that the purpose of containers is shielding applications from each other. This separation of applications is accomplished with namespaces: Mount namespace, process namespace, network namespace, and a few others. To give processes in the container access to the network, there must be a connection from the container's network namespace to the physical network on the host. This is (often or always) done with veth pairs; one end of the veth pair is in the container's namespace, the other outside. The outside half of the veth pair could be plugged into a bridge. A physical network interface can then also be plugged into the same bridge.

Thanks for the link, but I don't have the time right now to watch a 50 minutes presentation. Besides, this is from a Docker meeting, not Linux Containers.
What's missing is the ability of the image to configure the host. The host must provide an environment that allows the container image to run. The veth pair is part of this environment.

EDIT: This is no different for a virtual machine, by the way. Except that processes in the virtual machine don't see the veth, since NICs are emulated. But veths are a common mechanism to connect VMs to the host's network.

@OP
Are you using one of the many Linux container images on docker hub (), or building your own?
Isn't the whole point of container is to keep it minimal and you have to define everything you want to do (dockerfile for example)?

I might not be entirely clear on what you expect to happen, and I do apologize if I've misunderstood. Perhaps there's some issue with the context of the words, but you've mentioned DGRAM, yet you're using words such as "connect" and "connection". DGRAM, by definition, is a connection-LESS protocol. So I'm wondering, is there some expectation of connected-ness that isn't being met, because a DGRAM protocol is involved? Alternatively, I should point out that in one sense or another, a "Linux container" is a virtual environment. If I use a full blown "virtual machine" running on Linux, and if I wish what's inside the virtual machine, to interact with the physical World, then I have to make sure that something is set up to allow that. That might be something that's built in, in a way, to whatever "virtual machine" software I'm using, or it might be something for which I have to take action, to make sure it gets established. But one way or another, it is needed. E.G., I almost never use MS-Windows, but if I must, such as to be completely compatible with some file format which someone wishes used, and I need data from the outside world, over the physical NIC on the physical machine, then I have to make sure that the virtual machine can access the physical NIC.

Thanks Berndbaush,
I understand that one of the main functions that enables containers is namespaces. My point is that the Linux kernel image in the container is a sub-set of the functions supplied by Linux kernel. The Linux-host-kernel has a full set of Linux kernel functionality, including namespaces. So why is the Linux-host-kernel o.s able to connect to the NIC but the Linux-container-image-kernel is not?
The linux host is not providing an environment for the container. The container, including the linux-image, is just another linux process run by the linux host. The linux host does not provide anything to this process that it does not do to other processes.
You are correct in pointing out that veth is not a command. It is a virtual Ethernet device.
The presentation by Jerome is not about Docker containers. It is about what functionality has been added to the Linux kernel to allow containers. You might be particularly interested in the last 10 minutes of it, where he creates a container using the commands in the linux shell.

This point is incorrect. There is no kernel image in the container. A container uses the host's kernel.

Virtual machines, on the other hand, run their own kernel, which is entirely separate from the host's kernel.
The processes in the container don't see the host's NICs because they have their own network namespace.

I beg to differ.
Not quite. The processes in the container can't see the processes outside of the container. They can't see the filesystem outside of the container. And they can't see the NICs outside of the container.

Actually, this is precisely why containers exist: Processes in containers are not supposed to see all the host's resources. They are shielded from other containers, and they are shielded from the host.
OK, I did not check the presentation because I don't have the time. I have a rough idea about the features added to Linux, mostly CGroups and namespaces.

Ubuntu Could not reliably determine the servers fully qualified domain name, using for ServerName , .

, , :


: