Re: [Lxc-users] Making LXC accept an already open network interface—or other options
On Mon, May 9, 2011 at 14:52, Serge Hallyn serge.hal...@canonical.com wrote: Thanks for your response. Before scripting it, let's try manually first: devs=`ls /sys/class/net/veth*` ip link add type veth newdevs=`ls /sys/class/net/veth*` # Get the intersection of $devs and $newdevs I assume you mean difference instead of intersection, since the first execution of ls gives an emtpy output, and the purpose of this is obtaining the new devices, right? host# ls /sys/class/net/ eth0 eth1 lo br0 host# ip link add type veth host# ls /sys/class/net/ eth0 eth1 lo br0 veth0 veth1 host# _ # Attach $dev1 to your bridge Assuming $dev1 is the first of the new devices: host# brctl addif br0 veth0 host# _ lxc-start -n mycontainer # mycontainer has no network After this, the container sees the same interfaces as the host and it does have connectivity to the outside: host# cat testimg01.conf lxc.tty = 4 lxc.pivotdir = .pivot lxc.arch=x86 lxc.utsname=testimg01 lxc.console=/tmp/lxc-testimg01-console.log lxc.rootfs=/root/lxc/nfsroot lxc.mount.entry=proc/root/lxc/nfsroot/proc proc defaults 0 0 lxc.mount.entry=sys /root/lxc/nfsroot/sys sysfs defaults 0 0 lxc.mount.entry=devpts /root/lxc/nfsroot/dev/pts devpts defaults 0 0 lxc.mount.entry=varlock /root/lxc/nfsroot/var/lock tmpfs defaults 0 0 lxc.mount.entry=tmp /root/lxc/nfsroot/tmp tmpfs mode=1777 0 0 lxc.cgroup.devices.deny = a lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm lxc.cgroup.devices.allow = c 4:0 rwm lxc.cgroup.devices.allow = c 4:1 rwm lxc.cgroup.devices.allow = c 5:0 rwm lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 1:8 rwm lxc.cgroup.devices.allow = c 1:9 rwm lxc.cgroup.devices.allow = c 5:2 rwm lxc.cgroup.devices.allow = c 136:* rwm lxc.cgroup.devices.allow = c 254:0 rm host# lxc-start -f testimg01.conf -n testimg01 -l DEBUG -o /tmp/lxc-testimg01.log _ container# # ip link show |grep ^[0-9] 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state UP qlen 1000 3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state UP qlen 1000 4: br0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UNKNOWN 6: veth0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN qlen 1000 7: veth1: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN qlen 1000 container# telnet 172.20.64.20 22## outside node Trying 172.20.64.20... Connected to 172.20.64.20. Escape character is '^]'. SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu4 _ # get PID as the init pid of mycontainer ip link set $dev2 netns $PID host# pgrep init 1 4809 host# ip link set veth1 netns 4809 host # _ # 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 Since eth0 exists inside the container, renaming veth1 returns an error: container# ip link set veth1 name eth0 RTNETLINK answers: File exists Am I doing something wrong? -- David Serrano -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Making LXC accept an already open network interface—or other options
Quoting David Serrano (dserra...@gmail.com): On Mon, May 9, 2011 at 14:52, Serge Hallyn serge.hal...@canonical.com wrote: Thanks for your response. Before scripting it, let's try manually first: devs=`ls /sys/class/net/veth*` ip link add type veth newdevs=`ls /sys/class/net/veth*` # Get the intersection of $devs and $newdevs I assume you mean difference instead of intersection, since the Hah, yeah. first execution of ls gives an emtpy output, and the purpose of this is obtaining the new devices, right? host# ls /sys/class/net/ eth0 eth1 lo br0 host# ip link add type veth host# ls /sys/class/net/ eth0 eth1 lo br0 veth0 veth1 host# _ # Attach $dev1 to your bridge Assuming $dev1 is the first of the new devices: host# brctl addif br0 veth0 host# _ lxc-start -n mycontainer # mycontainer has no network After this, the container sees the same interfaces as the host and it Oh, no. So it thought you didn't want your own network namespace. I don't know if there is a way to tell it to give you a new netns, without new devices. Of course you can trivially patch it to do that, but for now since we're testing it shouldn't hurt to just 1. tell it to give you a normal network interface lxc.network.type=veth lxc.network.link=br0 lxc.network.flags=down 2. bring up the container 3. bring down the normal interface 4. Continue here with passing veth1 into the container. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Making LXC accept an already open network interface—or other options
On Tue, May 10, 2011 at 16:36, Serge Hallyn serge.hal...@canonical.com wrote: 1. tell it to give you a normal network interface lxc.network.type=veth lxc.network.link=br0 lxc.network.flags=down 2. bring up the container 3. bring down the normal interface 4. Continue here with passing veth1 into the container. Thank you. We're almost there. With this configuration, now there's only lo and eth0 inside the container indeed. Then I: host# ip link set veth1 netns $pid container# ip link del eth0 container# ip link set veth1 name eth0 container# ifconfig eth0 10.1.0.253 up container# ping 10.1.0.101## address of br0 in the host PING 10.1.0.101 (10.1.0.101) 56(84) bytes of data. From 10.1.0.253 icmp_seq=1 Destination Host Unreachable From 10.1.0.253 icmp_seq=2 Destination Host Unreachable From 10.1.0.253 icmp_seq=3 Destination Host Unreachable If I bring up eth0 before deleting it and putting veth1 in its place, the network works as expected and I can ping the host's br0. But the veth1-renamed-to-eth0 doesn't want to work. Interestingly: container# ifconfig eth0 # ifconfig eth0 eth0 Link encap:Ethernet HWaddr ae:6c:69:6a:f5:08 inet addr:10.1.0.253 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) container# ip neigh show 10.1.0.101 dev eth0 FAILED container# arp -an ? (10.1.0.101) at incomplete on eth0 You can see that the packet counts remain at 0. -- David Serrano -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Making LXC accept an already open network interface—or other options
Quoting David Serrano (dserra...@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 -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
