I have a CentOS-7 system I have set up some CentOS-7 systemd-nspawn containers on. By default, booting them makes them share the same range of network ports with the host so when the host is already serving on port 22 or 80, the container must either be configured to serve on another port or be remapped using (for example) the --port=tcp:2222:22 switch when booting. This isn't so bad when running only one nspawn container hosting only one service that uses only one port.
For more functional containers, I could either dedicate a USB-to-ethernet adapter to each container using the --network-interface=hosteth99 boot switch, or use a bridge with --network-bridge which apparently behaves like a network hub / switch in that it does not show up as an entry in mtr and allows real machines on my network to access a distinct IP address with its full range of standard ports per container. (Have I understood that correctly?) So as the nspawn container boots, the bridge notices it attach to one of the bridge's ports, request an IP address from my DHCP server via the bridge, and thereafter real computers should be able to ping, ssh to and http from the container as if it were a standalone system because the bridge forwards external network traffic to the internal virtual network.
I used nmtui to create a bridge. I set the bridge to get IPv4 address from DHCP and set the physical NIC as a slave. I installed bridge-utils and ran brctl while the container was running and it shows the container connected to the bridge. Now:
- booting the host assigns a DHCP address to the bridge
- mtr to that IP address (the IP address of the bridge) resolves the hostname of the container host
- sshing to the host's hostname works, and requests (eg curl) from the host work (so incoming and outgoing traffic to the host is fine)
- booting the container(s) with --network-bridge (with or without --network-veth) results in a host0 device within the container with no IPv4 address (even though I used nmtui within the container to set it to DHCP); the host has a corresponding vb-container device that gets set up and attached to the bridge's port as the container boots and torn down as it halts
- containers cannot make outgoing requests and external machines cannot ping the containers