[Question]: How to pass a PHYSICAL NIC ?

[lars18th]

Is your question not already answered in the FAQ?

• I made sure the question is not listed in the FAQ.

Is this a general question and not a technical issue?

• I am sure my question is not about a technical issue.

Question

Hi,

I want to know if it's possible to pass a physical network adapter instead of using the docker networking. The idea is to provide more low level access to a physical network. I know that with qemu we can pass through physical nic ports. But the question is if this is supported inside vDSM.

Any idea?

[lars18th]

Hi @kroese ,

Before you say it, this is related to #564 . But I need your help to improve it.

First of all, the file /etc/qemu/bridge.conf is missing. And to use qemu -netdev bridge this file is mandatory. So I recommend to add to the container image this: echo "allow br0" > /etc/qemu/bridge.conf. Then we can attach bridges to other network interfaces inside the container.

Second, it's how to connect two interfaces to the vDSM. At time we can do that (assuming eth1 on the host is the target lan network):

docker network create -d macvlan -o parent=eth1 --subnet=192.168.1.0/24 --gateway=192.168.1.1 --ip-range=192.168.1.70/32 -o macvlan_mode=passthru vdsm-eth0-macvlan
docker network create -d bridge vdsm-eth1-bridge

With these commands we create a MACVLAN network for the independent IP in the LAN, and one BRIDGE regular network. We need to define both because is not possible to run one user and one system. And very relevant it's the name. The assigned interfaces order (eth1, eth2, ethX) is based on the alfabetical order of the names. So for this reason I recommend vdsm-ethX-whatever.

With this config the macvlan will be the eth0 in the container, and a bridge (host) will be eth1. Therefore, when starting the container the LAN address (in the example 192.168.1.70) will be used as the main address for the vDSM.

And to add this secondary network to the vDSM, I'm using (manually, before the entry.sh):

ip link add name br0 type bridge
ip link set dev br0 up
ip addr del 172.31.4.2/24 dev eth1
ip link set eth1 master br0
ip addr add 172.31.4.2/24 dev br0

As you can imagine, the IP address in the bridge of the container are not necessary. But it could be useful when testing. So as the vDSM will be connected to that bridge, a different address in the same network will be used.

Finally the command to attach will be:
ARGUMENTS="-netdev bridge,id=hostnet1,br=br0 -device virtio-net-pci,romfile=,netdev=hostnet1,id=net1"

And the interfece will be available inside the vDSM. Nice! 😆

However the problems are:

• No working DHCP. You need to assign static IP using the ip address range of the eth1 in the container. I.e. 172.31.4.4/24. After configure it (using the first interface) you can ping from host and from the container.
• No port forwarding from host to the bridge (secondary) interface. I don't know why. But the ip tables are not created when the eth0 is the macvlan. If the eth0 is the bridge, the ip tables are created... but in this case, the forwarding doesn't work when the two networks are used. Yes if only one. Perhaps a bug? I don't know.

And why all of this? This is the objective:

• Run the container with two interfaces: one from the host (for managing, using port forwarding of 5000 and 22) and another connected directly to a LAN for providing services. And the most important: the LAN could be a different (and isolated) network from the HOST. This will garantee more security. And you can block ports 22 and 5000 in the LAN interface.

However, we need to solve some of the problems. So first of all, could you please fix the problem with the missing /etc/qemu/bridge.conf ?
And the second issue, you think could be a good idea to provide a /run/user-script.sh file to call it before the network is configured? Then we can mount a custom file to this path. And execute these command. You agree with that suggestion?

Waiting for your feedback.
Regards.