[Lxc-users] Making LXC accept an already open network interface—or other options

Serge Hallyn serge.hallyn at canonical.com
Mon May 9 12:52:15 UTC 2011


Quoting David Serrano (dserrano5 at gmail.com):
> Hi,
> 
> At $work we're currently using KVM and setting it up so that it uses a
> previously opened TAP interface: 'kvm -net tap,fd=3'. This way, we are
> able to create the interface a set up a couple of ebtables filters on
> it before going on. Now, we would like to do the same with LXC.
> 
> After taking a look to the documentation I don't think LXC is able to
> get the interface from a given FD, so I guess I should look for a
> workaround. I see there's a message in the LXC log that says
> «instanciated veth 'vethC1zCUS/vethtCn0zY'» but the relevant container
> doesn't appear in the same line. Yes it's in the previous line but
> relying on that is prone to race conditions. Moreover, reading from a
> debug log isn't elegant at all...
> 
> Do I have other options I haven't considered?

Best would be to patch the LXC code to do this, and send the patch
upstream.  But for first, for testing and $firebrigade purposes,
the way to do this by hand would be to write your own our_lxc_start.sh
script which does something like

#!/bin/sh
devs=`ls /sys/class/net/veth*`
ip link add type veth
newdevs=`ls /sys/class/net/veth*`
# Get the intersection of $devs and $newdevs
# Attach $dev1 to your bridge
lxc-start -n mycontainer
# mycontainer has no network
# get PID as the init pid of mycontainer
ip link set $dev2 netns $PID
# now from your mycontainer console, configure $dev2 which is now in the container
# you can rename it to eth0 in the container as
ip link set $dev2 name eth0

Something like that.  Patching lxc-start to take an extra command line
argument saying 'use this fd' shouldn't be a big deal.

-serge




More information about the lxc-users mailing list