nspawn: support --network-bridge= behaviour for multiple veth interfaces/bridges

[PinkD]

When I use two --network-bridge to bind two bridges into container, it seems only the last bridge takes effect.
I found that --network-bridge only works with(implies) --network-veth , I can't bind bridge to the interface created by --network-veth-extra either
Is there any way to bind two bridge into the container?

btw: The two bridges are separately for different usages but both need to be in container.

[poettering]

Is there any way to bind two bridge into the container?

only manually currently.

The docs are actually sufficiently clear about how this works, and that this is about a single iface only...

Will convert this issue to an RFE now, asking for multiple nspawn veth bridge support.

[wsw70]

only manually currently.

What world be the procedure to manually add this second bridge? (from within the container or the host, or at spawn time?)

[LaKing]

@wsw70

To attach a second bridge to a container this is what worked for me:

• create a veth type netdev
• one side attached to the bridge via .network file
• other side is a (dhcp) client defined in a .network file
• other side also needs a second .network file that activates in the container
• attach it to the container with the --network-interface switch
  .. and start the container.

Note: #13530

[paulstelian97]

Bump. I'm trying to set up a containers based system at my home and I want to move from LXC to SystemD (to make the containers host as light as possible). This limitation is a big one, as I cannot make a VMs router container (which would need to be attached to two bridges on the host).

[mjt0k]

Besides multiple --network-bridges, what's lacking are additional parameters for the vlan-aware bridges (even a single bridge). When the bridge which is being used to add the veth device is vlan-aware (which is done with VLANFiltering=yes), one has to specify vlan configuration for the veth device being created, too, and this requires multiple parameters: see [BridgeVLAN] section in systemd.network.
That to say: if we're about to extend configuration possibility here, it's a good idea to think about other missings too.

[LaKing]

I cannot make a VMs router container (which would need to be attached to two bridges on the host).

This is possible. I have network configuration with mixed containers and VM's.

[mjt0k]

I cannot make a VMs router container (which would need to be attached to two bridges on the host).
This is possible. I have network configuration with mixed containers and VM's.

This is definitely possible, just not stright-forward: specifying more than one bridge for more than one container interface requires pre-configuring the interfaces. The whole thing becomes quite a bit awkward due to systemd-nspawn supporting just one --network-bridge.

(Speaking of router containers - what's the purpose of these?)

[paulstelian97]

I am using a router container (rather than a router VM) on my Proxmox host to give a NAT network to my VMs. The container is running inside a containers VM (reason I'm not using the Proxmox containers is I intended to switch to a different hypervisor that doesn't have containers). Besides the NAT I'm also helpfully using it as a VPN server to connect from remote destinations and/or to my work VPN (running openconnect on the container).

Router containers can be quite useful as well in the fact that you can do IPv6 NAT which, while weird in most cases, is quite useful when you suspend/resume VMs (and regular IPv6 addresses drop out, but the router container can be restarted and IPv6 connectivity restored to all VMs -- so it's useful for the network environment I have at home).

And yeah...I do have that kind of manual interface configuration to get it working, all done via systemd-networkd running on the containers host VM.